전 세계적으로 고유 한 암호를 사용할 수없는 인용

시스템의 사용자 식별 / 인증 프로세스에 대해 누군가 (클라이언트)와 의견이 맞지 않습니다. 이것의 핵심은 각 사용자가 전역 적으로 고유 한 암호를 갖기를 원한다는 것입니다 (즉, 두 명의 사용자가 동일한 암호를 가질 수는 없음). 나는 이것에 대한 모든 명백한 주장을 제기했습니다 (보안 취약성, 인증과 식별을 혼동하고, 무의미한 것 등). 그러나 그들은이 접근법에 아무런 문제가 없다고 주장합니다.

나는 이것에 대한 권위있는 (또는 반 권위적이거나 독립적 인) 의견을 찾기 위해 다양한 Google 검색을 수행했지만 아무것도 찾을 수 없습니다 (주로 경고 할 가치가없는 명백한 가짜 pas입니다). 내가 알 수있는 한). 아무도 나에게 그런 독립적 인 의견을 지적 할 수 있습니까?

[편집]
귀하의 모든 답변에 감사드립니다. 그러나이 제안 된 접근 / 요구 사항의 문제점을 이미 이해하고 있으며 고객에게이를 설명 할 수도 있지만, 고객은이를 받아들이지 않을 것이므로 독립적이고 권위있는 출처에 대한 나의 요청 .

또한 Daily WTF 기사를 찾았지만 Jon Hopkins가 지적한 문제로 어려움을 겪습니다. 이것은 자명 한 WTF이므로 이유를 설명 할 가치가없는 것 같습니다 .

그리고 네, 암호는 소금에 절이고 해시됩니다. 어떤 경우에는 글로벌 고유성이 보장하기 어려울 수 있지만 이것이 문제를 해결하지는 못합니다. 이는 고객이 판단을하지 않아야한다는 요구 사항이 있음을 의미합니다. 도구. 그리고 내가 "염색과 해싱에 싹이 not 지 않는다"고 말할 수 있다면 "전 세계적으로 고유 한 암호를 구현하고 있지 않습니다"라고 말할 수있을 것입니다.

이것이 여전히 나쁜 생각 인 이유에 대한 독립적이고 권위있는 출처에 대한 조언 은 ...
[/ EDIT]

클라이언트가 이미 존재하는 비밀번호를 만들려고 할 때마다 일부 사용자는 이미 해당 비밀번호를 사용한다는 피드백을받습니다 ( 일반적으로 개인 정보 보호 계약 위반).

그 옆에 사용자 이름을 추측하기가 훨씬 쉬우 며 (포럼이있는 경우 많은 사용자 이름을 찾을 수 있음) 웹 사이트를 해킹하는 방법을 사용자에게 암시하고 있습니다.

개인 정보 보호 계약 위반 부분을 설명하는 인터넷 어딘가의 일부 페이지가 상식이라는 것 외에 다른 페이지가 있어야합니다. 기본적으로 누군가에게 키와 집 주소 목록을 제공하고 있습니다.

편집 : 권위에 가깝지는 않지만 WTF의 의미를 설명한 후에 도움이 될 수 있습니다. http://thedailywtf.com/Articles/Really_Unique_Passwords.aspx

모범 사례는 요구 사항을 충족시키는 데 방해가됩니다.

암호가 무엇인지 모르므로 암호를 해시하고 소금 (해시 된 암호 옆에 저장할 수 있음)이므로 소금을 비교할 수 없기 때문에이 작업을 수행 할 수 없습니다. 이것은 모범 사례이므로 귀하가하는 일입니다. 끝난.

또 다른 편집 : Doh! Hindsight는 쉽습니다. (물론) 당신은 (물론) 소금을 가지고 있기 때문에 여전히 독창성을 확인할 수 있습니다. 지금 당장 나를 쏴라.

FWIW, 생각보다 멍청하지는 않습니다. 목표는 사용자 그룹이 동일한 암호를 동의하고 공유하는 것을 방지하여 사람들 이 자신의 삶을 더 쉽게 만들 것이라고 믿게 만드는 것입니다.

비밀번호를 정기적으로 변경하기위한 요구 사항과 사람들이 현재 또는 이전에 사용한 비밀번호 (모두) 를 재사용 할 수 없도록하는 제한 조건 및 적절한 "강도"요구 사항 (또는 최소한 사전로드 된 "차단 된 사전"사전)이 적용되는 경우 "암호) 당신은 확률이 어쨌든 해커에게 유리하지 않은 상당히 빠른 시점에 도달하게 될 것입니다.

좋아, 내 대답은 원래 다음과 같이 시작했다.

개념적으로 몇 가지 조항이 주어지면 이것에 대해 거의 잘못이 없습니다. 대부분 내가 두꺼운 것입니다 ...

부적절한 유머는 분명히-요점은 전 세계적으로 고유 한 제약 조건이 없다면 다른 기회를 창출하고 있다는 것입니다. 아마도 덜 위험합니다.

반복 불가능한 암호를 적용하면 정보가 유출됩니다

방법? 크래커가 간단한 비밀번호로 새 사용자를 만들려고 할 때마다 시스템은 "Nope, 해당 비밀번호를 가질 수 없습니다"라고 응답하므로 크래커는 "Goody, 이것이 목록에 대한 것"이라고 말합니다.

보안에 관한 정보를 유출하는 것은 일반적으로 나쁜 일입니다. 좋아, 타사가 알고리즘을 알고 있다는 것은 잘 알고 있습니다 (동료 검토가 필요하지만). 전용 크래커가 키를 유추 할 수 있습니다.

