포스트

카카오 「MySQL 인증 플러그인 caching_sha2_password에 대한 이해」 리뷰 — 비밀번호 해시가 바뀌는 것보다 '평문이 서버까지 가야 한다'는 점이 전환의 진짜 비용

Tech Blog Review
게시
By August
좋아요 조회 9 분 읽는 시간

원문: MySQL 인증 플러그인 caching_sha2_password에 대한 이해 — kakao tech, 2025-07-17

한 줄 요약

MySQL 8.0부터 기본 인증 플러그인이 mysql_native_password(SHA-1 두 번)에서 caching_sha2_password(SHA-256 + 솔트 + 5,000회 반복)로 바뀌었고, 9.0부터는 옛 플러그인이 아예 없어진다. 해시가 강해진 것은 당연한 개선인데, 운영자에게 진짜 문제는 인증 프로토콜이 달라진다는 점이다. 옛 방식은 challenge-response라 평문 비밀번호가 네트워크를 안 탔지만, 새 방식은 첫 인증(Full Authentication) 때 평문 비밀번호가 서버까지 가야 하므로 SSL/TLS 또는 RSA 공개키 연결이 필수다. 커넥터 버전, 복제 계정, 그룹 복제 연결까지 바뀌는 이유가 여기 있다.

배경: 해시 알고리즘 한 줄 정리

MD5(128비트)는 충돌 공격에 약해 안 쓰고, SHA-1(160비트, 1995)도 비권장, SHA-2(2001, 224~512비트, Merkle-Damgård)가 널리 쓰이며 SHA-3(2015, Keccak 스펀지 구조)가 새 표준이다. MySQL의 새 플러그인은 SHA-256 기반이다. 원문은 이 배경을 표로 정리해 두었다.

플러그인 역사

버전기본 플러그인방식
1.0~4.0mysql_old_password자체 비트 연산, 16자리 hex
4.1~5.7mysql_native_passwordSHA1(SHA1(password)), * + 40자 hex
5.7.23 (선택)sha256_passwordSHA-256 + 솔트, SSL/TLS 또는 RSA 필수
8.0~caching_sha2_passwordsha256_password + 서버 측 캐시
9.0~(native 제거) 

sha256_password는 솔트로 같은 비밀번호도 다른 해시가 되게 했지만 매번 반복 해싱을 해야 해 느렸고, caching_sha2_password는 거기에 캐시를 붙여 재인증을 빠르게 한 것이다.

솔트는 비밀번호마다 고유하게 만드는 무작위 바이트(MySQL은 20바이트)로, 비밀은 아니지만 같은 비밀번호의 해시를 다르게 하고, 미리 계산한 해시 목록(레인보우 테이블)을 무력화하며, 사전·무차별 대입을 비밀번호마다 따로 해시하게 만들어 비용을 올린다.

mysql_native_password는 어떻게 인증하나

저장값은 SHA1(SHA1(password))다. 인증은 비밀번호가 네트워크를 타지 않는 challenge-response다.

  1. 클라이언트가 사용자명 등을 보낸다(비밀번호 원문 없음).
  2. 서버가 20바이트 무작위 문자열(scramble)을 보낸다.
  3. 클라이언트는 h1 = SHA1(pw), h2 = SHA1(h1), h3 = SHA1(scramble + h2)를 계산해 token = h1 XOR h3를 보낸다.
  4. 서버는 저장된 H_db = SHA1(SHA1(pw))로 s = SHA1(scramble + H_db)를 만들고, token XOR s로 h1을 복원해 SHA1(h1)이 H_db와 같은지 본다.

서버는 평문을 모른 채로 검증한다. 대신 SHA-1이고 솔트가 없다.

caching_sha2_password는 어떻게 저장하고 인증하나

저장. 비밀번호 생성·변경 시 고유 솔트를 만들고, 솔트 + 평문을 HMAC-SHA256 같은 PRF에 넣어 caching_sha2_password_digest_rounds(기본 5,000)만큼 반복한다(키 스트레칭). authentication_string은 $로 구분된다. A(플러그인 표시) · 005(5,000회) · 20바이트 솔트 인코딩 · 최종 해시.

Full Authentication. 처음 접속하거나 서버 캐시에 정보가 없을 때다. 클라이언트가 사용자명을 보내면 서버가 “이 계정은 caching_sha2_password”라고 알리고, 클라이언트는 두 경로 중 하나로 평문 비밀번호를 서버에 전달한다.

  • SSL/TLS: 암호화된 채널로 평문 전송. 서버가 솔트·반복 횟수로 해시해 저장값과 비교.
  • RSA: 서버가 공개키를 보내고, 클라이언트가 그것으로 평문을 암호화해 보내며, 서버가 개인키로 복호화한 뒤 위와 같이 비교.

즉 서버가 솔트를 섞어 5,000회 반복해야 하는 구조라 서버가 평문을 알아야만 검증할 수 있고, 그래서 채널 암호화가 필수다.

