-
[이슈정리] 패스워드 암호화 시 매칭 오류IT/Spring 2025. 6. 13. 11:55
※ 상세이슈
Spring boot + MyBatis + Spring Security 사용시,
기존에 만들어둔 DB에 있는 계정으로 로그인시, 로그인이 안되는 이슈가 발생 하며,
‘Encoded password does not look like BCrypt’ 라는 로그가 찍힘.→ 서치시 패스워드 해시 함수(Password Hash Function)에 의해 일어나는 이슈로 확인됨,
기존에 만들어 놓은 계정의 비밀번호도 해시(Hash)된 값으로 하여 생성하였지만,
패스워드 해시 함수는 동일한 비밀번호여도 해시값이 늘 다르기 때문에 동일한 값으로 볼 수 없다.
그렇기 때문에 새로 회원가입을 하거나 계정을 임의로 만들어 주어 새로 생성해야지만 정상적으로 로그인 된다.
→ 추가적으로 알아봤을 때, 동일한 해시 함수를 사용한다는 가정하에 생성된 비밀번호는
*메서드를 통해 추출된 salt를 새로 해싱한 값과 기존 DB의 해시값을 비교하며 동일하면 로그인이 가능하다고 한다.
지금 실습용으로 만든 내 소스는 해당 메서드가 없어서, 비밀번호를 서로 다르게 인식한것으로 확인된다.
*메서드 : BCryptPasswordEncoder.matches();
발생과정
이전 프로젝트에서 사용한 DB에 있는 회원 정보로 로그인을 시도함. LoginService : 로그인 시도시 아이디를 통해 DB 조회를 시도한다. SecurityConfig : 로그인 시도한 계정을 내부 엔진을 통해 비교한다. *내부엔진 : BCryptPasswordEncoder.matches()
서버가동 후 기존 계정으로 로그인 실행시,
입력한 고객 아이디는 로그에 잘 찍히지만 에러 로그가 발생..
Encoded password does not look like BCrypt
찾아보니, BCrypt 로 생성된 비밀번호가 아닌것으로 체크하고 있다고함
결과
이전 실습에서도 동일한 이슈가 있었는데,
이번에도 BCrypt 로 생성된 비밀번호가 동일하지 않아서 나는 이슈였다.
이전 실습에서는
Spring Security안에 PasswordEncoder 인터페이스 구현체가 해시를 수행(해싱된 비밀번호 생성) 하는것으로 비밀번호를 등록하지 않고, GPT를 통해 새로 생성해서 DB에 등록시켰다.
그리고 해당 비밀번호로 로그인 시도시 로그인이 되지 않는 일이 발생했다.
찾아보니, Spring Security 에서 패스워드 해시 함수(Password Hash Function)를 통해 생성되는 비밀번호는
해싱 이전 같은 평문의 암호여도 해싱된 결과는 늘 다를수 있다는 거였다.
즉, 내가 외부에서 만들어온 비밀번호는, 내부에서 생성된 패스워드의 해싱된 값과 다를 수 있다는 것이였다.
그래서 다시 프로젝트 내부에서 암호를 재 생성 하고 로그인 하니, 정상적으로 진행되는것을 확인 했다.
해당 실습에서는
이전 실습에서 생성된 계정으로 로그인 하려고 하니, 해싱된 비밀번호 비교시 동일하지 않은것으로 체크되었던것
구현해 놓은 회원가입으로 다시 계정을 생성하고, 로그인을 실행하니 잘된다..!
GPT와 대화한 결과 정리
👉 질문
음 그렇다면 이렇게 이해하면될까?
계정은 하나야 그리고 프로젝트는 2개야
2개의 프로젝트는 하나의 DB를 바라보고 있어
계정은 프로젝트 A에서 생성됬고 프로젝트 B에서도 사용하고 싶어
그렇다면 프로젝트 B에서 로그인 할때 내부적으로 BCryptPasswordEncoder.matches() 라는 구문을 통해
프로젝트 A에서 생성된 계정의 비밀번호의 salt를 추출해서 다시 비교하는거야?
👉 답변
✅ 상황
- 프로젝트 A → 회원가입 → DB에 계정과 암호화된 비밀번호 저장 (BCrypt)
- 프로젝트 B → 같은 DB 사용
- 프로젝트 B → 로그인 시도
✅ 로그인할 때 내부 동작
- 프로젝트 B에서 로그인 시 사용자가 비밀번호를 입력함 → plain password
- BCryptPasswordEncoder.matches() 가 호출됨.
- 이 메서드는:
- DB에 저장된 암호화된 비밀번호 (A에서 생성된 hash) 를 보고
- 이 안에서 salt를 자동으로 추출함.
- 추출된 salt와 사용자가 입력한 비밀번호를 다시 해싱.
- 새로 해싱한 값과 기존 DB의 해시값을 비교.
- 같으면 → 로그인 성공!
✅ 결론
프로젝트가 몇 개든 상관없고
암호화된 값이 어느 프로젝트에서 생성됐든 상관없다.
단, BCrypt를 둘 다 쓰고 있으면 항상 일관된 비교가 가능하다.
✅ BCrypt의 핵심 철학
- salt를 따로 저장할 필요가 없다.
- 해시값 하나만 DB에 있으면 항상 검증 가능하다.
👉 그러니까
"프로젝트 B가 A의 해시값을 사용해서 salt를 추출해 비교"
→ ✔ 이해 완벽!
반응형'IT > Spring' 카테고리의 다른 글
[이슈정리] Session 으로 로그인 정보 가져오기 (0) 2025.06.12