직접적인 관련은 없지만, 최근 더 강력한 비밀번호 검증 방식을 검토하고 있어 Pwned Passwords Validator 를 참고하게 되었습니다.
Discourse는 사용자 이름이 myusername인 경우 myusername123이나 4myusername과 같은 비밀번호를 차단하지 않는 것으로 보입니다.
이러한 유형의 약한 비밀번호에 대한 이전 논의는 찾지 못했습니다. 이전에 이 문제가 고려된 적이 있나요?
5개의 좋아요
사람들이 비밀번호를 선택할 때 '비밀번호에는 소문자 사용자명이 포함되면 안 된다’는 검사를 추가하는 데는 문제가 없습니다. 제 생각에는 합리적인 조치인 것 같습니다.
이미 password = username을 테스트하고 있지만, 부분 문자열 테스트는 큰 팬이 아닙니다. 특히 짧은 사용자 이름의 경우 더욱 그렇습니다. 만약 사용자 이름이 "Ed"이고 비밀번호가 우연히 "ed"를 포함하는 랜덤 문자열이라면 어떻게 될까요?
3개의 좋아요
Levenshtein distance와 유사한 유사도 점수를 사용하여 levenshtein(username, password) < 6이면 실패하도록 하는 건가요? 아니면 다음과 같이 순열(permutation)까지 포착할 수 있는 방법도 있습니다:
levenshtein(sort_by_chars(username), sort_by_chars(password)) < 6
이 방법은 "Ed"가 긴 비밀번호를 사용하여 가입하는 것을 막지 않으면서도 가장 심각한 악용 사례를 커버할 수 있을 것 같습니다. 또한 "사용자 이름과 비밀번호가 너무 유사합니다"라고 정확하고 쉽게 설명할 수도 있죠. 바람직하지 않은 엣지 케이스를 찾아보지는 않았지만, 당장은 떠오르는 것이 없습니다.
3개의 좋아요
오늘의 관련 트윗:
5개의 좋아요
규칙이 “더 많을수록” 좋다는 것의 반대 측면은, 비밀번호를 무차별 대입 공격(brute force)으로 깨는 것이 더 쉬워진다는 점입니다.
15자 이하의 비밀번호에 글자 z가 10번 반복되는 것은 당연히 있을 수 없습니다.
비밀번호에 'password’라는 단어가 포함된 것도 당연히 안 됩니다. 12자 미만인 경우라면요.
사전의 두 단어가 연속으로 오는 것도 당연히 잘못된 것입니다…
그리고 이어서 더 많은 예시가 이어집니다. 결국 비밀번호를 탐색할 수 있는 공간이 줄어드는 것입니다.
이 주제는 끝이 없는 미로(rabbit hole)입니다. 이 문제를 더 깊이 생각한 결과, 어제의 제 생각을 바꿨습니다. 저는 @codinghorror와 같은 의견입니다. 여기서는 아무것도 할 필요가 없다고 생각합니다.
3개의 좋아요
“좋은 규칙을 만드는 것이 어렵기 때문에, 규칙을 만들어서는 안 된다”?
며칠 전부터 디스커스(Discourse) 팀의 고위급 구성원들이 보안에 대해 심각한 오해를 퍼뜨리는 모습을 두 번째로 보고 있습니다. 몇 가지 근본적인 부분을 다시 생각해 볼 필요가 있다고 생각하며, 이것이 건설적인 피드백으로 받아들여지기를 바랍니다.
또한, 이 구체적인 제안은 무에서 나온 것이 아닙니다. 최근 한 사용자 계정이 사용자명이 myusername이고 비밀번호가 myusername46 형태였기 때문에 해킹을 당한 일이 있었습니다.
해당 사이트가 ClassicPress(WordPress와 동일한 로그인 구조)였기 때문에, 봇 등의 공격 대상으로는 훨씬 ‘쉽게 잡히는 먹이(low-hanging fruit)’에 해당합니다. 그러나 봇들이 실제로 이런 패턴을 찾아다니고 있습니다.
비밀번호 규칙이 존재하는 모든 종류의 나쁜 비밀번호를 막을 수는 없지만, 상당한 정도로 보안을 강화하는 데 기여할 수 있습니다.
기술적으로 우리는 NIST 800-63-B의 가이드라인을 따르고 있습니다:
기억형 비밀(secret)의 생성 및 변경 요청을 처리할 때, 검증기(verifier)는 일반적으로 사용되거나, 예상되거나, 또는 유출된 값이 포함된 목록과 예상되는 비밀을 비교해야 합니다(SHALL). 예를 들어, 이 목록에는 다음이 포함될 수 있으며(MAY), 이에 국한되지 않습니다:
- 이전 유출 데이터베이스에서 수집된 비밀번호.
- 사전(디셔너리)에 있는 단어.
- 반복적이거나 순차적인 문자 (예: ‘aaaaaa’, ‘1234abcd’).
- 서비스 이름, 사용자 이름 및 그 파생어와 같은 컨텍스트에 특화된 단어.
그들은 명시적으로 SHALL이 아닌 MAY라는 단어를 사용하고 있습니다. 따라서 이는 우리의 재량에 달려 있습니다. 여기에는 Levenshtein 거리를 사용하는에 대한 권장 사항이 없습니다. 사용자 이름이 6자보다 길면 비밀번호에 포함되지 않아야 한다는 규칙을 추가하거나, 100만 개 비밀번호 목록 위에 엔트로피(무작위성) 검사를 추가할 수도 있습니다. 저도 잘 모르겠습니다.
여기서 자체 규칙을 엄격하게 적용하기를 원하신다면 SSO를 실행하고, 해당 측에서 원하는 규칙을 적용하시면 됩니다. 또는 플러그인을 작성하는 것도 방법입니다.
3개의 좋아요
아마 우리도 그렇게 할 것 같습니다. 여기서는 더 많은 부분이 빠져 있지만, 지금까지의 답변들을 보면 이 문제를 굳이 꺼내는 것이 특별히 가치 있다고 생각되지 않습니다.
여러분이 만든 플러그인은 Customization > Plugin 카테고리에 공유해 주세요. 우리가 내린 모든 결정에 대해 모든 사람이 동의하는 것은 아니며, 다양성과 선택지를 존중합니다. 더 엄격한 비밀번호 규칙에 관심이 있는 다른 사람이 있을 수도 있습니다.
1개의 좋아요