이후 일반 텍스트 검색을 위해 어떻게 사용자 암호 저장소에 윤리적으로 접근해야합니까?

점점 더 많은 웹 사이트와 웹 응용 프로그램을 계속 구축함에 따라 사용자에게 문제가 발생했을 때 검색 할 수있는 방식으로 사용자 암호를 저장하라는 메시지가 자주 표시됩니다 (잊어 버린 암호 링크를 이메일로 보내거나 전화 등)) 내가이 관행에 맞서 싸울 수있을 때 실제 비밀번호를 저장하지 않고 비밀번호 재설정 및 관리 지원을 가능하게하는 '추가'프로그래밍을 많이합니다.

내가 싸울 수 없을 때 (또는 이길 수없는 경우) 비밀번호는 데이터베이스에 일반 텍스트로 저장되지 않도록 항상 어떤 방식 으로든 비밀번호를 인코딩합니다.하지만 DB가 해킹 될 경우 범인이 암호를 해독하는 데 많은 시간이 걸리지 않으므로 불편합니다.

완벽한 세계 사람들은 암호를 자주 업데이트하고 여러 사이트에 걸쳐 복제하지 않습니다. 불행히도 나는 같은 직장 / 가정 / 이메일 / 은행 암호를 가진 많은 사람들을 알고 있으며 도움이 필요할 때 자유롭게 암호를 제공합니다. DB 보안 절차가 어떤 이유로 실패하면 재정적 소멸을 책임지는 사람이되고 싶지 않습니다.

도덕적, 윤리적으로 저는 일부 사용자의 경우 생계를 훨씬 덜 존중하더라도 보호 할 책임이 있습니다. 솔트 해시 및 다른 인코딩 옵션에 대해 접근해야 할 방법과 인수가 많이 있다고 확신하지만, 저장해야 할 때 '최상의 사례'가 있습니까? 거의 모든 경우에 나는 PHP와 MySQL을 사용하고 있는데, 그것이 세부 사항을 처리 해야하는 방식에 차이가 있다면.

현상금에 대한 추가 정보

나는 이것이 당신이하고 싶은 것이 아니며 대부분의 경우 거부하는 것이 가장 좋다는 것을 알고 싶습니다. 그러나 나는이 접근법을 취하는 장점에 대한 강의를 찾고 있지 않습니다.이 접근법을 취하면 취할 수있는 최선의 조치를 찾고 있습니다.

아래의 메모에서 나는 노인들, 정신적으로 어려움을 겪고 있거나 매우 어린 사람들을 위해 마련된 웹 사이트가 안전한 암호 복구 루틴을 수행하도록 요청받을 때 사람들에게 혼란을 줄 수 있다고 지적했다. 이러한 경우에는 간단하고 평범한 것을 알 수 있지만 일부 사용자는 서비스 기술을 사용하여 시스템에 도움을 주거나 직접 전자 메일 / 표시하도록하는 추가 지원이 필요합니다.

이러한 시스템에서 사용자가 이러한 수준의 액세스 지원을 제공하지 않으면 이러한 인구 통계의 감소율이 응용 프로그램을 방해 할 수 있으므로 이러한 설정을 염두에두고 응답하십시오.

모두에게 감사 드려요

이것은 많은 토론과 함께 재미있는 질문이었고 나는 그것을 즐겼습니다. 결국 나는 암호 보안을 유지하는 대답 (일반 텍스트 또는 복구 가능한 암호를 유지할 필요는 없지만)에서 내가 찾은 주요 단점없이 시스템에 로그인 할 수 있도록 지정한 대답을 선택했습니다. 정상적인 비밀번호 복구.

언제나 그렇듯이 여러 가지 이유로 정답으로 표시하고 싶은 약 5 개의 답변이 있었지만 가장 좋은 답변을 선택해야했습니다. 나머지는 모두 +1이었습니다. 모두 감사합니다!

또한이 질문에 투표하고 / 또는 좋아하는 것으로 표시 한 스택 커뮤니티의 모든 사람들에게 감사드립니다. 저는 칭찬으로 100 표를 얻었으며이 토론이 다른 사람이 저와 같은 관심사를 갖는 데 도움이 되었기를 바랍니다.

이 문제에 대해 다른 접근법이나 각도를 취하는 것은 어떻습니까? 비밀번호가 일반 텍스트 여야하는 이유를 묻습니다. 사용자가 비밀번호를 검색 할 수 있도록 설정 한 경우 엄격하게 말하면 설정 한 비밀번호를 실제로 검색 할 필요는 없습니다 (어쨌든 무엇인지 기억하지 못함). 그들이 사용할 수 있는 암호를 제공 할 수 있어야 합니다 .

생각해보십시오. 사용자가 비밀번호를 검색해야하는 경우 비밀번호를 잊어 버렸기 때문입니다. 이 경우 새 비밀번호는 이전 비밀번호와 동일합니다. 그러나 오늘날 사용되는 일반적인 비밀번호 재설정 메커니즘의 단점 중 하나는 재설정 작업에서 생성 된 생성 된 비밀번호가 일반적으로 임의의 문자이기 때문에 복사 -n-가 아닌 한 사용자가 정확하게 입력하기가 어렵다는 것입니다. 풀. 잘 모르는 컴퓨터 사용자에게는 문제가 될 수 있습니다.

이 문제를 해결하는 한 가지 방법은 다소 자연스러운 언어 텍스트 인 자동 생성 암호를 제공하는 것입니다. 자연어 문자열에는 길이가 같은 임의의 문자열이 갖는 엔트로피가 없을 수 있지만 자동 생성 암호에는 8 자 (또는 10 자 또는 12 자) 만 있으면됩니다. 여러 개의 임의의 단어를 함께 묶어 높은 엔트로피 자동 생성 암호 문구를 얻으십시오 (그 사이에 공백을 남기면 읽을 수있는 사람이 여전히 인식하고 입력 할 수 있습니다). 길이가 변하는 6 개의 임의 단어는 10 개의 임의 문자보다 정확하게 입력하기 쉽고 아마도 더 높은 엔트로피를 가질 수 있습니다. 예를 들어 대문자, 소문자, 숫자 및 10 문장 부호 (총 72 개의 유효 기호)는 61.7 비트의 엔트로피를 갖습니다. 6 개 단어 암호 구에 대해 무작위로 선택할 수있는 7776 개 단어 사전 (Diceware에서 사용)을 사용하면 암호 구의 엔트로피는 77.4 비트가됩니다. 참조자세한 내용은 Diceware FAQ 를 참조하십시오.

• 약 77 비트의 엔트로피를 가진 암호문 : "산문 플레어 테이블 급성 감각을 인정하십시오"

• 약 74 비트 엔트로피의 암호 : "K : & $ R ^ tt ~ qkD"

문구를 입력하는 것을 선호하며 copy-n-paste를 사용하면 문구도 암호를 사용하기가 쉽지 않으므로 손실이 없습니다. 물론 귀하의 웹 사이트 (또는 보호 된 자산이 무엇이든)가 자동 생성 암호 문구에 77 비트의 엔트로피가 필요하지 않은 경우 더 적은 단어를 생성하십시오 (사용자가 높이 평가할 것입니다).

본인은 실제로 가치가 높지 않은 비밀번호로 보호 된 자산이 있다는 주장을 이해하므로 비밀번호의 위반이 세상의 종말이 아닐 수도 있습니다. 예를 들어, 다양한 웹 사이트에서 사용하는 암호의 80 %가 위반 된 경우에는 신경 쓰지 않을 것입니다. 발생할 수있는 모든 사람은 스팸 또는 제 이름으로 게시 한 사람입니다. 그다지 좋지는 않지만 그들이 내 은행 계좌에 침입하는 것과는 다릅니다. 그러나 많은 사람들이 자신의 은행 계좌 (및 아마도 국가 보안 데이터베이스)와 같은 웹 포럼 사이트에 동일한 암호를 사용한다는 사실을 감안할 때, 저 가치의 암호조차도 그렇지 않은 것으로 취급하는 것이 가장 좋습니다 -회복 가능.

