해시, HMAC, 암호화, JWT를 브라우저에서 확인할 수 있습니다. 입력 데이터를 외부로 보내지 않고 목적에 맞는 알고리즘을 선택하는 것이 중요합니다.
해시 함수는 길이가 다른 입력에서 고정 길이의 다이제스트를 만듭니다. 같은 바이트는 같은 결과를 만들지만 줄바꿈 하나만 달라도 결과가 바뀔 수 있습니다. 해시 생성기로 체크섬과 시험 데이터를 비교할 수 있습니다.
MD5는 128비트, 즉 16진수 32자를, SHA-1은 160비트를 출력합니다. 둘 다 알려진 충돌 공격이 있으므로 새 서명이나 공격자를 상정한 무결성 검사에 사용하지 않습니다. MD5는 우발적 변경 검사에는 여전히 쓰이기도 합니다.
SHA-256과 SHA-512는 SHA-2 계열로 각각 256비트와 512비트를 출력합니다. SHA-512는 구현에 따라 64비트 하드웨어에서 빠를 수 있습니다. 빠른 해시만으로 비밀번호를 저장하지 말고 솔트와 함께 Argon2id, scrypt 또는 적절히 설정한 bcrypt를 사용하세요.
HMAC은 해시 함수와 공유 비밀 키를 결합합니다. 올바른 결과는 내용의 무결성과 키를 알고 있음을 보여 주지만 공개적인 신원 증명은 아닙니다. HMAC 생성기로 개발 중 서명을 재현할 수 있습니다.
AWS Signature Version 4는 HMAC-SHA256, 파생 키, 정규화된 요청을 사용합니다. 메서드, 경로, 헤더, 본문 해시를 규격에 따라 처리해야 하며 본문만 해싱해서는 유효한 AWS 서명이 되지 않습니다.
GitHub 웹훅은 X-Hub-Signature-256을 사용합니다. Stripe는 Stripe-Signature를 사용하며 계산에 타임스탬프를 포함합니다. 요청의 원본 바이트를 검증하고 서명을 상수 시간으로 비교하며 재전송 공격도 방어하세요. JWT HS256도 HMAC-SHA256을 사용합니다.
AES는 같은 비밀 키로 암호화와 복호화를 하는 대칭 방식입니다. 키 길이뿐 아니라 모드도 중요합니다. AES-GCM은 인증 태그를 사용하며 같은 키로 nonce를 재사용하면 안 됩니다. AES 도구에서 시험 사례를 확인할 수 있습니다.
RSA는 공개 키와 개인 키를 사용합니다. 크기 제한과 처리 비용 때문에 큰 파일 전체보다 임의의 대칭 키를 암호화하는 데 주로 사용합니다. 실제 데이터는 AES가 처리합니다.
패딩 없는 RSA는 사용하지 마세요. RSA 도구는 RSA-OAEP를 사용합니다. 상호 운용할 때 해시 매개변수와 키 형식을 맞춰야 합니다. RSA-OAEP 암호화와 RSA 서명은 다릅니다. 개인 키와 복호화된 데이터를 보호하세요.
간결한 JWS 형식의 서명된 JWT는 점으로 나뉜 헤더, 페이로드, 서명의 세 Base64url 부분으로 구성됩니다. {"alg":"HS256","typ":"JWT"}는 HMAC-SHA256을 뜻하고 RS256은 SHA-256을 사용하는 RSA 서명입니다.
페이로드에는 주체인 sub, 발급자인 iss, 수신자인 aud, 만료인 exp, 발급 시각인 iat 등이 있습니다. JWT 디코더로 읽을 수 있지만 디코딩은 서명 검증이나 토큰을 받아들여도 된다는 증명이 아닙니다.
서버에서 허용 알고리즘을 고정하고 서명, 발급자, 수신자, 만료를 검증하세요. 토큰의 alg를 무조건 신뢰하거나 none을 실수로 허용하지 마세요. JWS 서명은 페이로드를 암호화하지 않으므로 기밀성이 필요하면 JWE 같은 방식이 필요합니다.
안 됩니다. SHA-256은 빠른 범용 해시이기 때문에 비밀번호를 무차별 대입으로 쉽게 뚫을 수 있습니다. 대신 bcrypt, scrypt 또는 Argon2를 사용하세요 — 이들은 느리고 메모리를 많이 사용하도록 설계되었습니다. Password Generator는 강력한 비밀번호를 생성하며, 저장은 서버에서 bcrypt/Argon2를 사용해야 합니다.
인코딩(Base64 등)은 호환성을 위해 데이터를 변환하며 — 키 없이도 되돌릴 수 있습니다. 암호화(AES 등)는 기밀성을 보호하며 — 올바른 키가 있어야만 되돌릴 수 있습니다. Base64를 보안 수단으로 절대 사용하지 마세요.
JWT 디코더에서 exp를 읽고 현재 Unix 시각과 비교하세요. 만료되지 않았다고 서명이 유효한 것은 아닙니다. 서버에서 서명, 발급자, 수신자도 검증해야 합니다.
네, crypto.getRandomValues()를 사용할 때는 안전하며, Password Generator가 바로 이것을 사용합니다. 이는 브라우저의 CSPRNG로, 운영체제가 키 생성에 사용하는 것과 동일한 엔트로피 소스입니다.
모든 새 애플리케이션에는 AES-256을 사용하세요. AES-128도 알려진 공격에 대해 기술적으로 안전하지만, AES-256은 더 큰 여유를 제공합니다. 최신 하드웨어에서는 성능 차이가 무시할 수준입니다.