A.3 "Complexity" 중 발췌 "Users also express frustration when attempts to create complex passwords are rejected by online services. Many services reject passwords with spaces and various special characters. In some cases, the special characters that are not accepted might be an effort to avoid attacks like SQL injection that depend on those characters. But a properly hashed password would not be sent intact to a database in any case, so such precautions are unnecessary."
그래서 NIST 문서가 업데이트 됐죠
https://pages.nist.gov/800-63-3/sp800-63b.html#appA
A.3 "Complexity" 중 발췌
"Users also express frustration when attempts to create complex passwords are rejected by online services. Many services reject passwords with spaces and various special characters. In some cases, the special characters that are not accepted might be an effort to avoid attacks like SQL injection that depend on those characters. But a properly hashed password would not be sent intact to a database in any case, so such precautions are unnecessary."
번역본 : https://peim.tistory.com/12
그래서 최대한 길게 하는게 좋다고 알고 있습니다.ㅋㅋ
면 충분하다 봅니다. 대소문자 특수문자 보다요.
특수문자랑 숫자, 영문대소문자는 다 합쳐서 20 + 10 + 26*2 = 82 글자인고
숫자와 영소문자 합쳐서 10+26 = 36글자긴 하지만
특수문자 합쳐서 10글자는 조합 가능한 갯수는 137 4000 0000 0000 0000 개이고
숫자 영소문자의 13글자는 조합 가능한 갯수는 1705 0000 0000 0000 0000 개, 10배입니다.
외우기 힘들게 특수문자 넣기보다 그냥 조금 더 길게 하는 게 낫죠.
비번 찾는게 더 걸리는건 사실이잖아요.;;
뭐 DB를 뚫어서 같은 비번인 경우는 답 없지만요....
급 생각나서 찾아보니 아직 있네요. 혹시라도 실제 비번을 넣진 마세요. 혹시라도 ..!
제 비번과 같은 타입은 93 trillion years (93조년이네요.;;)
https://www.security.org/how-secure-is-my-password/
(경우의 수를 줄일 수 있음)
비번 자체에 그것들이 포함되어있느냐가 중요한 건 아니죠.
5 hundred quintillion years
엇... 테스트를 안해봤는데...ㅡㅡ^
사이트가 사기군요?! 죄송합니다.
전 귀찮아서 못하지만 동의는 합니다. ㅠ
시덥잖은 사이트는 임의 문자열을 비번으로 하고 브라우저에 비번 기억시켜 사용하는게 낫다 생각합니다. 비번 까먹으면 그때마다 비번 재생성 하구요. (전 메모장ㅡ암호화된zip에 따로 적어두긴 합니다만...)
대신....특수문자를 안받거나.... 가려서 받는 데가 더 짜증납니다