우아콘2022 등록을 하다가 생긴 에피소드이다.
1Password 가 생성한 강려크한(?) 비밀번호 기능을 이용해서 비밀번호 설정을 했다.
그런데 입력 validator 에서 아래와 같은 메시지가 떴다.
1Password 가 제안한 강려크한 비밀번호는 아래와 같았다. (물론 아래의 값을 등록할 때 사용하지 않고 재 생성을 했다.)
wed2!RE3xer-yur6dg@
분명 영문대소문자도 들어가 있고, 숫자도 들어가 있고, 특수문자도 두 개 이상 들어가 있는데 어떤 것이 문제가 되었던 것일까?
텍스트 에디터에서 붙여놓고 마지막 커서를 가져가 놓는 방식으로 길이를 세어보았다.
(맨 끝이 아닌 이유는 Sublime Text는 제일 앞의 커서 위치를 0이 아닌 1부터 세기 때문이다.)
결국 길이가 16를 넘어서 발생하는 문제였다.
데이터베이스의 테이블을 설계하다보면 데이터가 저장할 상한값에 대해 고민을 하게 된다.
이것은 입력 받은 데이터를 그대로 저장을 할 경우가 그렇다.
하지만 비밀번호의 경우 입력한 값을 그대로 저장하는 경우는 토이프로젝트에서는 있다.
하지만 실무에서는 비밀번호를 다른 재료(값)들과 섞고 소금(salt)와 후추(pepper)를 쳐서 버무려서 최종적으로 해싱(hashing)을 해서 저장을 하기에 데이터 상한이 개발하는 주체가 정할 수 있다.
예로 SHA-512 로 해싱을 하는 경우에는 데이터를 16진수 문자로 저장을 해도 128바이트만 있으면 된다.
패스워드 암호화로 많이 사용하는 블로피시 기반의 bcrypt로 저장을 한다고 해도 다이제스트 크기는 184비트이다.
$2b$[cost]$[22 character salt][31 character hash]
입력받은 암호의 하한 길이 조건은 보안의 품질을 떨어 뜨리기에 제한을 해야 하는 것이 바람직하다. 우아콘2022에서 10자의 제한 같은 것이 예이다.
하지만 길이의 최대 길이를 제한하는 것은 기술적인 문제라기 보다는 그냥 존재하는 정책에 가깝다.
'Bug Reports' 카테고리의 다른 글
[Culture] Liskov was female! (리스코프는 여자였다!) (0) | 2020.08.05 |
---|---|
[sonarqube] @Nonnull의 오탐? (0) | 2019.03.05 |
Garmin Connect 앱의 한글 문제로 인한 Case Open (0) | 2018.03.03 |
MS도 jquery를 사용 & IE8를 버렸나? (0) | 2014.11.12 |
OruxMaps v.5.5.16 버그(OruxMaps v.5.5.18 해결) (0) | 2014.03.24 |