누군가가 큰 건물을 건축하도록 의뢰했다고 상상해 봅시다. 다음과 같은 대화가 이루어집니다.

건축가 : 이 크기와 용량을 가진 건물의 경우 여기, 여기, 여기에 화재 출구가 필요합니다.
클라이언트 : 아니요, 유지 관리하기에는 너무 복잡하고 비용이 많이 듭니다. 사이드 도어 나 백도어를 원하지 않습니다.
건축가 : 각하, 화재 출구는 선택 사항이 아니며 도시의 화재 코드에 따라 필요합니다.
클라이언트 : 나는 당신에게 논쟁을 지불하지 않습니다. 내가 부탁 한대로하세요

그런 다음 건축가는 화재 출구 없이이 건물을 윤리적으로 건축하는 방법을 묻습니까?

건축 및 엔지니어링 산업에서 대화는 다음과 같이 끝날 가능성이 높습니다.

건축가 : 이 건물은 비상구가 없으면 지을 수 없습니다. 다른 면허가있는 전문가에게 갈 수 있으며 그는 같은 것을 말할 것입니다. 나는 지금 떠나고있다. 협조 할 준비가되면 다시 전화 해주세요.

컴퓨터 프로그래밍은 허가 된 직업 이 아닐 수도 있지만 사람들은 종종 우리 직업이 토목 엔지니어 나 기계 엔지니어와 같은 존경을받지 않는 이유를 궁금해하는 것 같습니다. 이러한 직업은 쓰레기 (또는 완전히 위험한) 요구 사항을 전달할 때 간단히 거부됩니다. 그들은 "내가 최선을 다했지만 그는 주장했다. 나는 그가 말한 것을해야한다"고 말하는 변명이 아니라는 것을 알고있다. 그들은 그 변명에 대한 면허를 잃을 수 있습니다.

귀하 또는 귀하의 고객이 공개적으로 거래되는 회사의 일부인지 여부는 알 수 없지만 복구 가능한 형태로 비밀번호를 저장하면 여러 유형의 보안 감사에 실패 할 수 있습니다. 데이터베이스에 액세스 한 일부 "해커"가 암호를 복구하는 것이 얼마나 어려운지는 문제가 아닙니다. 대부분의 보안 위협은 내부에 있습니다. 당신이 보호해야 할 것은 모든 비밀 번호로 걸어서 가장 높은 입찰자에게 판매하는 불만을 품은 직원입니다. 비대칭 암호화를 사용하고 개인 키를 별도의 데이터베이스에 저장하면이 시나리오를 막을 수있는 것은 없습니다. 개인 데이터베이스에 액세스 할 수있는 사람 이 항상있을 것이므로 심각한 보안 위험이 있습니다.

암호를 복구 가능한 형식으로 저장하는 윤리적이거나 책임있는 방법은 없습니다. 기간.

공개 키로 암호와 소금을 암호화 할 수 있습니다. 로그인의 경우 저장된 값이 사용자 입력 + salt에서 계산 된 값과 같은지 확인하십시오. 암호를 일반 텍스트로 복원해야 할 때가 오면 개인 키를 사용하여 수동 또는 반자동으로 암호를 해독 할 수 있습니다. 개인 키는 다른 곳에 저장 될 수 있고 대칭 적으로 암호화 될 수있다 (비밀번호를 해독하기 위해서는 인간의 상호 작용이 필요할 것이다).

이것이 실제로 Windows 복구 에이전트의 작동 방식과 비슷하다고 생각 합니다.

• 비밀번호는 암호화되어 저장됩니다
• 일반 텍스트로 해독하지 않고도 로그인 할 수 있습니다
• 암호는 일반 텍스트로 복구 할 수 있지만 개인 키를 통해서만 시스템 외부에 저장할 수 있습니다 (원하는 경우 은행 금고에 저장).

포기하지 마십시오. 고객을 확신시키는 데 사용할 수있는 무기는 부인할 수 없습니다. 당신이 어떤 메커니즘을 통해 사용자 암호를 재구성 할 수 있다면, 당신은 준 그들의 고객에게 법적 부인 방지 메커니즘을 그리고 그들은 방법이 없기 때문에 공급 업체들이 암호를 재구성하지 않았다는 것을 증명할 수, 해당 암호에 따라 트랜잭션을 부인할 수 거래 자체를 통해. 암호가 암호문이 아닌 다이제스트로 올바르게 저장되면 불가능합니다. 최종 클라이언트가 직접 트랜잭션을 실행했거나 암호로 관리 의무를 위반 한 것입니다. 두 경우 모두 그에 대한 책임을 그에게 맡깁니다. 나는 그것이 수억 달러에 달하는 사례를 연구했습니다. 잘못하고 싶은 것이 아닙니다.

나중에 일반 텍스트 검색을 위해 암호를 윤리적으로 저장할 수 없습니다. 그렇게 간단합니다. Jon Skeet조차도 나중에 일반 텍스트 검색을 위해 암호를 윤리적으로 저장할 수 없습니다. 사용자가 어떤 식 으로든 일반 텍스트로 암호를 검색 할 수 있으면 해커도 코드에서 보안 취약점을 발견 할 수 있습니다. 그리고 그것은 단지 하나의 사용자 암호 만이 아니라 모든 암호 입니다.

고객에게 문제가있는 경우 암호를 복구 가능하게 저장하는 것은 법에 위배된다고 말합니다. 영국의 데이터 보호법 1998 (특히, Schedule 1, Part II, 9 항)은 데이터 컨트롤러가 개인 정보를 안전하게 유지하기 위해 적절한 기술적 수단을 사용해야합니다. 데이터가 손상된 경우 발생할 수있는 피해-사이트간에 비밀번호를 공유하는 사용자에게 상당한 영향을 줄 수 있습니다. 그래도 문제가 있다는 사실을 이해하는 데 어려움이 있다면 이 사례와 같은 실제 사례를 지적하십시오 .

사용자가 로그인을 복구 할 수있는 가장 간단한 방법은 사용자에게 자동으로 로그인하여 새 비밀번호를 선택할 수있는 페이지로 바로 연결되는 일회성 링크를 이메일로 보내는 것입니다. 프로토 타입을 만들어 실제로 보여줍니다.

다음은이 주제에 대해 쓴 몇 가지 블로그 게시물입니다.

• http://jamesmckay.net/2009/09/if-you-are-saving-passwords-in-clear-text-you-are-pro-ably-breaking-the-law/
• http://jamesmckay.net/2008/06/easy-login-recovery-without-compromising-security/

업데이트 : 이제 사용자 암호를 제대로 보호하지 못하는 회사에 대한 소송 및 기소가 시작되었습니다. 예 : 링크드 인은 5 백만 달러의 소송 소송으로 철회했습니다 . 소니는 PlayStation 데이터 핵보다 25 만 파운드의 벌금을 물었다 . 내가 올바르게 기억한다면 LinkedIn은 실제로 사용자의 암호를 암호화하고 있었지만 사용하는 암호화가 너무 약해서 효과적이지 않았습니다.

이 부분을 읽은 후 :