좋고 나쁜 암호 관리 정책을 설명하는 자료

암호 전문가에 대한 자세한 내용 은 보안 전문가 Bruce Schneier 의이 기사 를 읽으십시오 .

보안 연구원 Philip Inglesant & M. Angela Sasse가 "사용할 수없는 비밀번호 정책의 실제 비용"에 대한 자세한 내용을 보려면 이 PDF 를 읽으십시오 . 결론에서 인용하자면 :

“[사용자] 만 위험을 이해하면 다르게 행동 할 것”[12]이라는 세계관에 대항하여“보안 관리자 만 사용자와 조직의 실제 비용을 이해하면 정책을 다르게 설정할 것”이라고 주장합니다.

잘못된 보안 감각

따라서 클라이언트는 "같은 암호를 가진 사람이 없으면 암호가 해독되면 한 사람 만 영향을받습니다." 아니요. 크래커가 암호 시스템에 근본적인 결함이 있음을 입증했기 때문에 모든 사람이 영향을받습니다. 온라인 시스템의 사전 공격에 취약합니다. 크래커가 처음에 비밀번호에 대해 여러 번 추측 할 수 없었을 것입니다.

온라인 액세스의 경우 6 자이면 충분합니다

주제를 벗어나지 만 관심있는 독자에게는 언급 할 가치가 있다고 생각했습니다. 보안 측면에서 온라인 시스템은 데이터에 대한 액세스를 모니터링하고 제어하는 ​​활성 보안 관리 프로세스가있는 시스템입니다. 오프라인 시스템은 도난당한 하드 디스크에 데이터를 암호화하는 것과 같이 그렇지 않은 시스템입니다.

온라인 암호 시스템이있는 경우 높은 보안 암호가 필요하지 않습니다. 암호는 20 번의 시도 내 추측을 방지하기에 충분히 복잡해야합니다 (따라서 간단한 "배우자 / 자녀 / 애완 동물 이름"공격은 실패합니다). 다음 알고리즘을 고려하십시오.

1. 크래커는 "root plus suffix"접근 방식을 사용하여 비밀번호를 추측하여 추측을 최소화합니다.
2. N * 10 초 동안 자격 증명이 거부되고 추가 로그인 시도가 방지 됨
3. N> 20 인 경우 계정을 잠그고 관리자에게 알리십시오
4. N = N +1
5. 시간 T에 다음 로그인이 발생할 수 있음을 사용자에게 알립니다 (위에서 계산).
6. 1 단계로 이동

간단한 6 문자 암호의 경우 위 알고리즘은 사전 공격을 방지하는 동시에 모바일 키패드를 잘 모르는 사용자도 결국 통과 할 수 있습니다. 고무 호스로 암호 홀더를 때릴 때까지 소위 "고무 호스 공격"을 막을 수있는 것은 없습니다.

암호화 된 데이터가 플래시 드라이브에 놓여 있고 크래커가 그에 대해 무언가를 시도 할 자유가있는 경우 오프라인 시스템의 경우 가장 탄력적 인 키를 원할 것입니다. 그러나 그 문제는 이미 해결되었습니다 .

이 행동 과정에 대해 조언하고 이유를 제공했다면, 나는 그들의 말을 듣고 제안한대로 시스템을 구현할 것입니다. 그것은 만족스럽지 않을 수도 있지만, 당신은 일을 마쳤고, 그들은 법안에 발을 디딘 다. 그래서 그들은 그들이 원하는 것을 얻어야한다.

한 가지 예외가 있습니다. 시스템 침해로 인한 부정적인 결과가 심각 할 경우 (예 : 보안 침해로 인해 개인 정보가 손상 될 가능성이있는 경우) 실제로 원하는 시스템을 구현하지 않는 전문가의 의무가있을 수 있습니다. 거절하면 인기를 끌 것으로 기대하지 말고 그것을 안내 자로 두지 마십시오.

Murph의 답변을 강화하고 싶습니다. 예, 보안 문제이며이를 구현하는 데 정보 유출 취약성이 있습니다. 그러나 고객의 관점에서 볼 때, 그는 그것에 대해 너무 걱정하지 않는 것 같습니다.

당신이 지적해야 할 것은이 점이다 물리적으로 불가능 실제로 "고유의 암호"체크를 구현합니다. 암호를 소금에 절이고 해싱하고 일반 텍스트로 저장하지 않으면 실제로 고유성 검사를 수행하는 O (n) (고가) 작업입니다.

10,000 명의 사용자가 있고 새로운 사용자가 비밀번호를 등록하거나 변경할 때마다 고유성을 확인하는 데 30 초가 걸린다고 상상할 수 있습니까?

나는 이것이 당신이 고객에게 가져 가야 할 반응이라고 생각합니다.

질문을하기에 적절한 장소라는 점만 생각하면 Stack Exchange의 IT 보안 섹션이 도움이 될 것입니다. /security/tagged/passwords를 시도 하십시오 . IT 보안에 중점을 둔 개인이 특정 답변을 제공 할 수 있어야합니다.

그는 아마도 RSA 2 단계 암호화를 원할 것입니다. Active Directory 또는 ASP.NET 멤버쉽을 사용하는 경우 이는 쉬운 일이 아닙니다.

하드웨어 또는 소프트웨어 토큰은 PIN 코드가 뒤에 오는 시간 종속 고유 비밀번호를 생성합니다. 이것은 함께 각 사용자에게 고유 한 암호를 제공합니다.