Fast Authentication. Full 인증에 성공하면 서버 메모리(플러그인 힙 영역)에 재인증용 정보가 캐시된다. 이후 재접속은 서버가 nonce를 보내고 클라이언트가 nonce와 비밀번호로 만든 값을 보내면 캐시로 검증한다. 평문도, 반복 해싱도 없다. 캐시는 MySQL 재시작, FLUSH PRIVILEGES, 계정 정보 변경 시 비워진다.

도입 시 고려할 것

연결 방식 결정. 이미 SSL/TLS나 RSA를 쓰고 있으면 고민이 없지만, 아니면 둘 중 하나를 골라야 하고 어느 쪽이든 운영 중인 MySQL에 영향이 간다. SSL/TLS로 간다면 서버 설정과 인증서 관리, 클라이언트 연결 방법, 복제용 계정과 연결 방법, 그룹 복제 연결 방법까지 파악해야 한다. 원문은 이 영향도는 주제를 벗어난다며 상세히 다루지 않는다.

인증 방식 변경의 영향. 두 가지를 정리해야 한다. caching_sha2_password를 지원하는 커넥터 버전, 그리고 기존 native 계정을 어떻게 전환할지. 메이저 업그레이드와 같이 진행한다면 전환 프로세스도 설계해야 한다. 계정 전환 시나리오는 서비스마다 달라 원문이 다루지 않는다.

8.0에서 native를 계속 쓰려면 --mysql_native_password=ON이나 default_authentication_plugin=mysql_native_password를 설정하면 되고, 8.4까지는 가능하지만 9.0부터는 불가능하다.

읽고 남는 질문

  • Fast Authentication에서 “nonce와 비밀번호로 만든 값”의 구체적 계산식이 native의 XOR 방식과 어떻게 다른지가 없다. 캐시에 무엇이 저장되는지(SHA-256 해시의 어떤 형태인지)가 보안 분석에 중요하다.
  • 캐시가 서버 메모리에 있으니 커넥션 풀이 새 커넥션을 만들 때마다가 아니라 서버 재시작·FLUSH PRIVILEGES 직후에 Full 인증이 몰린다. 대규모 앱 서버 재기동 시 5,000회 반복 해싱이 서버 CPU에 주는 부담이 실측으로 있으면 좋겠다.
  • 복제 계정 전환 순서(소스 먼저? 레플리카 먼저?)가 실무에서 가장 조심스러운 부분인데 “다루지 않는다”로 끝났다. 후속 글이 있으면 좋겠다.

한 줄로 가져가기

인증 플러그인 전환은 해시 함수를 바꾸는 일이 아니라 “서버가 평문을 알아야 하는 프로토콜”로 바꾸는 일이고, 그래서 TLS·RSA·커넥터·복제까지 한 번에 따라 움직인다. 9.0이 오기 전에 연결 방식부터 정해야 한다.

시리즈

빅테크 기술 블로그 리뷰

31편 중 29편

