안전하지 않은 비밀번호로 사용자 처벌 [닫기]

안전하지 않은 비밀번호를 선택하는 사용자 (길이에 따라 비밀번호가 결정되지 않음, 사용되는 문자 유형 (대 / 소문자, 숫자, 기호 등) 수 및 사용 가능 여부를 선택하려는 사용자의 권리를 제한하려고합니다. 레인보우 테이블에 위치) 계정이 손상된 경우 계정의 피해량을 제한합니다.

아직이 아이디어에 대한 응용 프로그램이 없지만 포럼이나 다른 것을 쓰고 있다고 가정합니다. 1234를 암호로 사용하는 사용자는 게시하기 전에 보안 문자를 작성해야하거나 다음과 같은 엄격한 스팸 방지 조치를 받아야합니다. 콘텐츠를 거부하는 타임 아웃 또는 베이지안 필터 이 포럼이 매우 계층 적이므로 중재자 또는 다른 방법으로 "프로모션"을 허용하면 권한을 얻지 못하게하거나 권한이 있다고 말하지만 더 안전한 것으로 변경하지 않고서도 운동을 할 수는 없습니다. 암호.

물론 이것이 보안의 유일한 척도가 될 수는 없지만 좋은 보안 관행 옆에 잘 갈 수 있습니다.

어떻게 생각해? 이것이 과도하거나, 더 중요한 보안 관행에서 초점을 빼앗기거나, 위험을 제한하고 사용자가 더 안전한 암호를 사용하도록 장려하는 좋은 방법입니까 (좋은 보안 관행을 사용하는 사람들에게 희망을 주어야 함)?

YAGNI , KISS , DRY , 10 초 규칙 및 "[고객이 당신을 신경 쓰지 않는다" 는 사실 은 아마도 한 가지 해결책으로 좁혀 야 할 것입니다.하지 마십시오.

• 보다 안정적이고 안전한 테스트 가 필요한 개발 작업이 더 많습니다 .
• 사이트를 보는 방식에 따라 사이트의 보안이 저하 될 수 있습니다. 끔찍한 암호로 권한 상승으로 이어지는 일부 버그의 가능성이 너무 큽니다.
• 개발자, 테스터, 관리자, DBA, sysadmin 및 사용자의 복잡성을 증가시킵니다.
• 복잡성이 높을수록 어떤 식 으로든 자신을 반복하지 않는 것이 어렵습니다.
• 사용자는 귀하의 정보를 읽고 그에 대한 후속 조치를 취하지 않아도됩니다. 그것들은 이상적인 수준에 도달 할 때까지가 아니라 입력을 받아 들일 때까지 등록 양식을 조정하는 데 사용됩니다.
• 사용자는 신경 쓰지 않습니다.