아래의 메모에서 나는 보안 암호 복구 루틴을 수행하라는 요청을받을 때 웹 사이트가 노인들, 정신적으로 어려움을 겪고 있거나 매우 어린 사람들을 위해 웹 사이트를 혼란스럽게 만들 수 있다고 지적했다. 이러한 경우에는 단순하고 평범한 것을 알 수 있지만 일부 사용자는 서비스 기술을 사용하여 시스템에 도움을 주거나 직접 전자 메일 / 표시하도록하는 추가 지원이 필요합니다.

이러한 시스템에서 사용자가 이러한 수준의 액세스 지원을 제공받지 않으면 이러한 인구 통계의 감소율이 응용 프로그램을 방해 할 수 있으므로 이러한 설정을 염두에두고 답변하십시오.

이러한 요구 사항 중 하나라도 검색 가능한 암호 시스템을 요구하는지 궁금합니다. 예를 들면 : Aabel Mabel이 전화하여 "인터넷 프로그램이 작동하지 않습니다. 암호를 모르겠습니다"라고 말합니다. "확인"고객 서비스 드론 "몇 가지 세부 정보를 확인 하고 새 암호를 알려 드리겠습니다" . 다음에 로그인 할 때 해당 비밀번호를 유지할지 또는 기억할 수있는 것으로 변경할 것인지 묻습니다." 더 쉽게."

그런 다음 시스템은 암호 재설정이 언제 발생했는지 알고 "새 암호를 유지 하시겠습니까? 새 암호를 선택 하시겠습니까?"메시지를 표시합니다.

PC 암호가 적을 때 이전 암호를 듣는 것보다 어떻게 나쁜가요? 또한 고객 서비스 담당자는 장난에 빠질 수 있지만 데이터베이스 자체는 보안 침해를 당할 경우 훨씬 안전합니다.

내 제안에 나쁜 점이 있으면 처음에 원하는 것을 실제로 수행하는 솔루션을 제안합니다.

Michael Brooks는 CWE-257에 대해 보컬을 해왔습니다. 어떤 방법을 사용하든 관리자 (관리자)는 여전히 암호를 복구 할 수 있습니다. 이러한 옵션은 어떻습니까?

1. 다른 사람의 공개 키 ( 일부 외부 권한)로 비밀번호를 암호화하십시오 . 그렇게하면 개인적으로 재구성 할 수 없으며 사용자는 해당 외부 기관으로 이동하여 암호를 복구하도록 요청해야합니다.
2. 두 번째 비밀번호 문구에서 생성 된 키를 사용하여 비밀번호를 암호화하십시오. 이 암호화를 클라이언트 측에서 수행하고 절대로 서버로 전송하지 마십시오. 그런 다음 복구하려면 입력에서 키를 다시 생성하여 해독 클라이언트 측을 다시 수행하십시오. 물론이 방법은 기본적으로 두 번째 암호를 사용하지만 항상 암호를 적어 두거나 이전 보안 질문 방법을 사용하도록 지시 할 수 있습니다.

고객 회사 내에서 개인 키를 보유 할 사람을 지정할 수 있기 때문에 1.이 더 나은 선택이라고 생각합니다. 키 자체를 생성하고 안전한 곳에 지시 사항과 함께 키를 저장하도록하십시오. 암호에서 특정 문자를 내부 제 3 자에게만 암호화하여 제공하도록 선택하여 보안을 추가 할 수 있으므로 추측하기 위해 암호를 해독해야합니다. 그것. 이 문자를 사용자에게 제공하면 아마도 그것이 무엇인지 기억할 것입니다!

이 질문에 대한 응답으로 사용자의 보안 문제에 대해 많은 논의가 있었지만 이점에 대해 언급하고 싶습니다. 지금까지 시스템에 복구 가능한 암호를 저장 한 것에 대해 언급 한 하나의 합법적 인 이점 은 보지 못했습니다 . 이걸 고려하세요:

• 사용자는 자신의 암호를 이메일로받는 것이 유리합니까? 아뇨 희망 그들이 암호를 선택할 수 있도록 해주는 일회용 암호 재설정 링크에서 더 많은 혜택을받을 것입니다 기억을.
• 사용자가 비밀번호를 화면에 표시하면 이점이 있습니까? 위와 같은 이유로 아닙니다. 새 비밀번호를 선택해야합니다.
• 사용자는 지원 담당자가 사용자에게 비밀번호를 말하도록하는 것이 유리합니까? 아니; 지원 담당자가 사용자의 암호 요청이 올바르게 인증 된 것으로 간주하면 새 암호를 제공하고 암호를 변경할 수있는 기회가 더 커집니다. 또한 전화 지원은 자동화 된 비밀번호 재설정보다 비용이 많이 들기 때문에 회사는 혜택을받지 않습니다.

복구 가능한 암호의 이점을 얻을 수있는 유일한 방법은 악의적 인 의도가 있거나 불량한 API를 지원하는 타사의 암호 교환이 필요한 것 같습니다 (해당 API를 사용하지 마십시오). 아마도 당신은 회사가 복구 가능한 암호를 저장함으로써 이익과 부채 만 얻지 못한다는 사실을 고객들에게 진실로 진술함으로써 당신의 주장을 이길 수있을 것 입니다.

이러한 유형의 요청 사이를 읽으면 클라이언트가 암호 관리 방법을 전혀 이해하지 못하거나 실제로 신경 쓰지 않을 것입니다. 그들이 정말로 원하는 것은 사용자에게 그리 어렵지 않은 인증 시스템 입니다. 따라서 실제로 복구 가능한 암호를 원하지 않는 방법을 알려주는 것 외에도 특히 은행과 같은 강력한 보안 수준이 필요하지 않은 경우 인증 프로세스를 덜 고통스럽게 만드는 방법을 제공해야합니다.

• 사용자가 자신의 사용자 이름으로 이메일 주소를 사용할 수 있도록합니다. 사용자가 자신의 사용자 이름을 잊어 버린 셀 수없는 경우를 보았지만 이메일 주소를 잊어 버린 사람은 거의 없었습니다.
• OpenID를 제공하고 제 3자가 사용자의 건망증 비용을 지불하게하십시오.
• 암호 제한을 완화하십시오. "특수 문자를 사용할 수 없습니다"또는 "비밀번호가 너무 깁니다"또는 "비밀번호를 시작해야합니다"와 같은 쓸모없는 요구 사항으로 인해 일부 웹 사이트에서 선호하는 비밀번호를 허용하지 않을 경우 모두 매우 귀찮게 생각합니다 편지와 함께. " 또한 사용하기 쉬움이 암호 강도보다 큰 문제인 경우 암호를 짧게하거나 문자 클래스를 혼합하지 않아도 멍청하지 않은 요구 사항도 완화 할 수 있습니다. 제한이 완화되면 사용자는 잊을 수없는 암호를 사용하게됩니다.
• 비밀번호를 만료하지 마십시오.
• 사용자가 이전 비밀번호를 재사용 할 수 있도록합니다.
• 사용자가 자신의 비밀번호 재설정 질문을 선택할 수 있도록합니다.

그러나 어떤 이유로 든 (그리고 그 이유를 알려주세요) 실제로 복구 가능한 암호를 가질 수 있어야하는 경우 암호가 아닌 다른 온라인 계정을 사용하여 사용자가 다른 온라인 계정을 손상시키지 않도록 보호 할 수 있습니다. 기반 인증 시스템. 사람들은 이미 사용자 이름 / 비밀번호 시스템에 익숙하고 잘 훈련 된 솔루션이기 때문에 이것이 최후의 수단이지만 비밀번호에 대한 창의적인 대안이 많이 있습니다.

