Base64는 암호화인가?

짧은 답

아닙니다. Base64는 인코딩입니다. 어떤 데이터든 무해한 예순네 개의 문자만으로 적는 방법이고, 순수 텍스트용으로 지어진 시스템들을 통과해도 살아남게 하려는 것입니다. 키도 없고, 비밀도 없고, 어떤 종류의 보안 성질도 없습니다. 디코딩에 필요한 것은 알아보는 일뿐, 그 이상이 아닙니다 — 사람에게는 한 번의 눈길, 컴퓨터에게는 1밀리초.

그래도 물을 가치가 있습니다. 이 혼동은 어디에나 있고 가끔은 비싸니까요. base64 문자열은 뒤섞인 것처럼 보입니다 — cGFzc3dvcmQ=는 눈에 아무것도 말해 주지 않습니다 — 그리고 뒤섞여 보이는 것은 “안전함” 서랍에 들어갑니다. 실제 제품들이 이런 식으로 “보호된” 비밀번호를 싣고 출시된 적이 있습니다. 치료제는 한 번 배워 두는 구별입니다. 인코딩은 기계를 위한 것, 암호화는 비밀을 위한 것, 해시는 지문을 위한 것. 세 가지 일, 세 가지 도구, 그중 무언가를 지키는 것은 하나뿐입니다.

인코딩: 누구나 되돌린다

인코딩은 데이터가 적히는 방식을 바꿀 뿐, 데이터가 말하는 바는 결코 바꾸지 않습니다. 이메일 첨부, 스타일시트에 박아 넣은 이미지, 주소 속 토큰 — 어디서든 임의의 바이트가 텍스트만 확실히 나르는 통로를 지나야 하고, base64가 그 표준 의상입니다. 바이트 셋이 들어가면 글자·숫자·기호 둘로 이루어진 문자 넷이 나오고, 끝은 =로 채워집니다. 그 끝의 =가 표식이고, 한 번 알고 나면 base64가 어디에나 보입니다.

모든 것을 결정하는 성질은 이렇습니다. 조리법은 공개돼 있고, 거꾸로도 똑같이 돌아갑니다. 알아야 할 것이 없으니, 모를 수 있는 것도 없습니다. 주소의 퍼센트 인코딩(공백의 %20), HTML 엔티티(&), 16진수 표기, 역슬래시 이스케이프는 같은 생각의 다른 옷이고, 여기의 Base64 인코더·디코더는 그 모두를 양방향으로, 당신의 기계 위에서 말합니다. 발견한 문자열을 디코딩하는 일은 그것을 읽는 일과 정확히 똑같이 정당합니다. 인코딩은 애초에 자물쇠였던 적이 없으니까요.

암호화: 키를 가진 사람만 되돌린다

내용을 실제로 지키는 쪽은 암호화입니다. 데이터를 키로 변환하고, 수학은 키 없이 변환을 되돌리는 일이 그저 어려운 게 아니라 계산상 손이 닿지 않게, 그러나 키가 있으면 즉시 되게 짜여 있습니다. 비밀은 온전히 키에 살지, 방법에 살지 않습니다. 알고리즘은 공개되고 표준화되어 있으며, 바로 그래서 강합니다.

시각적 혼동이 무는 지점이 여기입니다. 암호화된 바이트는 여행할 수 있도록 으레 base64로 인코딩됩니다 — 먼저 키로 뒤섞고, 그다음 수송용 옷을 입힙니다. 두 겹, 두 가지 일. JSON Web Token이 교과서 사례입니다. 점으로 이어진 base64 조각 셋 중 앞의 둘은, 시도하는 누구에게나 읽히는 JSON으로 디코딩됩니다. 전체가 봉인된 줄 알고 공개 웹 디코더에 토큰을 붙여넣는 사람이 매일 있습니다. 정직한 묘사는 이렇습니다. JWT는 위조 방지 서명이 붙은 엽서이지, 봉투가 아닙니다.

해시: 아무도 되돌리지 못한다

해시는 한 방향으로만 달립니다. 아무리 많은 데이터든 SHA-256에 통과시키면 고정 크기의 수 하나가 나옵니다 — 같은 데이터에는 매번 같은 수, 한 비트만 달라도 완전히 다른 수, 그리고 수에서 데이터로 돌아가는 길은 키가 있든 없든 누구에게도 없습니다. 옷도 아니고 자물쇠도 아닌, 지문입니다.

그것이 해시를 제 소유의 두 가지 일에 맞는 도구로 만듭니다. 내려받은 파일이 발행자가 공개한 바로 그 파일인지 확인하기 — 지문을 맞대 보는 일이고, 해시·체크섬 도구가 당신의 기계에서 해 주며, 전용 가이드도 있습니다. 그리고 비밀번호 보관하기. 제대로 운영되는 서비스는 당신 비밀번호의 해시만 보관해서, 도둑맞은 데이터베이스조차 비밀번호 자체는 담고 있지 않습니다. 잊은 비밀번호를 이메일로 보내 줄 수 있는 사이트는 한 번도 해시하지 않았다고 자백한 것이고, 설정 파일이 제 비밀번호를 cGFzc3dvcmQ=로 “보호”하고 있다면 인코딩밖에 하지 않았다고 자백한 것입니다.

현장에서 셋을 구별하기

눈앞의 문자열에 통하는 지름길입니다.

• 디코딩했더니 읽히는 것이 나온다? 인코딩이었던 겁니다. 글자와 숫자, 어쩌면 +와 /, 흔히 끝에 = — 디코더에 통과시키고 보십시오.
• 디코딩했더니 이진 잡음이 나온다? 그렇다면 base64는 옷일 뿐이고, 그 밑은 암호화됐거나, 압축됐거나, 애초에 텍스트가 아니었던 것입니다 — 어느 쪽이든 인코딩은 아무것도 말해 주지 않습니다.
• 고정 길이, 16진수 문자, 결코 디코딩되지 않는다? 16진수 64자는 SHA-256의 윤곽이고, 32자는 MD5의 윤곽입니다. 해시는 디코딩되지 않습니다. 일치하거나, 일치하지 않거나뿐입니다.

그리고 각각의 실무 교훈. 비밀을 인코딩에 맡기지 말 것. 플랫폼이 암호화를 실어 주는데 직접 만들지 말 것. 비밀번호를 해시 아닌 것으로 저장하지 말 것. 한편, 확인하려고 디코딩하는 그 문자열 자체가 민감한 부분일 때가 많습니다 — 디버깅 중인 토큰이 대개 그렇습니다 — 여기의 디코더가 비밀이 이미 있는 곳, 즉 당신의 기계에서 도는 이유가 그것이고, 웹 도구에 붙여넣기가 실제로 하는 일에 제 페이지가 있는 이유도 같습니다.