개발 이야기3분 읽기

Base64는 암호화가 아니다

Base64는 키 없이 누구나 되돌릴 수 있는 인코딩입니다. 인코딩·해시·암호화의 차이와 Base64를 실제로 쓰는 자리를 정리했습니다.

YWRtaW46cGFzc3dvcmQxMjM= 같은 문자열은 언뜻 암호문처럼 보입니다. 실제로는 admin:password123이고, 되돌리는 데 키가 필요 없습니다.

Base64가 하는 일

Base64는 임의의 바이트를 영문 대소문자·숫자·기호 두 개, 모두 64개 문자로 바꾸는 변환입니다. 3바이트를 4글자로 옮기므로 결과는 원본보다 약 33% 커집니다. 길이가 맞지 않으면 끝에 =를 붙여 채웁니다.

목적은 하나입니다. 텍스트만 통과하는 통로로 바이너리를 보내는 것.

  • 이메일 첨부(MIME) — 본문이 텍스트만 다룹니다
  • JSON에 이미지나 파일 담기
  • HTML·CSS의 data: URI
  • HTTP 헤더 — 줄바꿈이나 제어문자가 들어가면 안 됩니다

변환은 세 종류다

이름이 섞여 쓰이는 일이 많아 한 줄로 구분하면 이렇습니다.

되돌릴 수 있나 키가 필요한가 쓰는 곳
인코딩 (Base64, URL, Hex) 아니오 형식 맞추기
해시 (SHA-256, bcrypt) 아니오 아니오 무결성, 비밀번호 저장
암호화 (AES, RSA) 내용 감추기

Base64는 첫 줄입니다. 키가 필요 없다는 칸이 핵심입니다. 값을 손에 넣은 사람은 누구나 원문을 볼 수 있습니다.

안전해 보이는 자리들

몇 가지는 실제 시스템에서 그대로 쓰이고 있어서 오해를 부릅니다.

HTTP Basic 인증Authorization: Basic 뒤에 오는 값은 아이디:비밀번호를 Base64로 인코딩한 것입니다. 감추는 장치가 아니라 헤더에 넣을 수 있는 형태로 바꾼 것뿐입니다. 이 방식이 그나마 쓸 만한 것은 HTTPS가 통신 구간 전체를 암호화하기 때문입니다.

JWT — 헤더와 페이로드는 Base64url입니다. 누구나 읽을 수 있고, 서명은 내용을 감추는 것이 아니라 변조를 막는 장치입니다.

설정 파일의 인코딩된 값 — 비밀번호를 Base64로 넣어 두면 화면에서 눈에 덜 띌 뿐, 파일을 읽을 수 있는 사람에게는 평문과 같습니다.

Base64url

URL이나 파일명에 들어갈 때는 조금 다른 표를 씁니다.

  • +-, /_
  • 끝의 = 패딩은 대개 생략합니다

/가 경로 구분자로, +가 공백으로 해석되는 문제를 피하기 위한 것입니다. JWT와 WebAuthn 같은 곳에서 씁니다. 일반 Base64 디코더에 넣으면 실패하거나 깨진 결과가 나오므로, 값에 -_가 보이면 이쪽을 먼저 의심합니다.

실제로 감춰야 한다면

  • 전송 중 — HTTPS(TLS). 별도로 할 일이 거의 없습니다
  • 저장할 때 — AES-GCM 같은 인증된 암호화. 키는 코드가 아니라 키 관리 서비스나 환경변수에 둡니다
  • 비밀번호 — 암호화가 아니라 bcrypt나 Argon2로 해시합니다. 되돌릴 수 없어야 맞습니다

Base64는 이 셋 중 어디에도 들어가지 않습니다. 암호화한 결과를 텍스트로 옮길 때 그 뒤에 한 번 더 적용될 뿐입니다.

알아보는 법

  • 끝에 = 또는 ==가 붙어 있다
  • 길이가 4의 배수다
  • A-Z a-z 0-9 + / 만 나온다
  • 점으로 나뉜 세 덩어리라면 JWT입니다

tools.onuel.dev에서 Base64 인코딩디코딩을 할 수 있고, 실제로 감춰야 할 때 쓰는 AES도 같은 자리에 있습니다. 모두 브라우저 안에서 처리되어 입력한 값이 서버로 가지 않습니다.

  • #Base64
  • #인코딩
  • #보안