권장 키 길이는 해시 출력의 길이에 해당합니다. SHA-1=20 바이트, SHA-256=32 바이트, SHA-384=48 바이트, SHA-512=64 바이트
온라인 HMAC 서명 생성 및 검증 도구. 일반적인 SHA 시리즈 알고리즘 지원. 인터페이스 서명, Webhook 검증 및 보안 연동에 적합.
일반 해시 함수(SHA256 등)는 메시지 자체의 다이제스트만 계산하므로 누구나 계산할 수 있습니다. HMAC은 해시 프로세스에 비밀 키를 도입하여 키를 가진 당사자만 유효한 서명을 생성하거나 검증할 수 있습니다. HMAC은 메시지 무결성과 인증을 모두 보장하는 반면, 일반 해시는 무결성만 검증합니다.
각 플랫폼은 서명을 다르게 포맷합니다: Stripe는 `Stripe-Signature` 헤더에 `t=timestamp,v1=hex_signature` 형식을 사용하며 `timestamp.payload` 문자열에 서명합니다; GitHub는 `X-Hub-Signature-256`에 `sha256=hex_signature` 형식을 사용합니다; Shopify는 `X-Shopify-Hmac-Sha256`에 Base64 인코딩 값을 사용합니다. 이 도구는 이러한 일반 형식에 대한 직접 검증을 지원합니다.
Hex는 16진수 형식(0-9, A-F)으로 사람이 읽을 수 있으며 디버깅에 적합합니다. Base64는 64자 인코딩으로 더 컴팩트하며 JSON에 임베딩하기에 이상적입니다. Base64URL은 URL 안전 버전(+/를 -_로 대체)으로 JWT 헤더 및 URL 매개변수에 사용됩니다.
**HMAC-SHA256을 권장합니다**: 현대 API 및 Webhook의 표준이며(Stripe, GitHub, Shopify, Slack에서 사용), 32바이트 출력과 범용 지원을 제공합니다. SHA-512는 더 높은 보안을 제공하지만 출력이 더 깁니다(64바이트). SHA1은 레거시 시스템에만 사용됩니다. MD5는 더 이상 사용되지 않으며 매우 오래된 API에만 사용해야 합니다.
키가 길수록 더 안전합니다. 최소 16자(128비트)를 권장하며, 프로덕션에서는 32자 이상을 권장합니다. 도구는 키 길이를 모니터링하고 너무 짧으면 경고합니다. 키에 대해 암호학적으로 안전한 난수 생성기를 사용하고, 간단한 비밀번호나 예측 가능한 문자열을 사용하지 마십시오.
일반적인 원인: 1) 메시지에 여분의 공백이나 줄바꿈이 포함됨; 2) 플랫폼이 복합 문자열에 서명함(예: Stripe는 `timestamp.payload`에 서명); 3) 서명에 제거해야 할 접두사가 포함됨(GitHub의 `sha256=` 등); 4) 다른 알고리즘이 사용됨. 양쪽에서 동일한 매개변수를 사용하는지 확인하십시오.
예. JWT의 HS256 알고리즘은 HMAC-SHA256이며, HS512는 HMAC-SHA512입니다. 이 도구의 HMAC-SHA256 출력은 HS256의 서명 콘텐츠로 직접 사용될 수 있습니다. JWT 헤더와 페이로드는 Base64URL로 인코딩된 다음 HS256으로 서명됩니다.
이 도구는 브라우저에서 모든 계산을 위해 Web Crypto API를 로컬로 사용합니다. 키와 메시지는 어떤 서버로도 전송되지 않습니다. 브라우저 개발자 도구의 네트워크 패널을 열어 이를 확인할 수 있습니다 — 외부 요청이 이루어지지 않습니다. 테스트 및 개발에 적합하며, 매우 민감한 프로덕션 키의 경우 로컬 오프라인 도구를 사용하십시오.
아니요. HMAC 보안은 키 비밀성과 해시 알고리즘의 충돌 저항성에 달려 있습니다. 충분히 길고 랜덤한 키를 사용하면 유효한 HMAC 서명을 위조할 수 있는 알려진 공격이 없습니다. 정기적인 키 로테이션은 좋은 보안 관행입니다.
HMAC(Hash-based Message Authentication Code)은 RFC 2104에 정의된 널리 사용되는 메시지 인증 기술입니다. HMAC은 키와 메시지를 해시 함수를 통해 처리하여 고정 길이의 서명을 생성합니다. 일반 해시와 달리 HMAC은 서명을 생성하거나 검증하려면 키를 알아야 하므로 메시지 무결성과 인증을 모두 보장합니다.
**HMAC은 현대 API 보안의 기초입니다**. Stripe, GitHub, Shopify, Slack 및 Twilio는 Webhook 이벤트에 HMAC-SHA256을 사용하여 요청이 실제로 플랫폼에서 왔는지 확인합니다. AWS는 Signature V4 요청 서명에 HMAC-SHA256을 사용합니다. JWT의 HS256 알고리즘은 본질적으로 HMAC-SHA256입니다. HMAC을 이해하는 것이 API 보안을 마스터하는 첫 번째 단계입니다.
**플랫폼마다 서명 형식이 다릅니다**: Stripe의 형식은 `t=timestamp,v1=hex_signature`이며 `timestamp.payload`에 서명합니다; GitHub는 `X-Hub-Signature-256`에 `sha256=hex_signature` 형식을 사용합니다; Shopify는 `X-Shopify-Hmac-Sha256`에 Base64 인코딩 값을 사용합니다. 이 도구는 이러한 일반 형식에 대한 자동 파싱 및 검증을 지원합니다.
**서명 검증이 실패하는 이유는 무엇입니까?** 가장 일반적인 이유는 메시지 형식 불일치입니다: 플랫폼이 원시 메시지 본문 대신 `timestamp.payload`에 서명할 수 있습니다; 또는 메시지에 여분의 줄바꿈이 포함됩니다; 또는 서명에 제거해야 하는 접두사(`sha256=` 등)가 포함됩니다. 플랫폼 문서를 주의 깊게 확인하고 원시 16진수 값을 사용하여 비교하십시오.
이 도구는 HMAC 계산을 위해 브라우저의 네이티브 **Web Crypto API**(SubtleCrypto)를 사용합니다 — HTTPS와 TLS를 구동하는 것과 동일한 암호화 라이브러리입니다. 모든 계산은 로컬에서 이루어지며, 키와 메시지는 어떤 서버로도 전송되지 않습니다. 브라우저 개발자 도구의 네트워크 패널을 열어 외부 요청이 이루어지지 않는지 확인할 수 있습니다.