• 사용자가 4 자리가 아닌 숫자 핀을 선택하도록하고, 무차별 대입 시도가 방지되는 경우에만 사용하는 것이 좋습니다.
• 사용자는 자신 만 답을 알고, 결코 변하지 않으며, 항상 기억하며, 다른 사람들이 찾는 것을 신경 쓰지 않는 짧은 답변으로 질문을 선택하게합니다.
• 사용자가 사용자 이름을 입력 한 다음 추측으로부터 보호하기에 충분한 순열을 가지고 기억하기 쉬운 모양을 그리도록 합니다 (G1이 전화 잠금을 해제하는 방법에 대한 멋진 사진 참조 ).
• 어린이 웹 사이트의 경우 사용자 이름 (identicon과 같은 종류)을 기반으로 퍼지 생물을 자동 생성하고 생물에게 비밀 이름을 제공하도록 요청할 수 있습니다. 그런 다음 로그인 할 생물체의 비밀 이름을 입력하라는 메시지가 표시 될 수 있습니다.

내가 질문에 대한 의견에 따라 :
하나의 중요한 요점은 거의 모든 사람들에 의해 매우 반가워졌습니다 ... 나의 첫 반응은 @stefanw와 같은 문제가 깨진 요구 사항이라는 것을 깨달을 때까지 @Michael Brooks와 매우 유사했습니다. 그러나 이것들은 그들이있는 것입니다.
그러나 그때조차도 그렇지 않을 수도 있습니다! 여기서 누락 된 점 은 응용 프로그램 자산 의 무언의 가치 입니다. 간단히 말해, 가치가 낮은 시스템의 경우 모든 프로세스가 포함 된 완전히 안전한 인증 메커니즘은 과도하게 사용되며 잘못된 보안 선택이 될 것입니다.
분명히 은행의 경우 "모범 사례"는 필수이며 CWE-257을 윤리적으로 위반할 방법이 없습니다. 그러나 가치가없는 저비용 시스템을 쉽게 생각할 수 있습니다 (단순한 암호는 여전히 필요합니다).

진정한 보안 전문 지식은 누구나 온라인에서 읽을 수있는 "모범 사례"를 독단적으로 내뱉는 것이 아니라 적절한 상충 관계를 찾는 데 있다는 점을 명심해야합니다.

: 따라서, 나는 다른 해결책을 제안
시스템의 값에 따라, 그리고 하는 경우에만 시스템이 적절하게 아니오 "비싼"자산 (신원 자체 포함)와 낮은 값, 및 적절한 과정을 유효한 비즈니스 요구 사항이 있습니다 불가능 (또는 비용 / 충분히 어려운), 및 클라이언트가 ... 모든주의 사항을 알고 만든
그 다음은 특별한 농구를 통해 뛰어 없습니다로 간단하게 해독 가능한 암호화를 허용하는 것이 적합 할 수있다.
구현하기가 매우 간단하고 저렴하기 때문에 (암호화 키 관리를 고려하더라도) 암호화를 전혀 사용하지 않으며, 일부 보호 기능을 제공합니다 (구현 비용 이상). 또한 전자 메일을 통해, 화면에 표시하는 등의 방법으로 사용자에게 원래 암호를 제공하는 방법을 살펴볼 가치가 있습니다.
여기에서의 가정은 도난당한 암호의 값 (집합 적으로도)이 매우 낮다는 것이므로 이러한 솔루션 중 하나라도 유효 할 수 있습니다.

다른 게시물과 별도의 댓글 스레드에서 실제로 활발한 토론이 진행되고 있기 때문에 몇 가지 설명을 추가하고 여기 다른 곳에서 제기 된 매우 좋은 요점에 응답합니다.

우선, 여기에 모든 사람이 사용자의 원래 암호를 검색하고 나쁜 습관이며 일반적으로 좋은 생각이 아니라는 것이 분명하다고 생각합니다. 그것은 전혀 논쟁의 여지가 없습니다 ...
또한, 나는 대부분의 상황에서 실제로 잘못되고, 심지어 파울, 불쾌하고, 추악 하다고 강조합니다 .

그러나 문제의 핵심은 원칙을 중심으로 하며 , 이것을 금지 할 필요가없는 상황 이 있는가? 그렇다면 그 상황에 가장 적합한 방법으로 그렇게하는 방법이있다 .

이제 @Thomas, @sfussenegger 및 다른 사람들이 언급 한 것처럼, 그 질문에 대답하는 유일한 올바른 방법은 주어진 (또는 가상의) 상황에 대한 철저한 위험 분석 을 수행하여 위험에 처한 것을 이해하고 보호해야 할 가치를 이해하는 것입니다 보호 기능을 제공하기 위해 수행중인 다른 완화 조치
아닙니다.이 용어는 유행어가 아니며 실제 보안 전문가에게 가장 중요한 기본 도구 중 하나입니다. 모범 사례는 신중한 위험 분석이 수행 된 후 (보통 경험이없는 사람과 해킹에 대한 지침으로) 어느 정도까지 좋습니다.

알다시피, 재밌습니다. 저는 항상 나 자신을 보안 광신자 중 한 사람으로 여겼으며, 어떻게 든 소위 "보안 전문가"의 반대편에 있습니다. 글쎄, 진실은-광신자이기 때문입니다. 그리고 실제 실제 보안 전문가-나는 그 중요한 위험 분석 없이 "최상의 관행"교리 (또는 CWE)를 내뿜는 것을 믿지 않습니다 .
"실제로 어떤 문제를 방어하고 있는지 모른 채 툴 벨트에 모든 것을 신속하게 적용 할 수있는 보안 열광자를 조심하십시오. 더 많은 보안이 반드시 좋은 보안과 동일하지는 않습니다."
위험 분석 및 진정한 보안 광신자는 위험, 잠재적 손실, 가능한 위협, 보완 완화 등을 기반으로 더 현명하고 가치 / 위험 기반의 트레이드 오프를 가리킬 것입니다. 위험 분석을 소리로 지적 할 수없는 "보안 전문가" 권장 사항에 대한 근거 또는 논리적 균형을 지원하지만 위험 분석을 수행하는 방법을 이해하지 못하고 도그마와 CWE를 추출하는 것을 선호하지만 보안 해킹은 아니지만 Nack은 전문 지식이 인쇄 된 화장지 가치가 없습니다.

실제로, 이것이 우리가 공항 보안 인 어리 석음을 얻는 방법입니다.

그러나이 상황에서해야 할 적절한 절충에 대해 이야기하기 전에 명백한 위험을 살펴 보겠습니다 (이 상황에 대한 배경 지식이 모두 없기 때문에 우리는 모두 가설을 세웁니다. 상황이있을 수 있습니다 ...)
저가형 시스템을 가정 해 보자. 그러나 대중이 접근하기에는 부족하지 않습니다. 시스템 소유자는 일반적인 명의 도용을 방지하려고하지만 "높은"보안은 사용 편의성만큼 중요하지 않습니다. (예, 능숙한 스크립트 사용자가 사이트를 해킹 할 수있는 위험을 받아들이는 것은 합법적 인 트레이드 오프입니다. 잠깐, APT는 유행하지 않습니다 ...?)
예를 들어, 대가족 모임을위한 간단한 장소를 마련하여 올해 캠핑 여행을 가고 싶은 곳을 모두가 브레인 스토밍 할 수 있다고 가정 해 보겠습니다. Erma가 필요로 할 때 로그온 할 수 없기 때문에 익명의 해커 또는 심지어 Cousin Fred가 Wantanamanabikiliki 호수로 돌아가라는 제안을 반복해서 걱정하지 않아도됩니다. 핵 물리학자인 에르 마 이모는 암호를 기억하거나 컴퓨터를 전혀 사용하는 데 능숙하지 않습니다. 그래서 나는 그녀에게 가능한 모든 마찰을 제거하고 싶습니다. 다시 말하지만, 나는 해킹에 대해 걱정하지 않고 잘못된 로그인의 바보 같은 실수를 원하지 않습니다. 누가 오는지, 그들이 원하는 것을 알고 싶습니다.

