Yeah, I agree that aspect of it seemed quite problematic to me as well from the beginning. And he obviously cannot include the email in the hash. So it’s better to just disallow the top x most common passwords, which we already have. (Though it’s not updated on the fly as the list changes over time.)
2개의 좋아요
What would really solve the issue here, in my humble opinion, would just to apply best practices like preventing an IP to try to login more than X times without success, don’t let people try passwords at non human time ( humans don’t try a password every 1 sec ) would fix the security issue without forbidding all the passwords.
The way I see is, someone can make a list that gives all the combinations of A-Z 1-9 up to X length. This means nothing if you can’t brute force the target, unless it’s a targed attack and then there’s not much you can do.
Is anything like that currently implemented?
Yes, there is extensive rate limiting across the whole of Discourse. By default login attempts are limited to 6 per minute and 30 per hour (per IP).
9개의 좋아요
Hmm, can you extrapolate here though? It would seem to me that the distribution of lengths might be quite different if you focus on the 1 mil most common ones since those will obviously tend to be shorter.
1개의 좋아요
I think it’s a good idea to alert the user but maybe not prevent them from using the password if they insist. Explain it better, maybe something along the lines of
“The encrypted version of this password has been found in a public database of stolen user information and may put your account at increased risk of being hacked by brute force attacks. If you use this password across multiple web services we strongly recommend changing them to unique passwords to stay secure, especially for mail accounts.”
And let them hit submit a second time to use it anyway.
hopefully webauthn will make passwords a thing of the past someday 
2개의 좋아요
이것은 제게 이해가 가지 않습니다(그래서 이 스레드를 다시 올린 것입니다). 비밀번호가 해독되었거나(또는 평문으로 발견되었음)이 확인되면 보안 수준이 현저히 낮아집니다. 매우 관대한 가정을 적용하더라도 이는 엔트로피의 크게 감소를 의미합니다:
- 무작위로 생성된 10자리 비밀번호, 매우 제한된 문자 집합을 사용하더라도(소문자만 사용하는 극단적인 예: Pr = 1/26^10 = 1/1.4e14)
- HIBP 목록에 포함된 것으로 알려진 비밀번호 (Pr = 1/5e8)
다른 사람이 그 비밀번호를 사용했고 그것이 또한 유출되었거나/해독된 경우 - 이것이 결정적인 차이입니다.
단 하나의 목록에만 등장한 비밀번호를 막는 것의 실용적인 문제는 무엇입니까? 사용자로서 저는 해당 비밀번호를 다시 사용하지 않도록 하기 위해 그런 정보를 알고 싶습니다. 사이트 관리자로서도 저는 사용자가 손상된 비밀번호를 사용하지 않기를 원합니다. 이는 사용성 저하라는 트레이드오프를 감수할 만한 가치가 있어 보입니다.
아니요, 통계적으로 모든 비밀번호는 시간이 지나면 해킹당하므로 핵심적인 차이가 아닙니다.
우리는 이미 수년 전부터 가장 흔한 상위 100만 개의 비밀번호를 차단하고 있으므로, 중요한 부분에서는 이미 보호되고 있습니다.
3개의 좋아요
통계적으로 모든 암호화 및 해싱 알고리즘은 시간이 지나면 결국 깨지게 됩니다. 알고리즘이 깨질 위험에 근접했다는 첫 번째 징후가 보일 때 우리는 더 이상 그것을 사용하지 않습니다.
그렇다면 왜 비밀번호가 예외여야 할까요? 모든 보안은 주어진 작업에 사용 중인 엔트로피가 충분한지에 대한 베팅이며, 거기에는 항상 견딜 수 있는 공격의 길이 또는 강도에 대한 가정이 포함되어 있습니다.
비밀번호가 목록에 처음 등장할 때 최소 6자리의 엔트로피를 잃게 된다는 점을 고려하면(현실적으로는 아마도 그 이상일 것입니다), 이는 쉬운 결정인 것 같습니다.
네, 이는 오늘날 이용 가능한 많은 다른 소프트웨어 패키지에서 존재하는 상황보다 훨씬 나은 상태입니다. HIBP는 그 위에 더 많은 보장을 원하는 사이트들에게 여전히 좋은 개선책입니다.
기술적으로 가능하다고 하면, 플러그인을 통해 “구문자열 생성” 버튼을 추가할 기회인 것 같습니다…
이 경우 pwned 목록에 포함된 항목은 제외되고, 사용자는 이미 기본 100만 개 제외 목록이 내장된 상태로 직접 구문자열을 만들 수 있습니다. 버튼 방식은 사용자가 pwned 목록이나 엔트로피에 대해 교육받을 필요가 없도록 해주며, 일반적으로 사용자는 그런 데 시간을 할애하지 않기 때문입니다.
다만 제 생각에는 Discourse가 이미 충분히 잘하고 있습니다.
왜 서버에서 비밀번호를 생성해야 하나요?
사용자가 비밀번호를 저장해야 한다면, 비밀번호 생성에 대한 책임은 사용자가 관리하는 것이 더 합리적이지 않을까요? 사용자가 선택한 자격 증명 관리 도구라면 이미 이 기능을 제공하고 있을 가능성이 높습니다.
2개의 좋아요
1m verboden 목록에 따라 ‘apple’, ‘apple1’, ‘apple 123’, 'apple 12345’는 허용되지 않는다고 계속 반복해서 알려주는 것보다, 서버에서 생성하는 방식이 더 나을 수 있기 때문입니다. 개인적으로는 Discourse에 이 기능이 도입되기를 크게 기대하지는 않지만, 만약 이 기능이 유출된 비밀번호 문제를 비교적 우아하게 해결하고, 문제가 발생했을 때 사용자의 판단에 맡길 수 있다면 살펴볼 가치가 있을 수 있습니다.
그렇다면 클라이언트 측 비밀번호 관리자가 이런 식의 비밀번호를 생성한다는 건가요?
사용자에게 비밀번호 관리자를 사용하도록 권장하는 것이 단일 사이트에서 비밀번호를 강제하는 것보다 훨씬 효과적입니다. 후자의 경우, 해당 비밀번호를 다른 모든 곳에서도 사용하게 되어 비밀번호가 더 빨리 유출될 위험을 높일 뿐입니다.
바보 같은 실수를 수정하는 건 해킹을 당한 것을 복구하는 것보다 더 어렵습니다. 제 생각엔, https://www.useapassphrase.com/ 같은 것을 참고하는 것만으로도 그 이론적 배경에 관심이 없는 사람들에게 큰 도움이 될 것 같습니다.
수천만 명이 사용하는 시스템을 구축해 왔고, 비밀번호와 관련된 다양한 접근 방식을 시범 적용해 보았습니다. 그중에는 '반드시 x와 y를 포함해야 한다’는 그 끔찍한 요구 사항도 있었죠.
사용자에게 비밀번호 관리에 대해 교육하지 않는다면, 비밀번호 피로, 재사용, 그리고 그 무서운 "키보드 아래에 붙어 있는 포스트잇"의 가능성이 오히려 높아질 뿐입니다.
서버에서 비밀번호를 생성하는 것도 새로운 공격 벡터와 표면을 만들어 내며, 이는 보호해야 합니다. 개인적으로는 위 모든 것을 없애고 싶습니다.
3개의 좋아요
JS가 클라이언트 사이드에서 패스프레이즈를 무작위로 생성한 후 해시를 계산하고 목록과 비교하는 구조일 거라고 생각했어요. 교육 부분은 ‘비밀번호 만들어줘’ 버튼 위에 스텁으로 구현할 수 있겠죠. 솔직히 이런 건 디스코스가 신경 쓸 일이 아니라고 생각하지만, 사람들이 자신의 행동으로 인한 분노를 브랜드 탓으로 돌리는 경우가 많으니 고려해볼 만한 가치가 있을지도 모릅니다.
그렇다면 가장 좋은 방법은 귀하가 제안한 기능을 수행하는 플러그인을 개발하거나 의뢰하는 것입니다.
1개의 좋아요
이 플러그인의 목적도 바로 그것입니다.
이 플러그인을 작성한 후 이 문제에 대해 좀 더 생각해 보니, 제프의 의견에 동의하게 되었습니다.
"breached(해킹당하다)"라는 것은 어딘가에 그 문구를 생각해 낸 사람이 있었고, 그 문구가 "어떤 목록"에 등장했다는 것을 의미합니다. 만약 누군가가 다음과 같은 도구를 만든다면 어떻게 될까요?
- 문자열 목록을 공개합니다.
- 고유한 문자열을 체계적으로 생성하여 목록에 추가합니다.
제프의 논지는 결국 모든 문자열이 어딘가의 공개 목록에 등장하기 때문에 궁극적으로 “안전하지 않은” 상태가 된다는 것입니다. 그리고 결국 당신의 “초고도 보안” 비밀번호도 이 끊임없이 확장되는 목록에 등장하게 될 것입니다.
비밀번호 자체의 개념은 누군가가 당신의 계정 비밀번호를 추측하지 못한다는 "통계적 불가능성"에 의존하고 있을 뿐입니다. 공격자는 기술적으로 비밀번호를 알 필요가 없으며, 단지 정말 좋은 추측을 할 필요가 있습니다. 그들은 "좋은 추측"을 하는 데 필요한 요소를 파악하여 자신에게 유리하게 활용할 수 있습니다:
- 해킹 데이터(breach)가 있다면, 동일한 계정에 대해 동일한 비밀번호를 시도합니다.
- 해킹 데이터 목록이 있다면, 많은 사람들이 사용하는 비밀번호를 시도합니다.
우리는 이미 Discourse가 위의 2번 항목에서 잘 수행되고 있다는 점을 논의했습니다. 당신이 목표로 하는 것은 1번 항목인 것 같지만, 이를 코어에 포함시키는 것은 (사용자 이름과 관련되지 않은 어떤 비밀번호도 사용해서는 안 된다는 가정 하에) 다소 불필요하며 사용성 측면에서 악몽과도 같습니다… 하지만 당신의 사이트에 당신이 설명하는 기능이 필요하다면, 이 플러그인이 바로 당신을 위한 것입니다.
4개의 좋아요
맞습니다. 솔직히 이는 확률이라는 개념과 완전히 동떨어진, 따라서 이 문제를 논리적으로 다루는 유일한 올바른 방식을 무시한 매우 나쁜 논리입니다.
다행히도 우리가 논의하고 있는 것은 가장 많이 사용되는 비밀번호를 이미 제외하고 난 후 나타나는 가장자리 사례(edge case)이며, 이는 그 자체로도 꽤 좋은 전략입니다.
1개의 좋아요