두 가지가 있습니다. 여기에 요인이 있습니다.
첫째, 당신이 맞습니다. 엔트로피는 같습니다. 중요한 것은 그 공간의 활용이 아니라 주소 공간입니다. 사용자가 기호 등을 사용할 수 한, 이것이 첫 번째 경우에 중요합니다.
그러나 두 번째 요소는 추측 가능성 또는 파손 가능성입니다. 레인보우 테이블을 사용하여 암호를 추측 할 수 있습니까? 암호를 무차별 대입 할 수 있습니까 (예 : 모든 문자가 동일 함). 123456789012의 예는 간단하고 일반적이기 때문에 괜찮은 레인보우 테이블에있을 것이기 때문에이 방법을 따르지 않습니다.
현재 비밀번호에 대한 모범 사례는 다음과 같습니다. 확장 된 문자를 허용하지만 특정 규칙을 적용하지 않습니다 (어쨌든 주소 공간을 줄임). 더 긴 암호를 권장합니다. “코드”메모, “단어”에 대한 강조를 제거합니다. 좋은 암호는 기억에 남을 수 있지만 그렇지 않습니다. 마지막으로 복잡성을 조장하기 때문에 30, 60 또는 90d 암호 변경을 강제하지 않을 것입니다. 적어도 개인 ID의 경우 공유 / 관리자 ID는 약간 다를 수 있습니다.
내 느낌은이 접근 방식이 유용성과 향상된 보안의 균형을 잘 맞춘다는 것입니다. 하지만 취약한 암호를 찾기 위해 주기적으로 암호 데이터베이스를 감사하는 것이 이상적이라고 생각합니다.
댓글