등록 변경시 보안 암호를 사용하거나 OpenId (Jeff Atwood 's 2c : http://www.codinghorror.com/blog/2010/11/your-internet-drivers-license.html )를 사용하십시오. 그런 다음 더 흥미로운 기능에 집중하십시오.

우선 사용자는 보안 암호를 만들거나 OpenId를 사용해야하므로 간단합니다.

처음에 암호가 잘못되었다고 생각하는 이유는 무엇입니까? 소스에서 문제를 중지하면 어떤 암호 클래스가 어떤 역할에 매핑되는지 파악하는 데 많은 디자인 시간이 절약됩니다. 관리자는 정의상 전체 권한을 가지므로 사용자를 제한하는 비밀번호를 입력하지 않도록하려면 이미 기능이 필요합니다.

내 대답은 정말 KISS에 귀착됩니다 .

사용자로서, 아마도 귀하의 사이트를 사용하지 않도록 설득 할 것입니다. 진심으로 은행에서 6 자리 코드가 온라인 뱅킹에 완벽하게 안전하다고 말하지만 잘 알려지지 않은 블로그에 의견을 쓰려면 적어도 8 개의 상위 문자가 포함 된 고유 한 비밀번호를 기억해야합니다 -및 소문자, 숫자, 특수 문자 및 그리스어 또는 키릴 문자는 유니 코드 시퀀스를 마음으로 알고있는 경우에만 입력 할 수 있습니다. 그리고 정기적으로 바꾸십시오.

틀리지 말고 보안이 중요합니다. 그러나 누군가가 사이트에 액세스하기 위해 자신의 암호를 해독하려고 시도 할 것이라는 강력한 이유가 없다면 사용자를 화나게하지 말아야합니다. 귀하의 사이트가 FBI 네트워크에 대한 VPN 액세스를 제공하는 경우 계속 진행하십시오. 그러나 이메일 주소를 가진 사람이 누구나 가입 할 수있는 사용자 포럼이라면 요점은 무엇입니까?

더 나은 해결책 : 웃는 얼굴.

진심이야! "너지 (Nudge) : 건강, 부, 행복에 대한 결정 개선"과 같은 행동 경제학 책을 읽은 것은 몇 가지 사실을 확신시켰다.

1. 모든 사람이 현명한 결정을 내 리도록 강요 할 수는 없습니다.
2. 사람들은 자유롭게 선택할 수 있지만 많은 옵션을 좋아하지 않습니다.
3. 그러나 간단한 트릭으로 더 나은 선택에 영향을 줄 수 있습니다.

이러한 원칙이 다음과 같은 상황에 적용되는 것으로 보입니다.

1. 안전하지 않은 암호를 기반으로 사용자를 제한하면 대화 상자에서주의 깊게 작성된 설명을 읽지 않고 헬프 데스크에 전화하여 " 작업."
2. 암호를 만들 때 사용자는 특수 문자의 모든 가능성 목록과 사용 가능한 문자 목록을 볼 필요는 없습니다. 항목이 요구 사항을 충족하지 않는 경우에만 약간의 복잡성을 추가 함을 제안하는 작은 팝업을 표시하는 것이 좋습니다.
3. 사람들은 사회적 단서의 영향을받습니다. 심지어 우리가 그들의 행동을 승인한다는 것을 보여주는 행복한 얼굴이나 그렇지 않은 경우 찡그린 얼굴과 같은 작은 얼굴조차도 마찬가지입니다. 더 나은 디자인 웹 사이트의 일부에서 변화가 빨간색하는 색깔의 진행 표시 줄을 표시합니다 하지 충분한 :( 녹색에 좋은 작업! :) 자신의 (제안) 암호 및 확인에 사용자 유형으로. 이 UI는 표준을 충족해야하는 사회적 압력을가집니다. 즉, 바를 녹색으로 바꾸거나 찌푸린 얼굴을 미소로 바꾸어야합니다. 색상이 바뀝니다.

쌓아 두지 말고 아직 언급하지 않은 "나쁜 아이디어"에서 고객 지원이라는 다른 이유를 생각했습니다.

이 제품이 고객 지원 담당자의 지원을받는 제품이라면이 제품은 그다지 좋아하지 않을 것입니다. 지원의 기본 가정 중 하나는 사용자 경험을 이해하고 예측할 수 있다는 것입니다. 일반 사용자를 지원하는 경우 페이지 1은 페이지 2, 3 및 4에 대한 링크가 있어야 X, Y, Z를 수행 할 수 있습니다. 등

이제 추적해야 할 다른 변수를 제공합니다. 사용자가 4 페이지에 대한 링크를 볼 수 없다면, 어리석은 짓을했기 때문입니까? 아니면 암호가 빨라지고 시스템이 암호에 대한 액세스를 거부하여 처벌하고 있기 때문입니까? 잠깐만 ... 쓰레기, 잘못된 암호로 처벌 중 하나에 대한 액세스를 거부하고 있습니까, 아니면 5 페이지를 생각하고 있습니까? 대문자와 소문자가 혼합되지 않은 암호의 경우 짝수 페이지에 대한 액세스는 허용되지만 읽기 전용으로 제한됩니다. 귀하의 비밀번호는 모두 대문자 또는 소문자로 구성되어 있습니까? 케이스. 문자를 입력하면 소문자입니다. shift를 사용할 때는 대문자가됩니다. 비밀번호에 사례를 혼합 했습니까? 시스템에 로그인 할 때 사용한 비밀번호입니다. 방금 사용한 것. 좋아, 편집으로 이동 한 다음 환경 설정을 선택한 다음 보안을 선택하십시오. "저장된 비밀번호"를 선택하십시오 ... 아니오, 선생님, 여기에서 비밀번호를 볼 수 없습니다 ....

네. 이러지 마

비밀번호를 제한하거나 취약한 비밀번호의 위험성을 사용자에게 알리십시오. 사용자가 데이터에 신경 쓰지 않으면 다른 사람의 액세스를 제한 할 수 있습니다. 부주의 한 암호 관행을 따르는 사람들이 걸러 내면 더 자신감을 가질 수 있습니다. 키보드 아래의 스티커 메모로 끝나거나 랩톱에 테이프로 묶일 경우 더 강력한 암호를 요구하는 요점은 무엇입니까?

레인보우 테이블에 위치 할 수 있는지 여부

무지개 테이블이 아니라 사전을 의미한다고 생각합니다. 사전 공격은 암호와 일치하는 사전의 모든 단어를 테스트하는 것만으로 작동합니다. 이 공격은 5 번의 시도로 x 분 동안 차단 될 수 있습니다 ...

레인보우 테이블은 암호를 해시하고 공격자가 해시를 알고있는 경우에만 사용됩니다. 레인보우 테이블에서 "12345"나 그와 비슷한 것이면 해시를 찾을 수있을 것입니다.

왕복 여행을 마치기 만하면 : 무지개 테이블을 쓸모 없게 만들려면 암호를 입력해야합니다. 그리고 하나의 암호가 아닌 모든 암호에 unqiue salt를 사용하십시오. 그렇게하면 공격자는 액세스하려는 각 계정에 대해 고유 한 소금이 포함 된 무지개 테이블을 만들어야합니다. 당신이 영리하게 수행하면 연결 다중 해시 알고리즘으로 해싱을 강화하여 한 세대가 0.5 초가 걸릴 수 있습니다. 이 작업을 수행 한 경우 웹 사이트의 계정에 액세스하는 데 며칠이 걸릴 수 있습니다. 아마도이 계정과 일치하는 해시를 생성하는 달이 될 것입니다 ... 모든 암호를 얻을 수있는 공격자를 생각할 수 없습니다. 오래 걸리세요

해싱 시간 : 로그인 메커니즘을 기다리는 약 500ms의 시간을 생각하십시오. 나는 받아 들일 수 있다고 생각합니다 ... (알림 : 거의 1 초가 SSL을 위해 악수합니다)