fix: 비밀번호 복잡도 규칙을 한 곳으로 — 변경 화면 우회 차단

[seizeh]

2026-08-01 에 작업해 두고 푸시하지 않은 채 로컬에만 있던 브랜치다(45커밋 뒤처져 있어 main 위로 체리픽했다). 그동안 구멍은 열려 있었고 수정본은 이 머신에만 있었다.

무엇이 문제였나

세 화면이 각자 검사를 갖고 있다가 규칙이 서로 갈렸다.

화면	검사	문제
가입	길이 8자만	화면 힌트는 "영문 + 숫자 포함 8자 이상" 인데 검사는 길이만 — 안내와 검사가 어긋나 서버가 거절할 비밀번호를 통과시켰다
재설정	8자 + 영문 + 숫자	서버와 일치 (정상)
변경	6자만	구 app._set_password 정책 잔재. 가입에서 막은 단순 비밀번호를 '변경'으로 우회할 수 있었다

서버도 change-password 만 6자였다.

조치

lib/utils/password_rule.dart 를 정본으로 두고 세 화면 + AuthResult 문구가 같은 상수를 쓰게 했다. 힌트(kPasswordRuleHint)와 에러 문구(kPasswordRuleMessage)도 한 곳에서 나오므로, 안내와 검사가 다시 갈릴 수 없다.

클라이언트는 사본이고 정본은 서버다. 여기 검사는 서버 왕복 전에 알려주기 위한 것이고, 실제 차단은 엣지 함수 세 개가 각각 재검증한다. 그래서 서버 쪽도 같은 규칙으로 맞추는 짝 PR 이 필요하다 — 클라이언트만 조이면 API 직접 호출로 그대로 뚫린다.

이 버그가 테스트에 화석으로 남아 있었다

expect(msg('weak_password'), '새 비밀번호는 6자 이상이어야 해요');

기존 테스트가 옛 문구를 못 박아 두고 있었다. 즉 테스트가 버그를 지키고 있었던 셈이라 함께 갱신하고, 회귀 가드 13건을 새로 넣었다(특히 "6자는 거부").

검증

• flutter test 275건 통과(신규 13건 포함), analyze 0, format 0
• catch (_) 104 — 래칫 104 와 동일(추가 없음)
• lib/ 에 남은 6자 검사 0건 확인

머지 순서 — 이 PR 이 먼저

짝 PR: pmdb fix/change-password-complexity(서버 change-password 를 8자+영숫자로).

서버를 먼저 머지하면 그 사이 앱은 여전히 6자를 통과시키고, 사용자는 서버 weak_password 를 받는데 앱이 그걸 "6자 이상이어야 해요" 로 안내한다 — 무엇을 고쳐야 할지 알 수 없는 상태가 된다. #255 → #151 과 같은 이유의 순서다.

🤖 Generated with Claude Code