암호화 식별자

이 도구가 식별하는 형식

16진수 다이제스트는 길이로 식별합니다(대소문자 구분 없음):

예를 들어 d63dc919e201d7bc4c825630d2cf25fdc93d4b2f0d46706d29038d01은 56자이며, “password”라는 단어의 SHA-224 해시입니다.

비밀번호 해시는 접두사와 구조로 식별합니다:

• $2a$, $2b$, $2y$: bcrypt(코스트 팩터는 접두사에서 읽음)
• $1$: md5crypt, $apr1$: Apache MD5(htpasswd)
• $5$와 $6$: sha256crypt와 sha512crypt
• $y$: yescrypt, $7$와 $scrypt$: scrypt
• $argon2id$, $argon2i$, $argon2d$: Argon2
• $pbkdf2-sha256$(passlib)와 pbkdf2_sha256$(Django): PBKDF2
• $P$와 $H$: phpass(WordPress, phpBB), $S$: Drupal 7
• * 뒤에 16진수 40자가 오는 형식: MySQL 4.1+
• {SSHA}, {SHA} 및 그 밖의 일반적인 LDAP 스킴

자주 쓰이는 형식은 결과에 hashcat 모드(-m)도 함께 표시됩니다: MD5 0, NTLM 1000, SHA-1 100, SHA-256 1400, SHA-512 1700, bcrypt 3200, md5crypt 500, sha256crypt 7400, sha512crypt 1800, phpass 400, Drupal 7 7900, MySQL 4.1+ 300, Django PBKDF2-SHA256 10000.

키, 토큰, 식별자:

• PEM 블록(-----BEGIN ...-----): 개인 키(RSA, EC, OpenSSH, PKCS #8), 비밀번호로 보호된 개인 키, 공개 키, X.509 인증서, 인증서 서명 요청
• OpenPGP ASCII 아머: 암호화된 메시지(BEGIN PGP MESSAGE), 키 블록, 서명
• OpenSSH 공개 키(ssh-rsa, ssh-ed25519, ecdsa-sha2-...)
• JSON Web Token: 헤더를 디코딩해 alg와 typ을 보여 주며, enc 필드가 있는 다섯 부분짜리 토큰은 암호화된 JWE로 판단합니다
• UUID와 그 버전(해시가 아닌 식별자)

인코딩(더 구체적인 형식에 해당하지 않을 때만):

• 16진수, Base32, Base64, Base64url(디코딩된 길이를 바이트 단위로 표시) 및 URL(퍼센트) 인코딩.
• 디코딩된 길이가 16바이트의 배수인 16진수 또는 Base64 데이터는 AES 같은 블록 암호의 출력일 수 있으며, 128, 256, 384, 512바이트라면 RSA로 암호화된 데이터나 서명일 수도 있습니다. 16, 20, 28, 32, 48, 64바이트인 Base64 또는 Base32 데이터는 MD5, SHA-1, SHA-2의 원시 해시일 수 있습니다.

식별로 알 수 없는 것

• 100% 확실한 정확한 알고리즘. 64자리 16진수 문자열은 SHA-256 또는 SHA3-256으로 표시되지만, BLAKE2s를 비롯한 다른 256비트 해시도 똑같이 보입니다. MD5, MD4, NTLM 해시는 모두 16진수 32자입니다.
• 어떤 암호로 암호화했는지. 암호화된 데이터는 무작위처럼 보입니다. 길이는 후보를 좁혀 줄 뿐이므로 AES나 RSA는 가능성일 뿐 확실하지 않습니다.
• 키 강도. bcrypt 해시는 접두사에 코스트 팩터를 표시하지만($2y$10$ = 코스트 10), 실제 비밀번호 자체의 강도는 알려주지 않습니다.
• 솔트 적용 여부. 최신 비밀번호 해시(bcrypt, Argon2)는 항상 솔트가 적용되지만, 구형 방식(원시 MD5/SHA)은 적용될 수도, 그렇지 않을 수도 있습니다.
• 평문. 식별은 해시를 되돌리지 않습니다. 크래킹은 별도의 과정이며, 오직 자신의 데이터에 대해서만 합법적으로 수행할 수 있습니다.

식별이 틀리는 경우

• 사용자 지정 접두사가 붙은 토큰. 애플리케이션이 해시를 자체 접두사로 감싸는 경우가 있습니다. 먼저 그 래퍼를 제거하세요.
• 이중 인코딩. 바이너리 해시를 16진수화한 뒤 다시 Base64로 감싼 값은 잘못 식별됩니다. 한 번 디코딩한 뒤 다시 실행해 보세요.
• 흔하지 않은 길이. 잘린 해시(SHA-256의 앞 16자를 ID로 사용한 경우 등)는 위 표의 어떤 다이제스트 길이와도 맞지 않으므로 일반 16진수 데이터로 표시됩니다.
• 여러 값을 한꺼번에 넣은 경우. 한 번에 하나의 값만 확인합니다. 해시 목록을 붙여넣으면 첫 번째 줄만 확인하므로 나머지 값은 하나씩 붙여넣으세요.

사용 사례

• 보안 감사: 암호화 방식 마이그레이션에 앞서 코드베이스 전반의 해시 유형을 목록화합니다.
• CTF 챌린지: 알 수 없는 데이터에 대한 빠른 1차 점검.
• 인시던트 대응: 유출된 자격 증명의 형식을 식별합니다.
• 프레임워크 디버깅: 라이브러리가 어떤 인코딩을 생성하는지 파악합니다.

윤리적 유의 사항

해시 형식을 식별하는 것은 수동적인 조사에 불과합니다. 권한 없이 타인의 해시를 크래킹하는 행위는 대부분의 관할 지역에서 컴퓨터 오용 관련 법률을 위반합니다. 오직 자신이 소유하거나 분석 권한이 있는 해시만을 대상으로 하세요.