포스트

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

Tech Blog Review
게시 수정 작성자 August
좋아요 조회 11 분 읽는 시간
시리즈 빅테크 기술 블로그 리뷰 32편 중 29편 빅테크 기술 블로그 리뷰
  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, 그리고 큐를 나누는 순간 순서를 잃는 문제
  32. 32 Airbnb 「Avoiding double payments in a distributed payments system」 리뷰 — 네트워크와 DB 트랜잭션을 섞지 않는 세 단계, 재시도 가능 여부의 분류, 그리고 복제본을 읽으면 이중 결제가 나는 이유

원문: 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.6 (선택)sha256_passwordSHA-256 + 솔트, SSL/TLS 또는 RSA 필수
8.0~caching_sha2_passwordsha256_password + 서버 측 캐시
9.0~(native 제거) 

원문에 따르면 caching_sha2_password는 5.7.23에 선택 사항으로 도입됐고 8.0부터 기본값이 됐다. 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회)를 적용해 해시를 다시 계산한다고 설명한다. 나는 이것을 검증에 평문이 필요하니 채널 암호화가 필수가 되는 구조로 읽는다. MySQL 문서는 이때의 안전한 연결에 TLS를 쓴 TCP 외에 Unix 소켓 파일과 공유 메모리도 포함한다.

Fast Authentication은 그다음이다. Full 인증에 성공하면 서버 메모리(플러그인 힙 영역)에 재인증용 정보가 캐시된다. 이후 재접속은 서버가 nonce(한 번만 쓰는 무작위 값)를 보내고 클라이언트가 nonce와 비밀번호로 만든 값을 보내면 캐시로 검증한다. MySQL 문서는 이 경로를 이렇게 설명한다. “When the cache can be used, the server uses a challenge-response mechanism that does not use cleartext password transmission and does not require a secure connection.” (캐시를 쓸 수 있을 때 서버는 평문 전송이 없고 안전한 연결도 요구하지 않는 challenge-response를 쓴다.) 캐시는 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으로 올리기 전에 연결 방식부터 정해야 한다.

참고한 자료외부 출처 2

외부 출처

TechBlog, Kakao
Tech Blog Review Kakao MySQL Authentication SHA-256 TLS Security Database
데이터베이스 내부와 트랜잭션
이 글은 저작권자의 CC BY 4.0 라이선스를 따릅니다.

변경이력

2번 수정

  1. docs(posts): separate the sections of every post with a thematic break
  2. docs(techblog): cite sources and ease reading in kakao-mysql-caching-sha2-password

댓글

아직 댓글이 없습니다