텍스트 해시 계산(SHA-256 · SHA-1)
텍스트나 비밀번호의 SHA-256, SHA-1 해시값을 브라우저에서 즉시 계산합니다. 서버로 전송되지 않습니다.
(텍스트를 입력하세요)
(텍스트를 입력하세요)
📖 자주 걸리는 지점
Web Crypto API 를 사용해 입력한 텍스트의 SHA-256 과 SHA-1 을 브라우저 안에서 계산합니다. 입력은 전송되지 않습니다. 해시는 암호화가 아닙니다 — 되돌릴 열쇠가 없는 것이 아니라 애초에 되돌리기 위한 정보가 버려져 있는 함수입니다. 다만 이것이 안전하다는 의미는 아닙니다 — 입력의 후보가 한정되어 있다면 하나하나 계산해 맞춰 보는 것만으로 원래 값은 밝혀집니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| 비밀번호 저장에 SHA-256 을 써 버린다 | SHA-256 은 빠른 것을 목적으로 설계된 함수입니다. 파일의 정합성을 확인하는 데는 빠를수록 좋지만 비밀번호 저장에 쓰면 그 빠름이 그대로 공격자의 무기가 됩니다 — 현대의 GPU 는 1 초에 수십억 회의 SHA-256 을 계산할 수 있으므로 영숫자 8 자의 비밀번호는 전수 조사로 몇 시간 이내에 뚫립니다. 솔트를 붙여도 사정은 달라지지 않습니다 — 솔트는 레인보우 테이블을 무효화하고 같은 비밀번호가 같은 해시가 되는 것을 막을 뿐이며 한 건씩의 전수 조사의 속도에는 전혀 영향을 주지 않습니다. | 비밀번호에는 bcrypt / scrypt / Argon2id 를 쓰세요. 이들은 의도적으로 느리고 또한 대량의 메모리를 요구하도록 설계되어 있습니다 — 메모리를 먹는다는 성질이 중요하며 GPU 는 연산기의 수에 비해 메모리가 적으므로 병렬화의 이점을 지울 수 있습니다. SHA-256 에 솔트를 더해 1 만 번 반복한다는 자작 설계는 그만두세요 — 발상은 옳지만 그것은 PBKDF2 로 이미 표준화되어 있고 자작 구현은 반드시 어딘가에서 틀립니다. 2026 년 시점의 권장은 Argon2id, 언어나 프레임워크에 없다면 bcrypt 입니다. |
| 같은 문자열인데 다른 도구와 값이 다르다 | 해시 함수가 받는 것은 바이트열이지 문자가 아닙니다. 따라서 같아 보이는 텍스트라도 바이트열이 1 바이트라도 다르면 결과는 완전히 별개가 됩니다. 실무에서 어긋나는 원인은 거의 이 네 가지입니다 — 끝의 줄바꿈, 줄바꿈 코드가 LF 인지 CRLF 인지, BOM 의 유무, 문자 코드가 UTF-8 인지 아닌지. 특히 전형적인 것이 셸로 echo "abc" | sha256sum 은 줄바꿈을 포함한 4 바이트의 해시를 돌려줍니다 — abc 의 3 바이트가 아닙니다. |
셸에서는 printf %s abc | sha256sum 을 쓰세요 — 여분의 바이트가 붙지 않습니다(echo -n 은 환경에 따라 동작이 다르므로 피합니다). 어긋났을 때는 먼저 양쪽의 바이트 수를 세어 보세요 — wc -c 나 xxd 로 1 바이트의 차이는 금방 찾을 수 있습니다. API 의 서명 검증이 맞지 않는 경우도 원인은 거의 같습니다 — 서명 대상의 문자열을 조립하는 순서, 구분 문자, 끝의 줄바꿈, 그리고 JSON 을 다시 직렬화한 것으로 키 순서나 공백이 바뀌지 않았는지를 확인하세요. 같을 것이라고 여기지 말고 실제 바이트열을 맞춰 보는 것이 유일한 해결법입니다. |
| SHA-1 을 그대로 계속 쓰고 있다 | SHA-1 의 충돌은 이론상의 이야기가 아닙니다 — 2017 년에 Google 과 CWI 가 내용이 다른 두 개의 PDF 가 같은 SHA-1 이 되는 실례를 공개했습니다(SHAttered). 2020 년에는 선택 접두사 충돌이 현실적인 비용으로 가능해졌으며 이는 임의의 두 문서를 각각 원하는 내용 그대로 두고 충돌시킬 수 있다는 훨씬 강한 공격입니다. Git 이 지금도 SHA-1 을 쓰고 있는 것은 충돌을 만들 수 있다는 것과 Git 을 공격할 수 있다는 것이 별개의 문제이기 때문이지 SHA-1 이 안전해서가 아닙니다. | 새로 만드는 것은 모두 SHA-256 이상으로 하세요. 기존의 SHA-1 에 대해서는 용도로 판단하세요 — 변조 탐지 · 서명 · 인증서에 쓰고 있다면 이행이 필요하지만 ETag · 캐시 키 · 샤딩처럼 충돌해도 곤란하지 않은 용도라면 서두를 이유는 없습니다. 이 구별이 중요하며 모든 SHA-1 을 일률적으로 교체하려 하면 정말로 위험한 곳에 손이 미치지 않게 됩니다. 판단의 기준은 공격자가 의도적으로 충돌시켰을 때 무언가 이득을 보는가 한 가지입니다 — 이득이 없다면 두어도 되고 이득이 있다면 최우선으로 고치세요. |
해시화했으니 익명화했다는 취급은 성립하지 않습니다. 메일 주소나 전화번호의 SHA-256 을 개인정보가 아닌 것으로 공유하는 것은 위험합니다 — 전화번호는 후보가 유한(일본의 휴대전화라면 10 억 가지가 채 안 됨)하므로 전부 계산해 맞춰 보면 몇 분이면 원래대로 돌릴 수 있습니다. 메일 주소도 알려진 주소 목록과 대조하면 마찬가지입니다. 이는 광고 업계에서 실제로 문제가 된 경로이며 해시화는 입력의 후보가 사실상 무한한 경우에만 익명화가 됩니다. 굳이 대조용 식별자가 필요하다면 비밀 키를 섞은 HMAC 를 쓰세요 — 키를 모르는 쪽은 전수 조사를 할 수 없게 됩니다(다만 키 관리라는 별도의 책임이 생깁니다). 해시를 ID 로 공개하는 설계를 채택하기 전에 그 입력 공간을 전부 계산하는 데 몇 시간이 걸리는지를 실제로 어림잡아 보세요.
📖 사용법
-
1
해시할 텍스트 입력입력란에 텍스트를 입력하면 실시간으로 SHA-256, SHA-1 해시값이 계산됩니다.
-
2
해시값 확인SHA-256(256비트)과 SHA-1(160비트) 해시값이 표시됩니다.
-
3
복사 후 사용복사 버튼으로 해시값을 복사합니다.
❓ 자주 묻는 질문
SHA-256과 SHA-1 중 어느 것을 사용해야 하나요?
해시값은 단방향인가요?
입력 데이터가 서버로 전송되나요?
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.