어쨌든.
따라서 단방향 해시를 사용하는 대신 암호를 대칭 적으로 암호화하는 경우 주요 위험은 무엇입니까?

• 사용자를 가장합니까? 아니요, 나는 이미 그 위험을 받아 들였습니다. 흥미롭지는 않습니다.
• 사악한 관리자? 글쎄, 어쩌면 ... 그러나 다시 한 번, 누군가가 다른 사용자를 사칭 할 수 있는지 여부는 신경 쓰지 않습니다. 내부 또는 아니요. 어쨌든 악의적 인 관리자가 어떻게 든 상관없이 암호를 얻을 것 입니다. 관리자가 잘못되면 게임은 끝났습니다.
• 제기 된 또 다른 문제는 ID가 실제로 여러 시스템간에 공유된다는 것입니다. 아! 이것은 매우 흥미로운 위험이며 면밀한 검토가 필요합니다. 공유
  한 실제 신원이 아니라 증명 또는 인증 자격 증명 이 아니라고 가정 해 보겠습니다 . 이 경우를 제외하고는 ... 그냥 의미 그래서 좋아요, 공유 암호 때문에 효율적으로 저에게 다른 시스템에 입학을 허용합니다 (예를 들어, 내 은행 계좌, 또는 Gmail)는이 효과적으로 동일한 ID입니다 그렇지 않은 . 이 시나리오에서는 각 시스템에서 ID를 별도로 관리합니다 (OAuth와 같은 타사 ID 시스템이있을 수는 있지만이 시스템의 ID와는 별도 임).
  따라서 여기서 위험의 핵심 포인트는 사용자가 여러 다른 시스템에 자신의 (같은) 암호를 기꺼이 입력한다는 것입니다. 이제 I (관리자) 또는 내 사이트의 다른 해커는 Aerma Erma의 암호에 액세스 할 수 있습니다. 핵 미사일 사이트.

흠.

여기에 당신에게 아무것도 보이지 않습니까?

그렇습니다.

핵 미사일 시스템을 보호하는 것이 나의 책임 이 아니라는 사실부터 시작 하겠습니다. 저는 단지 (가족을위한) 가족 가족 외출 장소를 짓고 있습니다. 누구의 책임입니까? 음 ... 핵 미사일 시스템은 어때요? 어.
둘째, 누군가의 암호 (보안 사이트와 보안되지 않은 사이트간에 동일한 암호를 반복적으로 사용하는 것으로 알려진 사람)를 훔치려는 경우 왜 사이트를 해킹하는 것이 귀찮습니까? 아니면 대칭 암호화로 어려움을 겪고 있습니까? Goshdarnitall, 난 그냥 내 자신의 간단한 웹 사이트를 올릴 수 있습니다 , 사용자가 원하는 무엇이든에 대해 아주 중요한 뉴스를 받도록 가입하게 ... Puffo Presto, 나는 그들의 "비밀을 훔쳤다".

그렇습니다. 사용자 교육은 항상 hienie에서 우리를 물기 위해 돌아옵니다.
그리고 당신이 할 수있는 일은 없습니다 ... 당신이 당신의 사이트에서 자신의 암호를 해시하고 TSA가 생각할 수있는 다른 모든 것을하더라도, 당신 은 그들이 지키려고한다면 , 당신의 암호를 보호 하지 못합니다. 실수로 모든 사이트에 암호를 입력하십시오. 귀찮게 노력하지 마십시오.

달리 말하면, 당신은 그들의 암호를 소유하지 않기 때문에 , 당신 처럼 행동하려고하지 마십시오.

그래서, 친애하는 보안 전문가들은 노파가 웬디에게 "위험은 어디에 있습니까?"

위에서 제기 한 일부 문제에 대한 또 다른 몇 가지 사항 :

• CWE는 법률이나 규정 또는 표준이 아닙니다. 일반적인 약점 의 모음입니다 . 즉 "모범 사례"의 반대입니다.
• 공유 된 정체성의 문제는 실제 문제이지만, 여기의 해설자들에 의해 오해 (또는 오해)됩니다. 가치가 낮은 시스템에서 암호를 해독하는 것이 아니라 ID 자체를 공유하는 문제 (!)입니다. 값이 낮은 시스템과 값이 큰 시스템간에 암호를 공유하는 경우 문제가 이미 있습니다!
• 결국, 이전의 요점은 실제로 이러한 저 가치 시스템과 고 가치 뱅킹 시스템 모두에 대해 OAuth 등을 사용하여 AGAINST 를 가리킬 것 입니다.
• 나는 그것이 단지 예일 뿐이라는 것을 알고 있지만 (슬프게도) FBI 시스템은 실제로 가장 안전하지는 않습니다. 고양이의 블로그 서버는 아니지만 더 안전한 은행을 능가하지는 않습니다.
• 암호화 키에 대한 분할 지식 또는 이중 제어는 군대에서만 발생하지 않습니다. 사실 PCI-DSS 는 기본적으로 모든 판매자로부터 이것을 요구 하므로 더 이상 실제로는 더 이상 멀지 않습니다 (값이 정당한 경우).
• 이와 같은 질문을하는 모든 사람들에게 개발자 직업이 그렇게 나쁘게 보이는 것입니다. 보안 직업이 더 나빠 보이게하는 것은 그와 같은 답변입니다. 다시 한 번, 비즈니스 중심 위험 분석이 필요합니다. 그렇지 않으면 자신을 쓸모 없게 만듭니다. 틀린 것 외에도.
• 나는 이것이 다르게 생각하고 올바른 절충점을 찾는 훈련없이 일반 개발자를 고용하고 더 많은 보안 책임을지는 것이 좋은 생각이 아닌 이유라고 생각합니다. 여기에있는 모든 사람들에게 불쾌감은 없습니다.하지만 더 많은 훈련이 필요합니다.

아휴. 얼마나 긴 글 ...
그러나 원래의 질문에 대답하기 위해 @Shane :

• 올바른 방법으로 고객에게 설명하십시오.
• 그가 여전히 주장한다면 좀 더 설명 해줘야한다고 주장한다. 필요하다면 울화통을 던져라.
• 그에게 사업 위험을 설명하십시오. 세부 사항은 양호하고 수치는 우수하며 라이브 데모가 가장 좋습니다.
• 그가 여전히 주장하고, 유효한 사업상의 이유를 제시한다면-당신이 판단 요청을 할 시간입니다 :
  이 사이트는 가치가 낮습니까? 실제로 유효한 비즈니스 사례입니까? 당신에게 충분합니까? 유효한 비즈니스 이유보다 더 큰 다른 위험은 없습니까? (물론 클라이언트는 악의적 인 사이트가 아니지만 그로 인한 것입니다).
  그렇다면 바로 진행하십시오. 필요한 프로세스를 제자리에 두는 노력, 마찰 및 사용 상실 (가설 상 상황)의 가치는 없습니다. 다른 모든 결정 (이 상황에서)은 나쁜 트레이드 오프입니다.

따라서 결론과 실제 답변-간단한 대칭 알고리즘으로 암호화하고 강력한 ACL, 바람직하게 DPAPI 등으로 암호화 키를 보호하고 문서화하고 클라이언트 (그러한 결정을 내릴 수있는 선임자)가 사인 오프하도록합니다. 그것.

중간 집은 어때요?

강력한 암호화로 비밀번호를 저장하고 재설정을 사용하지 마십시오.

