패스워드 보안의 기본
패스워드 보안의 기본
서론
보안 이야기를 할 때 비밀번호(패스워드)는 가장 먼저 떠오르는 요소 중 하나입니다.
하지만 실제로는 "123456", "password" 같은 약한 비밀번호가 여전히 많이 쓰이고 있고,
개발자조차도 패스워드를 안전하게 다루는 방법을 제대로 배우지 못한 경우가 많습니다.
이 글에서는 초보 개발자의 관점에서,
패스워드 보안을 사용자 입장과 서비스 개발자 입장으로 나누어 정리해 보겠습니다.
1. 사용자 입장에서의 패스워드 보안
1.1 강한 비밀번호란?
일반적으로 다음과 같은 특징을 갖습니다.
- 길이가 충분히 길다 (최소 12자 이상 권장)
- 대문자/소문자/숫자/특수문자를 섞어 사용
- 사전에 있는 단어 하나로 끝나지 않음
하지만 현실적으로:
- 이런 비밀번호를 직접 외우고 여러 사이트에서 다르게 쓰는 것은 거의 불가능에 가깝습니다.
그래서 가장 현실적인 해법은:
- 패스워드 매니저(비밀번호 관리 앱) 를 사용하는 것입니다.
1.2 절대 하면 안 되는 습관
- 여러 사이트에서 같은 비밀번호 재사용
- 아이디와 비밀번호를 메모장/노션 등에 평문으로 저장
- 쉬운 규칙(예:
password1,password2, …)으로만 바꾸기
한 사이트에서 정보가 유출되면:
- 같은 비밀번호를 쓰는 다른 서비스 계정까지 줄줄이 털릴 수 있습니다.
2. 개발자 입장에서의 패스워드 보안
2.1 절대 평문 저장 금지
가장 기본이자 절대적인 원칙:
- 데이터베이스에 사용자 비밀번호를 평문으로 저장하면 안 됩니다.
대신:
- 단방향 해시 함수 + 솔트(salt) 를 사용해야 합니다.
대표적인 해시 함수/알고리즘:
- bcrypt
- scrypt
- Argon2
이런 알고리즘은:
- 느리게 설계되어 있어
- 공격자가 무차별 대입(브루트포스) 공격을 하기 어렵게 만듭니다.
2.2 해시 과정의 기본 아이디어
간단히 요약하면:
- 사용자가 비밀번호를 입력
- 서비스는 그 비밀번호에 솔트(추가 문자열) 를 섞어서 해시 함수에 넣음
- 해시 결과만 DB에 저장
- 로그인 시에도 같은 과정을 거쳐 나온 해시 값이 DB 값과 같으면 인증 성공
이렇게 하면:
- 데이터베이스가 털리더라도,
- 공격자는 해시 값만 가져갈 수 있고,
- 원래 비밀번호를 알아내기가 훨씬 어려워집니다.
2.3 비밀번호 정책과 UX의 균형
비밀번호 정책을 너무 엄격하게 하면:
- 사용자가 오히려 기억하기 힘든 규칙 때문에
- 비밀번호를 메모장에 적어 두거나
- 규칙을 예측하기 쉬운 방식으로 만들기도 합니다.
그래서:
- 적당한 길이 요구(예: 최소 10~12자)
- 너무 과한 특수문자 조합 강제보다는
- 패스워드 매니저 사용을 권장하는 메시지 등
보안과 사용성의 균형을 같이 고민하는 것이 중요합니다.
3. 추가적으로 고려할 점
3.1 2단계 인증(2FA/MFA)
패스워드만으로는 부족할 때:
- OTP 앱(예: Google Authenticator)
- SMS/이메일 코드
- FIDO 키/보안 키
같은 두 번째 인증 수단을 추가하면 보안 수준이 크게 올라갑니다.
3.2 비밀번호 초기화/재설정 절차
비밀번호 재설정 기능을 만들 때도:
- "본인임을 충분히 확인했는가?"
- "재설정 링크/코드의 유효기간은 짧게 설정했는가?"
- "한 번 사용한 토큰은 다시 쓸 수 없도록 막았는가?"
같은 부분을 반드시 고려해야 합니다.
마무리
패스워드 보안은 오래된 주제이지만,
여전히 많은 사고의 출발점이 되는 영역입니다.
정리하면:
- 사용자 입장에서는 강한 비밀번호 + 비밀번호 매니저 + 서비스별 다른 비밀번호
- 개발자 입장에서는 해시+솔트, 안전한 알고리즘, 적절한 정책, 2FA 도입이 핵심
서비스를 만들 때
- "이 시스템에서 비밀번호가 어떻게 저장되고, 어떻게 검증되는가?"를
꼭 한 번 점검해 본다면,
기본적인 보안 사고를 막는 데 큰 도움이 될 것입니다.