이전 시리즈 글 LINE 「LINE에서 Kafka를 사용하는 방법 - 1편」 리뷰 — 초당 4GB 클러스터가 바이트가 아니라 요청 수를 제한하는 이유, 그리고 2,000틱짜리 파이프라인에서 같은 것을 본 기록 다음 시리즈 글 LINE 「초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기」 리뷰 — 인터셉터와 시리얼라이저만으로 브로커에 평문을 남기지 않는 법
  1. 1 카카오 「실시간 메시징 시스템 개발기」(3편) 리뷰 — Redis에 몰린 부하를 서버로 옮기고, 그 서버를 pprof로 세 번 깎은 이야기
  2. 2 카카오 「추가배포 없이 API의 case 통일시키기」 리뷰 — 받는 쪽이 자기 케이스에 맞춰 알아서 읽게 하면 배포 순서가 사라진다
  3. 3 카카오 「MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석」 리뷰 — 바이트 단위 저장 구조부터 아직 안 고쳐진 Y2K38까지
  4. 4 네이버 D2 「6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기」 리뷰 — 복제·검증·복구를 셋으로 나누고, 옛 도구와 새 도구를 서로 모르게 같이 돌린 전환
  5. 5 카카오 「MySQL ALTER DDL 수행 방식에 대한 이해」 리뷰 — Copy·In-Place·Instant는 '무엇을 복사하느냐'보다 '언제 Exclusive 메타 락을 잡느냐'로 구분된다
  6. 6 카카오 「MySQL Orchestrator 기반의 새로운 HA 표준 개발기」 리뷰 — 10년 멈춘 Perl 도구를 떠나 Raft 클러스터로, 그리고 slave_net_timeout 한 줄
  7. 7 카카오 「MySQL Ver. 8.0 New Feature: Instant DDL Algorithm에 대한 이해」 리뷰 — 컬럼을 0.01초에 추가하는 대가는 '읽을 때마다 버전을 대조하는 것'이다
  8. 8 네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다
  9. 9 카카오 「MySQL InnoDB Log에 대한 이해 - (1)」 리뷰 — 트랜잭션 하나가 어떻게 MTR 여러 개로 쪼개져 Redo Log Buffer에 들어가는가
  10. 10 카카오 「PostgreSQL to ES: Kafka Connect CDC 파이프라인」 1·2편 리뷰 — 변경이 없어서 디스크가 차고, LSN이 사라져서 스냅샷을 다시 짜야 했던 CDC의 실제 운영 비용
  11. 11 LINE 「기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다」 리뷰 — 블랙박스는 입력과 출력만 정의하면 통계로 같음을 증명할 수 있다
  12. 12 뱅크샐러드 「게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락)」 리뷰 — 같은 WHERE version 조건인데, 충돌한 요청을 어떻게 하는가에서 갈리는 두 설계
  13. 13 우아한형제들 「Spring Batch와 Querydsl」 리뷰 — offset을 버린 Reader가 21분을 4분으로 만든 이유, 그리고 그 Reader가 답하지 않는 두 가지
  14. 14 네이버 D2 「테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴)」 리뷰 — 목이 많아지는 것은 테스트의 문제가 아니라 설계의 신호
  15. 15 당근 「QR을 찍으면 무슨 일이 벌어질까? 당근페이 현장 결제의 모든 것」 리뷰 — 카드망을 빌려 7주 만에 낸 결제와, 그 글이 다루지 않은 승인 응답이 사라지는 순간
  16. 16 네이버 D2 「스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기」 리뷰 — 두 DB에 동시에 쓰되 한쪽 실패는 무시하고, 읽기 트래픽을 복제해 성능을 재고, 6개월간 불일치를 0으로 만든 과정
  17. 17 야놀자 「RESTful API validation 자동화 하기」 리뷰 — 인터페이스 하나에서 검증·문서·타입을 뽑는 이유, 그리고 자동화가 없으면 누락이 필연이라는 문장
  18. 18 카카오 「MySQL Json 데이터 타입의 저장 구조와 성능 비교」 리뷰 — 통째로 넣고 통째로 꺼내면 TEXT, 키로 파고들면 JSON
  19. 19 LINE 「도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?」 리뷰 — 사용자를 모르는 채팅 플랫폼, 웹으로 만든 클라이언트, SOFT STOP으로 갈아 끼우는 챗봇 시나리오
  20. 20 카카오페이 「MSA 환경에서 네트워크 예외를 잘 다루는 방법」 리뷰 — Unknown을 타입으로 만든 글과, Unknown을 상태로 저장한 프로젝트가 갈리는 지점
  21. 21 카카오 「메시징 서버의 스트레스 테스트 노하우와 AI가 덜어 준 부분」 리뷰 — 지표를 네 층으로 내려가 읽는 법, 그리고 LLM에게 맡긴 것과 맡기지 못한 것
  22. 22 네이버 D2 「일 3,000만 건의 네이버페이 주문 메시지를 처리하는 Kafka 시스템의 무중단 전환 사례」 리뷰 — 두 벌로 발행해 대조한 검증기와, 발행 제어 키를 파티션 키와 같게 둔 이유
  23. 23 카카오 「잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정」 리뷰 — 벤더가 8ms 만에 리포트를 보냈고, 우리는 101ms짜리 트랜잭션 안에 있었다
  24. 24 컬리 「컬리의 입고 시스템이 외부 인입 데이터를 안전하게 동기화하는 방법」 리뷰 — 145회 재시도가 맞는 도메인과 재시도를 금지한 도메인, 그리고 발행부와 수신부가 각자 책임지는 구조
  25. 25 네이버 D2 「@RequestCache: HTTP 요청 범위 캐싱을 위한 커스텀 애너테이션 개발기」 리뷰 — 캐시의 수명을 '요청 하나'로 맞추면 TTL 고민이 사라진다, 그리고 @RequestScope가 안 되는 이유
  26. 26 무신사 「Kafka와 Strimzi를 이용하여 6개의 도메인을 하나의 도메인으로 합쳐보았습니다」 리뷰 — 배치 없이 CDC와 Kafka Streams로 옮긴 결정, 그리고 통합 모델이 원본과 같다는 것을 누가 확인하는가
  27. 27 쿠팡 「대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략」 리뷰 — 캐시 두 겹과 '분 단위 99.99% 동일'이라는 문장, 그리고 그 0.01%를 누가 어떻게 세는가
  28. 28 LINE 「LINE에서 Kafka를 사용하는 방법 - 1편」 리뷰 — 초당 4GB 클러스터가 바이트가 아니라 요청 수를 제한하는 이유, 그리고 2,000틱짜리 파이프라인에서 같은 것을 본 기록
  29. 29 카카오 「MySQL 인증 플러그인 caching_sha2_password에 대한 이해」 리뷰 — 비밀번호 해시가 바뀌는 것보다 '평문이 서버까지 가야 한다'는 점이 전환의 진짜 비용
  30. 30 LINE 「초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기」 리뷰 — 인터셉터와 시리얼라이저만으로 브로커에 평문을 남기지 않는 법
  31. 31 카카오뱅크 「하루 N억 건의 알림 시스템 구축기 (1)」 리뷰 — P99의 80%가 대기였다는 진단, Age 기반 Work-Stealing, 그리고 큐를 나누는 순간 순서를 잃는 문제
TechBlog, Kakao
Tech Blog Review Kakao MySQL Authentication SHA-256 TLS Security Database
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.

댓글

아직 댓글이 없습니다