암호를 재설정하는 대신 일회용 암호를 보내도록 허용하십시오 (첫 번째 로그온이 발생하자마자 변경해야 함). 그런 다음 사용자가 원하는 비밀번호 (원하는 경우 이전 비밀번호)로 변경하도록합니다.

이것을 암호 재설정을위한 안전한 메커니즘으로 "판매"할 수 있습니다.

사용자가 원래 비밀번호를 검색 할 수있는 유일한 방법 은 사용자 자신의 공개 키로 비밀번호를 암호화하는 것입니다. 그런 다음 해당 사용자 만 암호를 해독 할 수 있습니다.

따라서 단계는 다음과 같습니다.

1. 사용자는 아직 비밀번호를 설정하지 않고 사이트 (물론 SSL을 통해)에 등록합니다. 자동으로 로그인하거나 임시 비밀번호를 제공하십시오.
2. 향후 비밀번호 검색을 위해 공개 PGP 키를 저장하도록 제안합니다.
3. 공개 PGP 키를 업로드합니다.
4. 새 비밀번호를 설정하도록 요청합니다.
5. 그들은 암호를 제출합니다.
6. 사용 가능한 최상의 비밀번호 해싱 알고리즘 (예 : bcrypt)을 사용하여 비밀번호를 해시합니다. 다음 로그인을 확인할 때 사용하십시오.
7. 공개 키를 사용하여 비밀번호를 암호화하고 별도로 저장합니다.

그런 다음 사용자가 비밀번호를 요청하면 암호화 된 (해시되지 않은) 비밀번호로 응답합니다. 사용자가 나중에 비밀번호를 검색하지 않으려는 경우 (서비스 생성 비밀번호로만 재설정 할 수 있음) 3 단계와 7 단계를 건너 뛸 수 있습니다.

당신이 스스로에게 물어봐야 할 진짜 질문은 '사람들을 설득하는데 어떻게 더 잘할 수 있는가?'입니다.

나는 같은 문제가 있습니다. 같은 방식으로 나는 누군가가 내 시스템을 해킹한다고 생각합니다. "if"문제가 아니라 "when"문제입니다.

따라서 신용 카드 또는 암호와 같은 복구 가능한 기밀 정보를 저장 해야하는 웹 사이트를 수행 해야하는 경우 내가하는 일 :

• 다음으로 암호화 : openssl_encrypt (문자열 $ data, 문자열 $ method, 문자열 $ password)
  • PHP 매뉴얼 .
• 데이터 인수 :
  • 민감한 정보 (예 : 사용자 비밀번호)
  • 필요한 경우, 예를 들어 정보가 여러 개의 민감한 정보와 같은 데이터 배열 인 경우 직렬화
• password arg : 사용자 만이 아는 정보를 사용하십시오.
  • 사용자 번호판
  • 사회 보장 번호
  • 사용자 전화 번호
  • 사용자 어머니 이름
  • 등록시 이메일 및 / 또는 SMS로 전송 된 임의의 문자열
• 방법 인수 :
  • "aes-256-cbc"와 같은 하나의 암호 방법을 선택하십시오
• "password"인수에 사용 된 정보를 데이터베이스 (또는 시스템의 모든 위치)에 저장하지 마십시오

이 데이터를 검색해야 할 경우 "openssl_decrypt ()"함수를 사용하여 사용자에게 답변을 요청하십시오. 예 : "비밀번호를 받으려면 휴대 전화 번호가 무엇입니까?"라는 질문에 대답하십시오.

PS 1 : 데이터베이스에 저장된 데이터를 비밀번호로 사용하지 마십시오. 사용자 휴대폰 번호를 저장해야하는 경우이 정보를 사용하여 데이터를 인코딩하지 마십시오. 항상 사용자 만 알고 있거나 관련이없는 사람에게는 어려운 정보를 사용하십시오.

PS 2 : "원 클릭 구매"와 같은 신용 카드 정보의 경우 로그인 비밀번호를 사용합니다. 이 비밀번호는 데이터베이스 (sha1, md5 등)에서 해시되지만 로그인시 일반 텍스트 비밀번호를 세션 또는 비 지속적 (예 : 메모리) 보안 쿠키에 저장합니다. 이 평범한 비밀번호는 절대 데이터베이스에 남지 않으며, 실제로는 항상 메모리에 남고 섹션 끝에서 파괴됩니다. 사용자가 "원 클릭 구매"버튼을 클릭하면 시스템이이 비밀번호를 사용합니다. 사용자가 페이스 북, 트위터 등과 같은 서비스로 로그인 한 경우 구매시 비밀번호를 다시 입력하거나 (완전히 "클릭 할 때"가 아님) 사용자가 로그인 할 때 사용한 일부 서비스 데이터를 사용합니다 (페이스 북 ID와 같은).

자격 증명 보안은 이진 작업이 아닙니다. 보안 / 보안이 아닙니다. 보안은 위험 평가에 관한 것이며 연속체로 측정됩니다. 보안 광신자들은 이런 식으로 생각하는 것을 싫어하지만, 추악한 진실은 아무것도 완벽하게 안전하지 않다는 것입니다. 엄격한 비밀번호 요구 사항, DNA 샘플 및 망막 스캔이 포함 된 해시 비밀번호는 더 안전하지만 개발 및 사용자 경험 비용이 듭니다. 일반 텍스트 암호는 훨씬 덜 안전하지만 구현하기가 저렴하지만 피해야합니다. 하루가 끝나면 위반에 대한 비용 / 이익 분석이 이루어집니다. 보안되는 데이터의 가치와 시간 가치에 따라 보안을 구현합니다.

누군가의 암호가 야생으로 들어가는 비용은 얼마입니까? 주어진 시스템에서 가장의 비용은 얼마입니까? FBI 컴퓨터에는 비용이 엄청날 수 있습니다. Bob의 일회용 5 페이지 웹 사이트에는 비용이 미미할 수 있습니다. 전문가는 고객에게 옵션을 제공하고 보안과 관련하여 모든 구현의 장점과 위험을 제시합니다. 클라이언트가 업계 표준을 따르지 않아 위험에 처할 수있는 무언가를 요청하는 경우에는 두 배가됩니다. 클라이언트가 특별히 양방향 암호화를 요청하는 경우 이의 제기를 문서화해야하지만 본인이 알고있는 최선의 방법으로 구현하지 못하게해서는 안됩니다. 하루가 끝나면 고객의 돈입니다. 예,

양방향 암호화로 비밀번호를 저장하는 경우 보안은 모두 키 관리로 이어집니다. Windows는 인증서 개인 키에 대한 액세스를 관리 계정 및 암호로 제한하는 메커니즘을 제공합니다. 다른 플랫폼에서 호스팅하는 경우 어떤 옵션을 사용할 수 있는지 확인해야합니다. 다른 사람들이 제안했듯이 비대칭 암호화를 사용할 수 있습니다.

비밀번호는 단방향 해시를 사용하여 저장해야한다는 법률이 없습니다 (영국의 데이터 보호법). 이러한 법률 중 하나에 대한 유일한 요구 사항은 보안을 위해 합리적인 조치를 취하는 것입니다. 데이터베이스에 대한 액세스가 제한되는 경우 일반 텍스트 비밀번호조차도 이러한 제한에 따라 법적으로 자격이 될 수 있습니다.

그러나 이것은 법적인 우선 순위라는 또 하나의 측면을 밝혀줍니다. 법적 우선 순위에 따라 시스템을 구축하는 산업에서 단방향 해시를 사용해야한다고 제안하는 경우에는 완전히 다릅니다. 그것이 고객을 납득시키기 위해 사용하는 탄약입니다. 합리적인 위험 평가를 제공하고, 이의를 문서화하고, 고객의 요구 사항을 충족시킬 수있는 가장 안전한 방식으로 시스템을 구현할 것을 제안하는 최선의 제안을 제외하십시오.

사용자의 보안 질문에 대한 답변을 암호화 키의 일부로 만들고 보안 질문 답변을 일반 텍스트로 저장하지 마십시오 (대신 해시).

나는 생활을 위해 다단계 인증 시스템을 구현하므로 암호를 재설정하거나 재구성 할 수 있다고 생각하는 동안 일시적으로 하나의 적은 요소를 사용하여 재설정 / 재생 워크 플로우에 대해 사용자를 인증합니다. 특히 일부 추가 요소로 OTP (일회성 비밀번호)를 사용하면 제안 된 워크 플로우에 대한 시간 창이 짧은 경우 많은 위험을 완화 할 수 있습니다. 우리는 스마트 폰용 소프트웨어 OTP 생성기를 구현했습니다 (대부분의 사용자가 이미 하루 종일 가지고 다니고 있음). 상용 플러그에 대한 불만이 제기되기 전에, 내가 말하는 것은 사용자를 인증하는 데 사용되는 유일한 요소가 아닌 경우 암호를 쉽게 검색하거나 재설정 할 수있게하는 고유의 위험을 줄일 수 있다는 것입니다.

죄송합니다. 비밀번호를 해독 할 수있는 방법이 있다면 안전한 방법은 없습니다. 격렬하게 싸우고, 잃으면 CYA.

이 흥미롭고 열렬한 토론을 만났습니다. 가장 놀랐던 점은 다음과 같은 기본적인 질문에 거의 관심을 기울이지 않았다는 것입니다.

• Q1. 사용자가 일반 텍스트로 저장된 암호에 액세스해야한다고 주장하는 실제 이유는 무엇입니까? 왜 그렇게 많은 가치가 있습니까?

사용자가 노인이거나 젊다는 정보는 실제로 그 질문에 대답하지 않습니다. 그러나 고객의 관심사를 제대로 이해하지 않고 어떻게 비즈니스 결정을 내릴 수 있습니까?

왜 중요한가요? 고객 요청의 실제 원인이 고통스럽게 사용하기 어려운 시스템이라면 정확한 원인을 해결하면 실제 문제를 해결할 수 있을까요?

이 정보가없고 해당 고객과 대화 할 수 없기 때문에 추측 만 할 수 있습니다. 사용성에 관한 것입니다. 위를 참조하십시오.

내가 본 또 다른 질문은 다음과 같습니다.

• Q2. 사용자가 처음에 암호를 기억하지 못하면 왜 이전 암호가 중요합니까?

그리고 여기에 가능한 대답이 있습니다. "miaumiau"라는 고양이를 가지고 있고 그녀의 이름을 암호로 사용했지만 잊어 버린 경우 "# zy * RW (ew")와 같은 메시지를 보내거나 미리받는 것을 선호합니까?

또 다른 가능한 이유는 사용자가 새 비밀번호를 만드는 것이 어렵다고 생각하기 때문입니다. 따라서 이전 암호를 다시 보내면 고통스러운 작업에서 그녀를 다시 구할 수 있다는 환상을 갖게됩니다.

나는 그 이유를 이해하려고 노력하고 있습니다. 그러나 그 이유가 무엇이든, 그것이 해결되어야 할 이유가 아닌 이유입니다.

사용자로서 나는 간단한 것을 원합니다! 열심히 일하고 싶지 않아!

신문을 읽기 위해 뉴스 사이트에 로그인하면 1111을 암호로 입력하고 통과하고 싶습니다 !!!

안전하지 않다는 것을 알고 있지만 누군가 내 "계정"에 액세스하는 데 관심이 있습니까? 예, 그는 뉴스도 읽을 수 있습니다!

사이트에 "개인"정보가 저장됩니까? 내가 오늘 읽은 뉴스? 그렇다면 그것은 내 사이트가 아니라 사이트의 문제입니다! 사이트가 인증 된 사용자에게 개인 정보를 표시합니까? 그런 다음 처음에는 표시하지 마십시오!

이것은 문제에 대한 사용자의 태도를 보여주기위한 것입니다.

요약하자면, 일반 텍스트 암호를 "안전하게"저장하는 방법 (문제는 불가능 함)이 아니라 고객의 실제 문제를 해결하는 방법이 문제라고 생각하지 않습니다.

잊어 버린 비밀번호 처리 :

아무도 암호를 복구 할 수 없어야합니다.

사용자가 비밀번호를 잊어 버린 경우 최소한 사용자 이름 또는 이메일 주소를 알고 있어야합니다. 요청이있을 경우 Users 테이블에서 GUID를 생성하고 guid를 매개 변수로 포함하는 링크가 포함 된 전자 메일을 사용자의 전자 메일 주소로 보냈습니다.

링크 뒤의 페이지는 매개 변수 guid가 실제로 존재하는지 (아마 시간 초과 논리가 있음) 확인하고 사용자에게 새 비밀번호를 요청합니다.

핫라인 도움말 사용자가 필요한 경우 보조금 모델에 일부 역할을 추가하고 핫라인 역할이 식별 된 사용자로 임시 로그인하도록 허용하십시오. 이러한 모든 핫라인 로그인을 기록하십시오. 예를 들어 Bugzilla는 이러한 가장 기능을 관리자에게 제공합니다.

암호화 및 분실되기 전에 등록시 일반 텍스트 비밀번호를 이메일로 보내는 것은 어떻습니까? 많은 웹 사이트가 그것을 수행하는 것을 보았습니다. 사용자의 전자 메일에서 암호를 얻는 것이 서버 / comp에 그대로 두는 것보다 안전합니다.

복구 가능한 암호를 저장하기위한 요구 사항을 거부 할 수없는 경우에는이 값을 카운터 인수로 사용하십시오.

암호를 올바르게 해시하고 사용자를위한 재설정 메커니즘을 구축하거나 시스템에서 개인 식별 정보를 모두 제거 할 수 있습니다. 이메일 주소를 사용하여 사용자 기본 설정을 구성 할 수 있지만 그 정도입니다. 쿠키를 사용하여 향후 방문시 환경 설정을 자동으로 가져오고 합리적인 기간 후에 데이터를 버립니다.

암호 정책으로 간과되는 한 가지 옵션은 암호가 실제로 필요한지 여부입니다. 비밀번호 정책이 유일하게 고객 서비스 호출을 유발하는 경우이를 제거 할 수 있습니다.

사용자가 정말 는 잊어 버린 암호를 복구해야 (예를 들어) 시스템에 액세스 할 수 있어야합니까? 그들이 정말로 원하는 것이 로그온 할 비밀번호라면, 이전 비밀번호 (무엇이든)를 지원 담당자가 자신의 비밀번호를 잃어버린 사람에게 줄 수있는 새로운 비밀번호로 바꾸는 루틴이없는 이유는 무엇입니까?

나는 정확히 이것을하는 시스템으로 작업했습니다. 지원 담당자는 현재 비밀번호가 무엇인지 알 수 없지만 새로운 값으로 재설정 할 수 있습니다. 물론 이러한 모든 재설정은 어딘가에 기록되어야하며 암호가 재설정되었다는 이메일을 사용자에게 생성하는 것이 좋습니다.

또 다른 가능성은 계정에 액세스 할 수있는 두 개의 동시 비밀번호를 갖는 것입니다. 하나는 사용자가 관리하는 "일반"암호이고 다른 하나는 지원 직원 만 알고있는 스켈레톤 / 마스터 키와 유사하며 모든 사용자에게 동일합니다. 이렇게하면 사용자에게 문제가있을 때 지원 담당자가 마스터 키로 계정에 로그인하여 사용자가 자신의 비밀번호를 다른 것으로 변경할 수 있습니다. 말할 필요도없이, 마스터 키를 사용한 모든 로그인도 시스템에 의해 기록되어야합니다. 추가 조치로, 마스터 키를 사용할 때마다 지원 담당자 신임 정보의 유효성을 검증 할 수 있습니다.

마스터 키가 없다는 의견에 대한 답변 : 사용자 이외의 다른 사람이 사용자의 계정에 액세스하는 것을 허용하는 것이 좋지 않다고 생각하는 것이 나쁘다는 데 동의합니다. 질문을 살펴보면 전제 조건은 고객이 보안이 매우 취약한 보안 환경을 의무화한다는 것입니다.

마스터 키는 처음처럼 나빠질 필요가 없습니다. 예전에는 메인 프레임 컴퓨터 운영자가 특정 상황에서 "특별한 접근"권한을 가질 필요성을 인식 한 국방 공장에서 일했습니다. 그들은 단순히 특수 암호를 밀봉 된 봉투에 넣고 운영자의 책상에 테이프로 고정했습니다. 암호를 사용하려면 (운영자가 모르는) 봉투를 열어야했습니다. 근무 교대 변경 시마다 교대 관리자의 업무 중 하나가 봉투가 열렸는지 확인하고, 그렇다면 즉시 다른 부서에서 암호를 변경했으며 새 암호를 새 봉투에 넣고 프로세스가 모두 시작되었습니다. 다시. 운영자는 왜 그것을 열 었는지에 대한 질문을 받고 사건은 기록을 위해 문서화 될 것입니다.

이것은 내가 설계 할 절차가 아니지만, 효과가 뛰어나고 뛰어난 책임 성을 제공했습니다. 모든 것이 기록되고 검토되었으며 모든 운영자는 국방성 비밀 통관을 받았으며 우리는 결코 학대를 당하지 않았습니다.

검토와 감독으로 인해 모든 운영자는 봉투를 열 수있는 권한을 잘못 사용하면 즉시 해고되고 형사 기소 될 수 있음을 알고있었습니다.

따라서 진정한 답은 그들이 신뢰할 수있는 사람들을 고용하고, 배경 점검을하고, 적절한 관리 감독과 책임을 행사하기를 원하는 경우에 맞습니다.

그러나이 빈약 한 동료의 고객이 좋은 관리를했다면 처음에는 보안에 대한 해결책을 요구하지 않았을 것입니다.

이 주제에 대해 조금이라도 이해하고 있다면, 사인온 / 암호를 사용하여 웹 사이트를 구축하는 경우 서버에서 평문 암호를 전혀 볼 수 없다고 생각합니다. 암호는 클라이언트를 떠나기 전에 해시되어야하며, 소금을 칠해야합니다.

평문 암호를 보지 못하면 검색 문제가 발생하지 않습니다.

또한 MD5와 같은 일부 알고리즘은 더 이상 안전한 것으로 간주되지 않습니다 (웹에서). 나는 그것을 스스로 판단 할 방법이 없지만 고려해야 할 것입니다.

독립형 서버에서 DB를 열고이 기능이 필요한 각 웹 서버에 암호화 된 원격 연결을 제공하십시오.
관계형 DB 일 필요는 없으며, 테이블과 행 대신 폴더와 파일을 사용하여 FTP 액세스가 가능한 파일 시스템 일 수 있습니다.
가능하면 웹 서버에 쓰기 전용 권한을 부여하십시오.

검색 할 수없는 암호의 암호화 된 암호를 일반 사람들처럼 사이트의 DB에 저장하십시오 ( "pass-a"라고 함).
. 각 새 사용자 (또는 암호 변경)는 암호의 일반 사본을 원격 DB에 저장합니다. 서버 ID, 사용자 ID 및 "pass-a"를이 비밀번호의 복합 키로 사용하십시오. 밤에는 더 잘 자기 위해 암호에 양방향 암호화를 사용할 수도 있습니다.

이제 누군가가 비밀번호와 컨텍스트 (사이트 ID + 사용자 ID + "pass-a")를 모두 얻으려면 다음을 수행해야합니다.

1. 웹 사이트의 DB를 해킹하여 ( "pass-a", user id) 쌍을 얻습니다.
2. 일부 구성 파일에서 웹 사이트의 ID를 얻습니다.
3. 원격 암호 DB를 찾아서 해킹하십시오.

비밀번호 검색 서비스의 접근성을 제어 할 수 있으며 (보안 웹 서비스로만 노출, 하루에 특정 양의 비밀번호 검색 만 허용, 수동으로 수행 등)이 "특별한 보안 조정"에 대해 추가 요금을 청구 할 수도 있습니다.
암호 검색 DB 서버는 많은 기능을 제공하지 않으며 보안을 강화할 수 있으므로 숨겨져 있습니다 (권한, 프로세스 및 서비스를 엄격하게 조정할 수 있음).

대체로 해커의 작업을 어렵게 만듭니다. 단일 서버의 보안 침해 가능성은 여전히 ​​동일하지만 의미있는 데이터 (계정 및 비밀번호와 일치)를 모으기가 어렵습니다.

고려하지 않은 다른 옵션은 이메일을 통한 작업을 허용하는 것입니다. 약간 성가신 일이지만, 사용자가 시스템의 특정 부분을 보려고 (읽기 전용) 시스템 외부에 사용자가 필요한 클라이언트를 위해 이것을 구현했습니다. 예를 들면 다음과 같습니다.

1. 사용자가 등록되면 일반 웹 사이트와 같은 모든 액세스 권한을 갖습니다. 등록시 이메일이 포함되어야합니다.
2. 데이터 또는 조치가 필요하고 사용자가 비밀번호를 기억하지 못하는 경우에도 일반 " 제출 "바로 옆 에있는 특수한 " 허가를 위해 이메일 보내기 "단추 를 클릭하여 조치를 수행 할 수 있습니다. "단추 .
3. 그런 다음 요청을 수행 할 것인지 묻는 하이퍼 링크와 함께 요청이 이메일로 전송됩니다. 비밀번호 재설정 이메일 링크와 유사하지만 비밀번호를 재설정하는 대신 일회성 작업을 수행합니다. .
4. 그런 다음 사용자가 "예"를 클릭하면 데이터가 표시되어야하는지 또는 작업 수행, 데이터 공개 등을 확인합니다.

주석에서 언급했듯이 전자 메일이 손상된 경우 작동하지 않지만 암호를 재설정하지 않으려는 경우 @joachim의 주석을 처리합니다. 결국 암호 재설정을 사용해야하지만, 필요할 때보다 편리한 시간에 또는 관리자 나 친구의 도움을 받아 암호 재설정을 수행 할 수 있습니다.

이 솔루션의 트위스트는 작업 요청을 타사의 신뢰할 수있는 관리자에게 보내는 것입니다. 이는 노인, 정신적으로 어려움을 겪고 있거나 매우 어리거나 혼란스러운 사용자의 경우에 가장 효과적입니다. 물론이 작업을 수행하려면 신뢰할 수있는 관리자가 필요합니다.

평소와 같이 사용자의 비밀번호를 솔트 앤 해시하십시오. 사용자를 로그인 할 때 사용자의 비밀번호 (소금 / 해싱 후)를 모두 허용하고 문자 그대로 입력 한 내용도 일치하도록 허용하십시오.

이를 통해 사용자는 자신의 비밀 암호를 입력 할 수 있지만 소금 / 해시 버전의 암호를 입력 할 수 있습니다.이 암호는 누군가가 데이터베이스에서 읽을 수있는 것입니다.

기본적으로 솔트 / 해시 비밀번호를 "일반 텍스트"비밀번호로 설정하십시오.