나중에 일반 텍스트 검색을 위해 윤리적으로 사용자 암호 저장소에 접근하려면 어떻게 해야 합니까?
청렴결백한 만능 재주꾼2023. 4. 13. 10:23
반응형
질문자 :Shane
계속해서 더 많은 웹사이트와 웹 응용 프로그램을 구축함에 따라 사용자에게 문제가 있는 경우 검색할 수 있는 방식으로 사용자의 암호를 저장하라는 요청을 자주 받습니다(잊은 암호 링크를 이메일로 보내거나 전화 등) 할 수 있을 때 이 관행에 대해 격렬하게 싸울 수 있고 실제 비밀번호를 저장하지 않고도 비밀번호 재설정 및 관리 지원을 가능하게 하기 위해 많은 '추가' 프로그래밍을 수행합니다.
내가 싸울 수 없을 때(또는 이길 수 없을 때) 항상 어떤 방식으로든 암호를 인코딩하여 최소한 데이터베이스에 일반 텍스트로 저장되지 않도록 합니다. 하지만 내 DB가 해킹당하면 범인이 암호를 해독하는 데 많은 시간이 걸리지 않기 때문에 불편합니다.
완벽한 세상에서 사람들은 비밀번호를 자주 업데이트하고 여러 사이트에 복제하지 않을 것입니다. 불행히도 저는 직장/집/이메일/은행 비밀번호가 같은 많은 사람들을 알고 있으며 도움이 필요할 때 무료로 제공하기도 합니다. 나는 내 DB 보안 절차가 어떤 이유로 실패할 경우 그들의 재정적 몰락에 대한 책임이 있는 사람이 되고 싶지 않습니다.
도덕적으로나 윤리적으로 나는 일부 사용자의 생계가 될 수 있는 것을 보호해야 할 책임이 있다고 생각합니다. 나는 솔팅 해시와 다양한 인코딩 옵션에 대해 접근할 수 있는 방법과 주장이 많다고 확신하지만, 이를 저장해야 할 때 단일 '모범 사례'가 있습니까? 거의 모든 경우에 저는 PHP와 MySQL을 사용하고 있습니다. 만약 그것이 제가 세부 사항을 처리해야 하는 방식에 차이가 있다면 말입니다.
현상금에 대한 추가 정보
나는 이것이 당신이 하고 싶은 일이 아니며 대부분의 경우 그렇게 하지 않는 것이 최선이라는 것을 알고 있음을 분명히 하고 싶습니다. 그러나 나는 이 접근법을 취하는 것의 장점에 대한 강의를 찾는 것이 아니라 이 접근법을 취하는 경우 취할 수 있는 최선의 조치를 찾고 있습니다.
아래 메모에서 나는 주로 노인, 정신 장애자 또는 아주 어린 사람들을 대상으로 하는 웹 사이트가 안전한 암호 복구 루틴을 수행하라는 요청을 받을 때 사람들에게 혼란을 줄 수 있다는 점을 지적했습니다. 이러한 경우에는 간단하고 일상적일 수 있지만 일부 사용자는 서비스 기술자가 시스템에 도움을 주거나 이메일을 보내거나 직접 표시하도록 하는 추가 지원이 필요합니다.
이러한 시스템에서 사용자에게 이러한 수준의 액세스 지원이 제공되지 않으면 이러한 인구 통계의 감소율로 인해 애플리케이션이 중단될 수 있으므로 이러한 설정을 염두에 두고 응답하십시오.
모두에게 감사 드려요
이것은 많은 토론과 함께 재미있는 질문이었고 나는 그것을 즐겼습니다. 결국 나는 비밀번호 보안(일반 텍스트나 복구 가능한 비밀번호를 유지할 필요가 없음)을 유지하면서도 내가 지정한 사용자 기반이 내가 발견한 주요 단점 없이 시스템에 로그인할 수 있도록 하는 답변을 선택했습니다. 정상적인 암호 복구.
항상 그렇듯이 여러 가지 이유로 정답으로 표시하고 싶은 약 5개의 답변이 있었지만 가장 좋은 것을 선택해야 했습니다. 나머지는 모두 +1을 받았습니다. 모두 감사합니다!
또한 이 질문에 투표하거나 즐겨찾기로 표시한 Stack 커뮤니티의 모든 분들께 감사드립니다. 나는 칭찬으로 100 표를 치는 것을 받아들이고 이 토론이 나와 같은 관심사를 가진 다른 누군가를 도왔기를 바랍니다.
이 문제에 대해 다른 접근 방식이나 각도를 취하는 것은 어떻습니까? 암호가 일반 텍스트여야 하는 이유를 묻습니다. 사용자가 암호를 검색할 수 있도록 하기 위한 것이라면 엄밀히 말하면 설정한 암호를 검색할 필요가 없습니다(어쨌든 암호가 무엇인지 기억하지 못함). 사용할 수 있는 암호를 제공할 수 있어야 합니다 .
생각해 보세요. 사용자가 비밀번호를 검색해야 하는 경우 비밀번호를 잊어버렸기 때문입니다. 이 경우 새 암호는 이전 암호와 동일합니다. 그러나 오늘날 사용되는 일반적인 암호 재설정 메커니즘의 단점 중 하나는 재설정 작업에서 생성된 암호가 일반적으로 임의의 문자 묶음이므로 복사하지 않는 한 사용자가 단순히 올바르게 입력하기 어렵다는 것입니다. 반죽. 컴퓨터에 익숙하지 않은 사용자에게는 문제가 될 수 있습니다.
이 문제를 해결하는 한 가지 방법은 거의 자연어 텍스트인 자동 생성 암호를 제공하는 것입니다. 자연어 문자열에는 길이가 같은 임의의 문자로 구성된 문자열과 같은 엔트로피가 없을 수 있지만 자동 생성된 암호에 8자(또는 10 또는 12자)만 있어야 한다는 내용은 없습니다. 여러 개의 임의의 단어를 함께 연결하여 엔트로피가 높은 자동 생성 암호를 얻으십시오(읽을 수 있는 모든 사람이 여전히 인식하고 입력할 수 있도록 단어 사이에 공백을 둡니다). 다양한 길이의 무작위 단어 6개가 10개의 무작위 문자보다 정확하고 확실하게 입력하기 쉽고 엔트로피도 더 높을 수 있습니다. 예를 들어 대문자, 소문자, 숫자 및 10개의 구두점 기호(총 72개의 유효한 기호에 대해)에서 임의로 추출한 10자 암호의 엔트로피는 61.7비트의 엔트로피를 갖습니다. 6단어 암호구에 대해 무작위로 선택할 수 있는 7776단어 사전(Diceware 사용)을 사용하면 암호구는 77.4비트의 엔트로피를 갖습니다. 자세한 내용은 Diceware FAQ 를 참조하십시오.
약 77비트의 엔트로피를 가진 암호: "admit proseflare table acute flair"
약 74비트의 엔트로피를 가진 암호: "K:&$R^tt~qkD"
나는 문구를 입력하는 것을 선호한다는 것을 압니다. 그리고 copy-n-paste를 사용하면 문구가 비밀번호보다 사용하기 쉬우므로 손실이 없습니다. 물론 귀하의 웹사이트(또는 보호되는 자산이 무엇이든)에 자동 생성된 암호 문구에 대해 77비트의 엔트로피가 필요하지 않은 경우 더 적은 수의 단어를 생성하십시오(귀하의 사용자가 감사할 것이라고 확신합니다).
나는 실제로 높은 수준의 가치가 없는 암호로 보호된 자산이 있다는 주장을 이해합니다. 따라서 암호 위반이 세상의 끝이 아닐 수도 있습니다. 예를 들어, 내가 다양한 웹사이트에서 사용하는 비밀번호의 80%가 유출되더라도 상관하지 않을 것입니다. 누군가가 잠시 동안 내 이름으로 스팸을 보내거나 게시하는 것뿐입니다. 좋지는 않겠지만 그들이 내 은행 계좌에 침입할 것 같지는 않습니다. 그러나 많은 사람들이 은행 계좌(그리고 아마도 국가 안보 데이터베이스)에 사용하는 것과 동일한 비밀번호를 웹 포럼 사이트에 사용한다는 사실을 감안할 때 '저가치' 비밀번호라도 비 비밀번호로 처리하는 것이 가장 좋을 것이라고 생각합니다. - 복구 가능.
Michael Burr
누군가가 대형 건물(예: 바)을 지을 것을 의뢰했으며 다음과 같은 대화가 발생한다고 상상해 보십시오.
건축가:이 크기와 용량의 건물에는 여기, 여기, 여기에서 비상구가 필요합니다. 클라이언트:아니요, 유지 관리하기에는 너무 복잡하고 비용이 많이 듭니다. 저는 옆문이나 뒷문을 원하지 않습니다. 건축가:선생님, 비상구는 선택 사항이 아니라 도시의 소방 규정에 따라 필수입니다. 고객:논쟁하는 데 돈을 지불하지 않습니다. 내가 요청한 대로 하세요.
그러면 건축가는 이 건물을 비상구 없이 윤리적으로 지을 수 있는 방법을 묻습니까?
건축 및 엔지니어링 산업에서 대화는 다음과 같이 끝날 가능성이 가장 높습니다.
건축가:이 건물은 비상구가 없으면 지을 수 없습니다. 다른 면허가 있는 전문가에게 가도 똑같은 말을 할 것입니다. 나는 지금 떠날 것이다. 협조할 준비가 되면 다시 전화해 주십시오.
컴퓨터 프로그래밍은 면허가 있는 직업이 아닐 수 있지만 사람들은 종종 우리 직업이 토목 엔지니어나 기계 엔지니어와 같은 존경을 받지 못하는 이유를 궁금해하는 것 같습니다. 그런 직업은 쓰레기(또는 완전히 위험한) 요구 사항을 전달하면 단순히 거부할 것입니다. 그들은 "나는 최선을 다했지만 그는 주장했고 나는 그가 말한 대로 해야 한다"고 말하는 것이 핑계가 아니라는 것을 알고 있습니다. 그들은 핑계로 면허를 잃을 수 있습니다.
귀하 또는 귀하의 고객이 상장된 회사의 일부인지 여부는 모르겠지만 복구 가능한 형식으로 암호를 저장하면 여러 유형의 보안 감사에 실패하게 됩니다. 문제는 데이터베이스에 액세스한 일부 "해커"가 암호를 복구하는 것이 얼마나 어려운가가 아닙니다. 대부분의 보안 위협은 내부에 있습니다. 당신이 보호해야 할 것은 불만을 품은 직원이 모든 비밀번호를 가지고 걸어가서 최고가 입찰자에게 판매하는 것입니다. 비대칭 암호화를 사용하고 개인 키를 별도의 데이터베이스에 저장하는 것은 이 시나리오를 방지하는 데 전혀 도움이 되지 않습니다. 개인 데이터베이스에 액세스할 수 있는 사람 이 항상 있을 것이며 이는 심각한 보안 위험입니다.
복구 가능한 형식으로 암호를 저장하는 윤리적이거나 책임 있는 방법은 없습니다. 기간.
Aaronaught
공개 키로 비밀번호 + 솔트를 암호화할 수 있습니다. 로그인의 경우 저장된 값이 사용자 입력 + 소금에서 계산된 값과 같은지 확인하기만 하면 됩니다. 암호를 일반 텍스트로 복원해야 하는 경우가 발생하면 개인 키를 사용하여 수동 또는 반자동으로 암호를 해독할 수 있습니다. 개인 키는 다른 곳에 저장될 수 있으며 대칭적으로 추가로 암호화될 수 있습니다(이때 암호를 해독하려면 사람의 상호 작용이 필요함).
암호는 일반 텍스트로 복구할 수 있지만 개인 키가 있어야만 시스템 외부에 저장할 수 있습니다(원하는 경우 은행 금고).
stefanw
포기하지 마세요. 고객을 설득하는 데 사용할 수 있는 무기는 부인할 수 없는 것입니다. 당신이 어떤 메커니즘을 통해 사용자 암호를 재구성 할 수 있다면, 당신은 그들의 고객에게 법적 부인 방지 메커니즘을 제공하고 그들은 방법이 없기 때문에 공급 업체들이 암호를 재구성하지 않았다는 것을 증명할 수, 해당 암호에 따라 트랜잭션을 부인할 수 자신을 통해 거래를 진행합니다. 암호가 암호 텍스트가 아닌 다이제스트 형식으로 올바르게 저장되어 있으면 최종 클라이언트가 직접 트랜잭션을 실행했거나 암호에 대한 주의 의무를 위반했기 때문에 불가능합니다. 두 경우 모두 책임은 그에게 정면으로 남습니다. 나는 그것이 수억 달러에 달하는 경우에 일했습니다. 당신이 잘못하고 싶은 것이 아닙니다.
user207421
나중에 일반 텍스트 검색을 위해 암호를 윤리적으로 저장할 수 없습니다. 그것만큼 간단합니다. Jon Skeet조차도 나중에 일반 텍스트 검색을 위해 비밀번호를 윤리적으로 저장할 수 없습니다. 사용자가 어떻게든 일반 텍스트로 암호를 검색할 수 있다면 잠재적으로 코드에서 보안 취약점을 발견한 해커도 검색할 수 있습니다. 그리고 이는 한 사용자의 비밀번호가 손상되는 것이 아니라 모두가 손상되는 것입니다.
고객에게 문제가 있는 경우 암호를 복구할 수 있도록 저장하는 것은 법에 어긋난다고 말하십시오. 여하튼 여기 영국에서는 1998년 데이터 보호법(특히 별표 1, 파트 II, 단락 9)에 따라 데이터 컨트롤러가 무엇보다도 다음 사항을 고려하여 개인 데이터를 안전하게 유지하기 위해 적절한 기술적 조치를 사용해야 합니다. 데이터가 손상된 경우 발생할 수 있는 피해 - 이는 사이트 간에 암호를 공유하는 사용자에게 상당할 수 있습니다. 그들은 여전히 문제가 있다는 사실을 grokking 문제가있는 경우, 다음과 같은 몇 가지 실제 사례,에 지점 이 하나 .
사용자가 로그인을 복구할 수 있도록 하는 가장 간단한 방법은 자동으로 로그인하고 새 비밀번호를 선택할 수 있는 페이지로 바로 이동하는 일회성 링크를 이메일로 보내는 것입니다. 프로토타입을 만들고 실제로 보여줍니다.
아래 메모에서 나는 주로 노인, 정신 장애자 또는 아주 어린 사람들을 대상으로 하는 웹 사이트가 안전한 암호 복구 루틴을 수행하라는 요청을 받을 때 사람들에게 혼란을 줄 수 있다는 점을 지적했습니다. 이러한 경우에는 간단하고 일상적일 수 있지만 일부 사용자는 서비스 기술자가 시스템에 도움을 주거나 이메일을 보내거나 직접 표시하도록 하는 추가 지원이 필요합니다.
이러한 시스템에서 사용자에게 이러한 수준의 액세스 지원이 제공되지 않으면 이러한 인구 통계의 감소율로 인해 애플리케이션이 중단될 수 있으므로 이러한 설정을 염두에 두고 응답하십시오.
이러한 요구 사항 중 검색 가능한 암호 시스템이 필요한지 궁금합니다. 예를 들어: Mabel 이모가 전화를 걸어 "인터넷 프로그램이 작동하지 않습니다. 비밀번호를 모릅니다."라고 말합니다. "OK"라고 고객 서비스 드론이 말합니다. "몇 가지 세부 사항을 확인한 다음 새 비밀번호를 알려 드리겠습니다 . 다음에 로그인할 때 비밀번호를 유지할지 기억할 수 있는 것으로 변경할지 묻는 메시지가 표시됩니다. 더 쉽게."
그런 다음 시스템은 암호 재설정이 발생한 시점을 알고 "새 암호를 유지하시겠습니까, 아니면 새 암호를 선택하시겠습니까?" 메시지를 표시하도록 설정됩니다.
PC에 익숙하지 않은 사람들에게 이전 암호를 듣는 것보다 이것이 어떻게 더 나쁠까요? 그리고 고객 서비스 담당자가 장난을 칠 수 있지만 데이터베이스 자체는 침해될 경우 훨씬 더 안전합니다.
내 제안에 무엇이 나쁜지 댓글을 달면 처음에 원하는 것을 실제로 수행하는 솔루션을 제안하겠습니다.
Mr. Boy
Michael Brooks는 CWE-257에 대해 목소리를 높였습니다. 어떤 방법을 사용하든지 사용자(관리자)가 여전히 암호를 복구할 수 있다는 사실입니다. 그렇다면 이러한 옵션은 어떻습니까?
다른 사람의 공개 키로 암호를 암호화합니다(일부 외부 권한). 그렇게 하면 개인적으로 재구성할 수 없으며 사용자는 해당 외부 기관으로 이동하여 암호 복구를 요청해야 합니다.
두 번째 암호에서 생성된 키를 사용하여 암호를 암호화합니다. 클라이언트 측에서 이 암호화를 수행하고 절대 서버로 전송하지 마십시오. 그런 다음 복구하려면 입력에서 키를 다시 생성하여 클라이언트 측에서 암호 해독을 다시 수행합니다. 물론 이 접근 방식은 기본적으로 두 번째 암호를 사용하지만 항상 암호를 적어 두거나 이전 보안 질문 접근 방식을 사용하도록 지시할 수 있습니다.
1.이 더 나은 선택이라고 생각합니다. 클라이언트 회사 내에서 개인 키를 보유할 사람을 지정할 수 있기 때문입니다. 그들이 키를 직접 생성하고 지침과 함께 금고 등에 보관하도록 하십시오. 암호의 특정 문자만 암호화하고 내부 제3자에게 제공하여 추측하기 위해 암호를 해독해야 하도록 선택하여 보안을 추가할 수도 있습니다. 그것. 이 캐릭터를 사용자에게 제공하면 아마도 그것이 무엇인지 기억할 것입니다!
Phil H
이 질문에 대한 응답으로 사용자의 보안 문제에 대한 많은 논의가 있었지만 이점에 대한 언급을 추가하고 싶습니다. 지금까지 시스템에 복구 가능한 암호를 저장하는 것에 대해 언급된 합법적인 이점을 한 번도 본 적이 없습니다. 이걸 고려하세요:
사용자가 비밀번호를 이메일로 받으면 이점이 있습니까? 아니요. 1회용 비밀번호 재설정 링크를 통해 더 많은 혜택을 받을 수 있습니다. 이 링크를 통해 기억할 비밀번호를 선택할 수 있기를 바랍니다.
사용자가 화면에 비밀번호를 표시하면 이점이 있습니까? 아니요, 위와 같은 이유로; 새 암호를 선택해야 합니다.
지원 담당자가 사용자에게 암호를 말하도록 하면 사용자에게 이익이 됩니까? 아니요; 다시 말하지만, 지원 담당자가 사용자의 암호 요청이 적절하게 인증된 것으로 간주하면 새 암호와 변경할 수 있는 기회가 제공되는 것이 사용자에게 더 유리합니다. 또한 전화 지원은 자동 비밀번호 재설정보다 비용이 많이 들기 때문에 회사도 혜택을 받지 못합니다.
복구 가능한 암호의 이점을 얻을 수 있는 유일한 사람은 악의적인 의도를 가진 사람 또는 타사 암호 교환이 필요한 열악한 API 지지자뿐입니다(이 API는 절대 사용하지 마세요!). 아마도 회사는 복구 가능한 암호를 저장함으로써 어떠한 이익도 얻지 못하고 책임만 있을 뿐이라고 고객에게 진실하게 말함으로써 논쟁에서 승리할 수 있습니다.
이러한 유형의 요청 행 사이를 읽으면 클라이언트가 암호 관리 방법을 이해하지 못하거나 실제로는 전혀 관심조차 갖지 않는다는 것을 알 수 있습니다. 그들이 정말로 원하는 것은 사용자에게 그렇게 어렵지 않은 인증 시스템입니다. 따라서 실제로 복구 가능한 암호를 원하지 않는 방법을 알려주는 것 외에도 특히 은행과 같은 높은 보안 수준이 필요하지 않은 경우 인증 프로세스를 덜 고통스럽게 만드는 방법을 제공해야 합니다.
사용자가 사용자 이름으로 이메일 주소를 사용하도록 허용합니다. 나는 사용자가 자신의 사용자 이름을 잊어버리는 경우를 수없이 보아왔지만 이메일 주소를 잊어버린 사람은 거의 없습니다.
OpenID를 제공하고 제3자가 사용자 건망증 비용을 지불하게 합니다.
암호 제한을 완화하십시오. 일부 웹 사이트에서 "특수 문자를 사용할 수 없습니다" 또는 "비밀번호가 너무 깁니다" 또는 "비밀번호가 시작해야 합니다 편지로." 또한 사용 편의성이 암호 강도보다 더 큰 관심사인 경우 더 짧은 암호를 허용하거나 혼합 문자 클래스를 요구하지 않음으로써 어리석지 않은 요구 사항도 완화할 수 있습니다. 제한이 느슨해지면 사용자는 잊어버리지 않는 암호를 사용할 가능성이 높아집니다.
암호를 만료하지 마십시오.
사용자가 이전 비밀번호를 재사용할 수 있도록 허용합니다.
사용자가 자신의 비밀번호 재설정 질문을 선택하도록 허용합니다.
그러나 어떤 이유로(그리고 그 이유를 알려주십시오) 정말로, 정말로, 복구 가능한 비밀번호가 필요하다면 비밀번호가 아닌 비밀번호를 제공하여 사용자가 다른 온라인 계정을 잠재적으로 손상시키지 않도록 보호할 수 있습니다. 기반 인증 시스템. 사람들은 이미 사용자 이름/비밀번호 시스템에 익숙하고 잘 활용된 솔루션이기 때문에 이것은 최후의 수단이 될 것이지만 비밀번호에 대한 창의적인 대안은 분명히 많이 있습니다.
사용자가 4자리 숫자가 아닌 숫자 핀을 선택하도록 하고, 무차별 대입 시도가 방지되는 경우에만 선택하는 것이 좋습니다.
사용자가 답을 알고 있고, 절대 변하지 않고, 항상 기억하고, 다른 사람들이 알아도 상관하지 않는 짧은 답변이 포함된 질문을 선택하게 합니다.
사용자가 사용자 이름을 입력한 다음 추측을 방지하기 위해 충분한 순열을 사용하여 기억하기 쉬운 모양을 그리도록 합니다(전화 잠금 해제를 위해 G1이 이 작업을 수행하는 방법에 대한 멋진 사진 참조).
어린이 웹 사이트의 경우 사용자 이름(일종의 ID 아이콘)을 기반으로 퍼지 생물을 자동 생성하고 해당 생물에게 비밀 이름을 지정하도록 요청할 수 있습니다. 그런 다음 로그인을 위해 생물의 비밀 이름을 입력하라는 메시지가 표시될 수 있습니다.
Jacob
질문에 대해 내가 한 의견에 따르면: 거의 모든 사람들이 한 가지 중요한 점을 간과했습니다... 저의 초기 반응은 @Michael Brooks와 매우 유사했습니다. @stefanw처럼 여기의 문제는 요구 사항이 깨진다는 사실을 깨달았을 때까지였습니다. 하지만 이것이 바로 그것들입니다. 그런데 그게 사실이 아닐 수도 있다는 생각이 들었습니다! 여기서 누락된 점은 애플리케이션 자산 의 무언의 가치입니다. 간단히 말해서 가치가 낮은 시스템의 경우 모든 프로세스가 포함된 완전히 안전한 인증 메커니즘은 과도하고 잘못된 보안 선택이 될 것입니다. 분명히 은행의 경우 "모범 사례"가 필수이며 CWE-257을 윤리적으로 위반할 수 있는 방법은 없습니다. 그러나 가치가 없는 낮은 가치 시스템을 생각하기 쉽습니다(단, 간단한 암호는 여전히 필요함).
진정한 보안 전문 지식은 누구나 온라인에서 읽을 수 있는 "모범 사례"를 독단적으로 내세우는 것이 아니라 적절한 절충안을 찾는 것임을 기억하는 것이 중요합니다.
따라서 다른 솔루션을 제안합니다. 시스템의 값에 따라, 시스템은 적절 아니오 "비싼"자산 (신원 자체 포함)와 가치가 낮은 경우에만,그리고 적절한 처리 불가능 (또는 충분히 / 어려운 비용) 할 유효한 비즈니스 요구 사항이 있습니다 , 그리고 클라이언트는 모든 주의 사항을 알게 됩니다... 그런 다음 건너뛸 특별한 후프 없이 간단히 되돌릴 수 있는 암호화를 허용하는 것이 적절할 수 있습니다. 구현하기가 매우 간단하고 저렴하고(패시브 키 관리를 고려하더라도) 어느 정도 보호(구현 비용 이상)를 제공하기 때문에 암호화를 전혀 신경쓰지 말라는 말을 하고 멈춥니다. 또한 이메일을 통해, 화면에 표시 등을 통해 사용자에게 원래 비밀번호를 제공하는 방법을 살펴볼 가치가 있습니다. 여기에서는 도난당한 암호의 값(합계 포함)이 매우 낮다고 가정하기 때문에 이러한 솔루션 중 하나가 유효할 수 있습니다.
다른 게시물과 별도의 댓글 스레드에서 활발한 토론이 진행 중이며 실제로 여러 번의 활발한 토론이 있기 때문에 몇 가지 설명을 추가하고 여기 다른 곳에서 제기된 아주 좋은 점에 대해 답변하겠습니다.
시작하려면 여기 있는 모든 사람에게 사용자의 원래 암호를 검색하도록 허용하는 것이 나쁜 습관이며 일반적으로 좋지 않다는 것이 분명하다고 생각합니다. 논란의 여지가 전혀 없는... 더 나아가, 나는 많은 상황에서, 아니 대부분의 상황에서 그것이 정말 잘못되고 심지어 더럽고 추악하고 추악 하다는 점을 강조할 것입니다.
그러나 문제의 핵심은 원칙 에 있습니다. 이를 금지할 필요가 없는 상황 이 있는지, 그렇다면 상황에 가장 적합한 방법으로 금지해야 합니다.
이제 @Thomas, @sfussenegger 및 기타 몇 사람이 언급했듯이 해당 질문에 답하는 유일한 적절한 방법은 주어진(또는 가상의) 상황에 대한 철저한 위험 분석을 수행하여 위험에 처한 것이 무엇인지, 얼마나 보호할 가치가 있는지 이해하는 것입니다. , 그리고 그러한 보호를 제공하기 위해 어떤 다른 완화 조치가 수행되고 있는지. 아니요, 이것은 유행어가 아닙니다. 이것은 실제 보안 전문가를 위한 기본적이고 가장 중요한 도구 중 하나입니다. 모범 사례는 (보통 경험이 없는 사람과 해킹에 대한 지침으로) 그 시점 이후에는 사려 깊은 위험 분석이 이어집니다.
웃기는 일입니다. 저는 항상 스스로를 보안 광신자 중 한 명으로 여겼고, 어쩐지 저는 소위 "보안 전문가"의 반대편에 서 있습니다... 글쎄요, 사실은 - 제가 광신자이기 때문에 그리고 실제 실생활 보안 전문가 - 저는 가장 중요한 위험 분석 없이 "베스트 프랙티스" 도그마(또는 CWE)를 퍼뜨리는 것을 믿지 않습니다. "자신이 방어하고 있는 실제 문제가 무엇인지 모른 채 도구 벨트에 있는 모든 것을 신속하게 적용하는 보안 광신도를 조심하십시오. 더 많은 보안이 반드시 좋은 보안과 동일하지는 않습니다." 위험 분석과 진정한 보안 광신도는 위험, 잠재적 손실, 가능한 위협, 보완적 완화 등을 기반으로 더 똑똑하고 가치/위험 기반의 절충안을 가리킬 것입니다. 건전한 위험 분석을 권장 사항을 기반으로 하거나 논리적 트레이드오프를 지원하지만 위험 분석을 수행하는 방법조차 이해하지 못한 채 독단과 CWE를 내세우는 것을 선호하는 것은 보안 해킹일 뿐이며 전문 지식은 그들이 인쇄한 화장지 가치가 없습니다.
실제로, 그것이 우리가 공항 보안이라는 우스꽝스러움을 얻는 방법입니다.
그러나 이 상황에서 취해야 할 적절한 절충점에 대해 이야기하기 전에 명백한 위험을 살펴보겠습니다. 상황이 있을지도...) LOW-VALUE 시스템을 가정해 보겠습니다. 그러나 공개 액세스가 될 정도로 사소하지는 않습니다. 시스템 소유자는 우연한 사칭을 방지하기를 원하지만 "높은" 보안은 사용 편의성만큼 중요하지 않습니다. (예, 능숙한 스크립트 키디가 사이트를 해킹할 수 있는 위험을 수용하는 것은 합법적인 절충안입니다... 잠깐, 지금 APT가 유행하지 않습니까...?) 예를 들어, 내가 대규모 가족 모임을 위한 간단한 장소를 마련하여 모두가 올해 캠핑 여행을 어디로 가고 싶은지 브레인스토밍할 수 있도록 한다고 가정해 보겠습니다. 나는 어떤 익명의 해커나 심지어 사촌 프레드가 원타나마나비키리키 호수로 돌아가자고 반복적으로 제안하는 것에 대해 덜 걱정합니다. 나는 Erma 이모가 필요할 때 로그온할 수 없기 때문입니다. 자, 핵 물리학자인 Erma 이모는 암호를 잘 기억하지 못하거나 컴퓨터를 전혀 사용하지 않습니다. 그래서 나는 그녀에게 가능한 모든 마찰을 없애고 싶습니다. 다시 말하지만, 저는 해킹에 대해 걱정하지 않습니다. 단지 잘못된 로그인의 어리석은 실수를 원하지 않습니다. 누가 올지, 그들이 원하는 것이 무엇인지 알고 싶습니다.
어쨌든. 그렇다면 단방향 해시를 사용하는 대신 암호를 대칭적으로 암호화하는 경우 주요 위험은 무엇입니까?
사용자 사칭? 아니요, 나는 이미 그 위험을 받아들였습니다. 흥미롭지 않습니다.
사악한 관리자? 글쎄, 아마도... 하지만 다시, 나는 누군가가 다른 사용자를 사칭할 수 있든 없든 상관하지 않습니다. 내부든 아니든... 어쨌든 악의적인 관리자는 당신의 암호를 알아낼 것입니다. 당신의 관리자가 나빠지면 어쨌든 게임은 끝납니다.
제기된 또 다른 문제는 ID가 실제로 여러 시스템 간에 공유된다는 것입니다. 아! 이것은 매우 흥미로운 위험이며 자세히 살펴봐야 합니다. 공유된 실제 ID가아니라 증거 또는 인증 자격 증명임을 주장하는 것으로 시작하겠습니다. 알겠습니다. 공유 암호를 사용하면 다른 시스템(예: 은행 계좌 또는 Gmail)에 효과적으로 액세스할 수 있으므로 사실상 동일한 ID이므로 의미론적일 뿐입니다... 그렇지 않다는 점을 제외하고는 . 이 시나리오에서 ID는 각 시스템에서 별도로 관리됩니다(OAuth와 같은 타사 ID 시스템이 있을 수 있지만 여전히 이 시스템의 ID와 분리되어 있음 - 나중에 자세히 설명). 따라서 여기에서 위험의 핵심 포인트는 사용자가 기꺼이 자신의 (동일한) 비밀번호를 여러 다른 시스템에 입력한다는 것입니다. 이제 나(관리자) 또는 내 사이트의 다른 해커가 Erma 이모의 비밀번호에 액세스할 수 있습니다. 핵미사일 부지.
흠.
여기에서 눈에 띄는 것이 있습니까?
그래야 한다.
핵 미사일 시스템을 보호하는 것이 내 책임 이 아니라는 사실부터 시작하겠습니다. 나는 단지 프락킨 가족 나들이 장소(내 가족을 위해)를 만들고 있습니다. 그렇다면 누구의 책임인가? 음... 핵미사일 시스템은 어떻습니까? 윽. 둘째, 누군가의 비밀번호(보안 사이트와 안전하지 않은 사이트 간에 동일한 비밀번호를 반복적으로 사용하는 것으로 알려진 사람)의 비밀번호를 도용하고 싶다면 왜 귀하의 사이트를 해킹해야 합니까? 또는 대칭 암호화로 어려움을 겪고 계십니까? Goshdarnitall, 나는 나만의 간단한 웹사이트를 만들 수 있고, 사용자가 원하는 모든 것에 대한 매우 중요한 뉴스를 수신하도록 등록할 수 있습니다... Puffo Presto, 나는 그들의 비밀번호를 "도용"했습니다.
예, 사용자 교육은 항상 우리를 깨물기 위해 돌아옵니다. 그렇죠? 그리고 당신이 그것에 대해 할 수있는 일은 당신이 귀하의 사이트에 자신의 암호를 해시하고, 그렇지 않으면 TSA, 당신은 자신의 암호 NOT ONE WHIT에 보호를 추가 생각할 수있는 모든 일을하더라도 ... 없다, 그들은 유지하는 거라면 그들이 부딪치는 모든 사이트에 그들의 비밀번호를 난잡하게 붙였습니다. 귀찮게 시도하지 마십시오.
다시 말해, 당신은 그들의 비밀번호를 소유하고 있지 않으므로 당신 처럼 행동하지 마십시오.
친애하는 보안 전문가 여러분, 예전에 Wendy에게 "위험이 어디에 있습니까?"
위에서 제기한 몇 가지 문제에 대한 또 다른 몇 가지 사항:
CWE는 법률, 규정 또는 표준이 아닙니다. 이것은 "모범 사례"의 반대와 같은 일반적인 약점 의 모음입니다.
공유 정체성의 문제는 실제 문제이지만 여기에서 반대론자들이 잘못 이해(또는 잘못 표현)하고 있습니다. 가치가 낮은 시스템에서 암호를 해독하는 것이 아니라 ID 자체(!)를 공유하는 문제입니다. 가치가 낮은 시스템과 가치가 높은 시스템 간에 암호를 공유하는 경우 문제가 이미 있습니다!
에 의해, 이전 요점은 실제로 이러한 저가치 시스템과 고가치 은행 시스템 모두에 대해 OAuth 등을 사용하여 반대를 가리킬 것입니다.
나는 그것이 단지 예라는 것을 알고 있지만 (슬프게도) FBI 시스템은 실제로 가장 안전하지 않습니다. 고양이의 블로그 서버와 비슷하지는 않지만 더 안전한 은행을 능가하지도 않습니다.
암호화 키에 대한 분할 지식 또는 이중 제어는 군대에서만 발생하지 않습니다. 사실 PCI-DSS는 이제 기본적으로 모든 상인에게 이를 요구 하므로 더 이상 멀리 있지 않습니다(값이 정당화되는 경우).
이러한 질문이 개발자 직업을 그렇게 나쁘게 보이게 하는 것이라고 불평하는 모든 사람들에게: 보안 직업을 더욱 나쁘게 만드는 것은 그러한 답변입니다. 다시 말하지만, 비즈니스 중심의 위험 분석이 필요합니다. 그렇지 않으면 자신을 쓸모 없게 만듭니다. 게다가 틀렸다.
이것이 바로 일반 개발자를 고용하여 다르게 생각하고 올바른 절충안을 찾는 훈련 없이 그에게 더 많은 보안 책임을 맡기는 것은 좋은 생각이 아닌 이유라고 생각합니다. 불쾌하지 않습니다. 여기 계신 여러분께 저는 찬성합니다. 하지만 더 많은 훈련이 필요합니다.
아휴. 글이 얼마나 긴지... 그러나 원래 질문에 대답하기 위해 @Shane:
고객에게 작업을 수행하는 올바른 방법을 설명합니다.
그가 여전히 주장한다면, 더 설명하고 주장하고 주장하십시오. 필요한 경우 짜증을 내십시오.
그에게 사업 위험을 설명하십시오. 세부 사항이 좋고 수치가 더 좋으며 라이브 데모가 일반적으로 가장 좋습니다.
그가 여전히 주장하고 타당한 사업상의 이유를 제시한다면 - 당신이 판단을 내려야 할 때입니다: 이 사이트는 가치가 낮습니까? 정말 유효한 비즈니스 사례입니까? 당신에게 충분합니까? 타당한 비즈니스 이유보다 더 중요하다고 생각할 수 있는 다른 위험은 없습니까? (물론 클라이언트는 악의적인 사이트가 아니지만 그건 아닙니다.) 그렇다면 바로 진행하십시오. 필요한 프로세스를 제자리에 배치하기 위해 노력, 마찰 및 손실된 사용(이 가상 상황에서)의 가치가 없습니다. 다른 모든 결정(이 상황에서 다시 말함)은 좋지 않은 절충안입니다.
따라서 결론 및 실제 답변 - 간단한 대칭 알고리즘으로 암호화하고 강력한 ACL 및 바람직하게는 DPAPI 등으로 암호화 키를 보호하고 문서화하고 클라이언트(해당 결정을 내릴 수 있을 만큼 상급자)가 승인하도록 합니다. 그것.
AviD
반숙집은 어떻습니까?
강력한 암호화로 비밀번호를 저장하고 재설정을 활성화하지 마십시오.
암호를 재설정하는 대신 일회용 암호(첫 로그온이 발생하는 즉시 변경해야 함) 전송을 허용합니다. 그런 다음 사용자가 원하는 암호(선택하는 경우 이전 암호)로 변경하도록 합니다.
비밀번호 재설정을 위한 보안 메커니즘으로 이것을 "판매"할 수 있습니다.
Oded
사용자가 원래 암호를 검색할 수 있도록 하는 유일한 방법 은 사용자 자신의 공개 키로 암호를 암호화하는 것입니다. 그러면 해당 사용자만 암호를 해독할 수 있습니다.
따라서 단계는 다음과 같습니다.
사용자는 아직 암호를 설정하지 않고 사이트에 등록합니다(물론 SSL을 통해). 자동으로 로그인하거나 임시 비밀번호를 제공하십시오.
향후 암호 검색을 위해 공개 PGP 키를 저장하도록 제안합니다.
공개 PGP 키를 업로드합니다.
새 암호를 설정하도록 요청합니다.
그들은 암호를 제출합니다.
사용 가능한 최상의 암호 해시 알고리즘(예: bcrypt)을 사용하여 암호를 해시합니다. 다음 로그인을 확인할 때 사용합니다.
공개 키로 암호를 암호화하고 별도로 저장합니다.
그런 다음 사용자가 암호를 요청하면 암호화된(해싱되지 않은) 암호로 응답합니다. 사용자가 나중에 비밀번호를 검색할 수 있기를 원하지 않는 경우(서비스 생성 비밀번호로만 재설정할 수 있음) 3단계와 7단계를 건너뛸 수 있습니다.
Nicholas Shanks
나는 당신이 스스로에게 물어야 할 진짜 질문이 '어떻게 하면 사람들을 더 잘 설득할 수 있을까?'라고 생각합니다.
z-boss
같은 문제가 있습니다. 그리고 동시에 누군가가 내 시스템을 해킹하는 것은 "만약"이 아니라 "언제"의 문제라고 항상 생각합니다.
따라서 신용 카드나 비밀번호와 같이 복구 가능한 기밀 정보를 저장해야 하는 웹사이트를 만들어야 할 때 내가 하는 일은 다음과 같습니다.
다음으로 암호화: openssl_encrypt (문자열 $data, 문자열 $method, 문자열 $password)
"password" 인수에 사용된 정보를 데이터베이스(또는 시스템의 모든 위치)에 절대 저장하지 마십시오.
이 데이터를 검색해야 하는 경우 "openssl_decrypt()" 함수를 사용하고 사용자에게 답변을 요청하세요. 예: "비밀번호를 받으려면 다음 질문에 답하세요. 휴대전화 번호는 무엇입니까?"
PS 1 : 데이터베이스에 저장된 데이터를 비밀번호로 사용하지 마십시오. 사용자 휴대폰 번호를 저장해야 하는 경우 이 정보를 사용하여 데이터를 인코딩하지 마십시오. 항상 사용자만 알고 있거나 친척이 아닌 사람이 알기 어려운 정보를 사용하십시오.
PS 2 : "원 클릭 구매"와 같은 신용 카드 정보의 경우 로그인 비밀번호를 사용합니다. 이 암호는 데이터베이스(sha1, md5 등)에서 해시되지만 로그인 시 세션 또는 비영구적(즉, 메모리) 보안 쿠키에 일반 텍스트 암호를 저장합니다. 이 일반 암호는 데이터베이스에 머물지 않으며 실제로 항상 메모리에 남아 있으며 섹션 끝에서 파괴됩니다. 사용자가 "원 클릭 구매" 버튼을 클릭하면 시스템이 이 비밀번호를 사용합니다. 사용자가 facebook, twitter 등과 같은 서비스로 로그인한 경우 구매 시 비밀번호를 다시 묻거나(확인, 완전히 "클릭"되지 않음) 사용자가 로그인하는 데 사용한 서비스의 일부 데이터를 사용합니다. (페이스북 아이디처럼).
Daniel Loureiro
자격 증명 보안은 이진 작업이 아닙니다(보안/비보안). 보안은 위험 평가에 관한 것이며 연속체에서 측정됩니다. 보안 광신도들은 이런 식으로 생각하는 것을 싫어하지만, 추악한 진실은 완벽하게 안전한 것은 없다는 것입니다. 암호 요구 사항이 엄격한 해시 암호, DNA 샘플 및 망막 스캔은 더 안전하지만 개발 및 사용자 경험 비용이 듭니다. 일반 텍스트 암호는 훨씬 덜 안전하지만 구현 비용이 저렴합니다(그러나 피해야 함). 결국 침해에 대한 비용/편익 분석으로 귀결됩니다. 보안 대상 데이터의 가치와 시간 가치를 기반으로 보안을 구현합니다.
누군가의 비밀번호가 야생으로 유출되는 데 드는 비용은 얼마입니까? 주어진 시스템에서 가장 비용은 얼마입니까? FBI 컴퓨터의 경우 비용이 엄청날 수 있습니다. Bob의 1회성 5페이지 웹사이트의 경우 비용은 무시할 수 있습니다. 전문가는 고객에게 옵션을 제공하고 보안과 관련하여 모든 구현의 장점과 위험을 제시합니다. 고객이 업계 표준을 따르지 않아 위험에 처할 수 있는 것을 요청하는 경우에는 두 배로 그렇습니다. 클라이언트가 특별히 양방향 암호화를 요청하는 경우 이의 제기를 문서화할 수 있지만 이것이 귀하가 알고 있는 최선의 방법으로 구현하는 데 방해가 되지는 않습니다. 결국 고객의 돈입니다. 예, 단방향 해시 사용을 추진해야 하지만 그것이 절대적으로 유일한 선택이고 다른 것이 비윤리적이라고 말하는 것은 완전히 넌센스입니다.
양방향 암호화로 비밀번호를 저장하는 경우 보안은 모두 키 관리에 달려 있습니다. Windows는 인증서 개인 키에 대한 액세스를 관리 계정 및 암호로 제한하는 메커니즘을 제공합니다. 다른 플랫폼에서 호스팅하는 경우 해당 플랫폼에서 사용할 수 있는 옵션이 무엇인지 확인해야 합니다. 다른 사람들이 제안한 것처럼 비대칭 암호화를 사용할 수 있습니다.
암호는 단방향 해시를 사용하여 저장해야 한다고 구체적으로 명시한 법률(영국의 데이터 보호법도 아님)이 없습니다. 이러한 법률의 유일한 요구 사항은 보안을 위해 합당한 조치를 취해야 한다는 것입니다. 데이터베이스에 대한 액세스가 제한되면 일반 텍스트 암호도 이러한 제한에 따라 법적 자격을 얻을 수 있습니다.
그러나 이것은 법적 우선 순위라는 또 다른 측면을 밝혀줍니다. 법적 우선 순위에서 시스템이 구축되는 산업에서 단방향 해시를 사용해야 한다고 제안하는 경우 완전히 다릅니다. 그것이 고객을 설득하는 데 사용하는 탄약입니다. 이를 제외하고, 합리적인 위험 평가를 제공하고, 이의를 문서화하고, 고객의 요구 사항을 제공할 수 있는 가장 안전한 방법으로 시스템을 구현하기 위한 최선의 제안입니다.
Community Wiki
사용자의 보안 질문에 대한 답변을 암호화 키의 일부로 만들고 보안 질문 답변을 일반 텍스트로 저장하지 마십시오(대신 해시).
Rob Fonseca-Ensor
저는 생계를 위해 다중 요소 인증 시스템을 구현하므로 재설정/재생 워크플로를 위해 사용자를 인증하기 위해 일시적으로 하나의 요소를 덜 사용하면서 비밀번호를 재설정하거나 재구성할 수 있다고 생각하는 것이 당연합니다. 특히 OTP(일회성 암호)를 몇 가지 추가 요소로 사용하면 제안된 워크플로에 대한 시간 창이 짧은 경우 많은 위험을 완화할 수 있습니다. 우리는 (대부분의 사용자가 이미 하루 종일 가지고 다니는) 스마트폰용 소프트웨어 OTP 생성기를 성공적으로 구현했습니다. 상용 플러그에 대한 불만이 나타나기 전에 사용자를 인증하는 데 사용되는 유일한 요소가 아닌 경우 암호를 쉽게 검색하거나 재설정할 수 있도록 유지하는 데 따르는 위험을 낮출 수 있습니다. 사이트 간 암호 재사용 시나리오의 경우 사용자가 다른 사이트도 열려고 하기 때문에 원래 암호를 요구할 것이기 때문에 상황이 여전히 좋지 않다는 점을 인정합니다. 그러나 재구성된 암호를 가장 안전한 방법(html에서 htpps 및 신중한 모양).
Monoman
죄송합니다. 비밀번호를 해독할 수 있는 방법이 있는 한 보안이 유지될 방법은 없습니다. 격렬하게 싸우고, 지면 CYA.
Steven Sudit
이 흥미롭고 열띤 토론을 접했습니다. 그러나 가장 놀랐던 것은 다음과 같은 기본적인 질문에 얼마나 주의를 기울이지 않았다는 것입니다.
Q1. 사용자가 일반 텍스트로 저장된 암호에 액세스해야 한다고 주장하는 실제 이유는 무엇입니까? 왜 그렇게 가치가 있습니까?
사용자가 나이가 많거나 어리다는 정보는 실제로 그 질문에 답하지 않습니다. 그러나 고객의 관심사를 제대로 이해하지 않고 어떻게 비즈니스 결정을 내릴 수 있습니까?
이제 중요한 이유는 무엇입니까? 고객 요청의 진짜 원인이 사용하기 힘든 시스템이라면 정확한 원인을 해결하면 실제 문제가 해결될 수 있지 않을까요?
이 정보가 없고 해당 고객에게 말할 수 없기 때문에 추측할 수 있습니다. 사용성에 관한 것입니다. 위 참조.
내가 본 또 다른 질문은 다음과 같습니다.
Q2. 사용자가 처음에 비밀번호를 기억하지 못한다면 이전 비밀번호가 왜 중요합니까?
그리고 여기에 가능한 대답이 있습니다. "miaumiau"라는 고양이가 있고 그녀의 이름을 비밀번호로 사용했지만 잊어버린 경우, 그것이 무엇인지 상기시키거나 "#zy*RW(ew")와 같은 메시지를 받는 것을 선호합니까?
또 다른 가능한 이유는 사용자가 새 비밀번호를 찾는 것이 어렵다고 생각하기 때문입니다! 따라서 이전 암호를 다시 보내면 그 고통스러운 작업에서 그녀를 다시 구하는 환상을 갖게 됩니다.
나는 단지 그 이유를 이해하려고 노력할 뿐입니다. 그러나 이유가 무엇이든 해결해야 할 것은 원인이 아니라 원인입니다.
사용자로서 나는 단순한 것을 원합니다! 열심히 일하고 싶지 않아!
신문을 보기 위해 뉴스 사이트에 로그인하면 비밀번호로 1111을 입력하고 끝내고 싶다!!!
안전하지 않다는 것을 알고 있지만 누군가가 내 "계정"에 액세스하는 것에 대해 무슨 상관이 있습니까? 예, 그는 뉴스도 읽을 수 있습니다!
사이트에 내 "비공개" 정보가 저장됩니까? 오늘 읽은 뉴스는? 그렇다면 그것은 내 문제가 아니라 사이트의 문제입니다! 사이트는 인증된 사용자에게 개인 정보를 표시합니까? 그럼 애초에 보여주지마!
이것은 단지 문제에 대한 사용자의 태도를 보여주기 위한 것입니다.
요약하자면, 일반 텍스트 암호를 "안전하게" 저장하는 방법(불가능하다고 알고 있음)이 아니라 고객의 실제 문제를 해결하는 방법의 문제라고 생각합니다.
Dmitri Zaitsev
분실/잊은 암호 처리:
누구도 비밀번호를 복구할 수 없어야 합니다.
사용자가 비밀번호를 잊어버린 경우 최소한 사용자 이름이나 이메일 주소를 알고 있어야 합니다. 요청 시 사용자 테이블에서 GUID를 생성하고 GUID를 매개변수로 포함하는 링크가 포함된 이메일을 사용자의 이메일 주소로 보냅니다.
링크 뒤에 있는 페이지는 매개변수 guid가 실제로 존재하는지 확인하고(일부 시간 초과 논리가 있을 수 있음) 사용자에게 새 암호를 묻습니다.
핫라인 도움말 사용자가 필요한 경우 권한 부여 모델에 일부 역할을 추가하고 핫라인 역할이 식별된 사용자로 일시적으로 로그인하도록 허용하십시오. 이러한 모든 핫라인 로그인을 기록하십시오. 예를 들어, Bugzilla는 관리자에게 이러한 가장 기능을 제공합니다.
devio
암호화되어 분실되기 전에 등록 시 일반 텍스트 비밀번호를 이메일로 보내는 것은 어떻습니까? 나는 많은 웹사이트가 그것을 하는 것을 보았고, 사용자의 이메일에서 그 비밀번호를 얻는 것이 당신의 서버/컴에 남겨두는 것보다 더 안전합니다.
casraf
복구 가능한 암호를 저장해야 한다는 요구 사항을 거부할 수 없다면 이에 대한 반론은 어떻습니까?
비밀번호를 적절하게 해시하고 사용자를 위한 재설정 메커니즘을 구축하거나 시스템에서 모든 개인 식별 정보를 제거할 수 있습니다. 이메일 주소를 사용하여 사용자 기본 설정을 지정할 수 있지만 그게 전부입니다. 쿠키를 사용하여 향후 방문에 대한 기본 설정을 자동으로 가져오고 합리적인 기간 후에 데이터를 버립니다.
비밀번호 정책에서 종종 간과되는 한 가지 옵션은 비밀번호가 실제로 필요한지 여부입니다. 암호 정책이 고객 서비스 호출을 유발하는 유일한 경우 제거할 수 있습니다.
anopres
사용자는 정말 그들이 잊은 암호가 있었다, 또는 단순히 시스템에 얻을 수 있어야 할 것 (예를 들어,이 말 수)를 복구해야합니까? 그들이 정말로 원하는 것이 로그온을 위한 암호라면 지원 담당자가 암호를 분실한 사람에게 줄 수 있는 새 암호로 이전 암호(무엇이든 간에)를 단순히 변경하는 루틴을 사용하지 않는 이유는 무엇입니까?
나는 정확히 이것을 수행하는 시스템으로 작업했습니다. 지원 담당자는 현재 암호가 무엇인지 알 수 없지만 새 값으로 재설정할 수 있습니다. 물론 이러한 모든 재설정은 어딘가에 기록되어야 하며 비밀번호가 재설정되었음을 알리는 이메일을 사용자에게 생성하는 것이 좋습니다.
또 다른 가능성은 계정에 대한 액세스를 허용하는 두 개의 동시 암호를 갖는 것입니다. 하나는 사용자가 관리하는 "일반" 암호이고 다른 하나는 지원 담당자만 알고 모든 사용자에게 동일한 골격/마스터 키와 같습니다. 그렇게 하면 사용자에게 문제가 있을 때 지원 담당자가 마스터 키로 계정에 로그인하고 사용자가 자신의 암호를 무엇이든 변경할 수 있도록 도울 수 있습니다. 말할 필요도 없이, 마스터 키로 모든 로그인은 시스템에서도 기록되어야 합니다. 추가 조치로 마스터 키를 사용할 때마다 지원 담당자 자격 증명도 확인할 수 있습니다.
-EDIT- 마스터 키가 없다는 의견에 대한 답변으로: 사용자가 아닌 다른 사람이 사용자 계정에 액세스할 수 있도록 허용하는 것이 나쁘다고 생각하는 것처럼 나쁘다는 데 동의합니다. 질문을 보면 고객이 고도로 손상된 보안 환경을 요구했다는 전제가 전제되어 있습니다.
마스터 키는 처음에 보이는 것처럼 나쁘지 않아도 됩니다. 나는 메인프레임 컴퓨터 운영자가 특정 경우에 "특별한 액세스" 권한을 가질 필요가 있다고 인식한 방위 공장에서 일했습니다. 그들은 단순히 특수 암호를 봉인된 봉투에 넣고 교환원의 책상에 테이프로 붙였습니다. 교환원은 몰랐던 암호를 사용하려면 봉투를 열어야 했습니다. 교대 근무가 바뀔 때마다 교대 감독관의 작업 중 하나는 봉투가 열렸는지 확인하고, 그렇다면 즉시 암호를 변경하고(다른 부서에서) 새 암호를 새 봉투에 넣고 프로세스가 모두 시작되었는지 확인하는 것이었습니다. 다시. 교환원은 왜 그것을 열었는지에 대해 질문을 받았고 그 사건은 기록을 위해 문서화될 것입니다.
이것은 내가 설계한 절차는 아니지만 효과가 있었고 훌륭한 책임을 제공했습니다. 모든 것이 기록되고 검토되었으며 모든 대원은 DOD 기밀 허가를 받았으며 남용은 없었습니다.
검토와 감독으로 인해 모든 운영자는 봉투를 여는 특권을 남용하면 즉시 해고되고 형사 기소될 수 있다는 사실을 알고 있었습니다.
따라서 진정한 답은 올바른 일을 하고 싶다면 신뢰할 수 있는 사람을 고용하고 배경 조사를 하고 적절한 관리 감독과 책임을 행사하는 것입니다.
그러나 이 불쌍한 친구의 클라이언트가 관리를 잘했다면 애초에 보안이 취약한 솔루션을 요구하지 않았을 것입니다. 지금은 그렇게 하시겠습니까?
JonnyBoats
이 주제에 대해 내가 이해하는 바에 따르면 로그인/비밀번호가 있는 웹사이트를 구축하는 경우 서버에 일반 텍스트 비밀번호조차 표시되지 않아야 한다고 생각합니다. 암호는 클라이언트를 떠나기 전에 해시되어야 하며 아마도 소금에 절여야 합니다.
일반 텍스트 암호가 표시되지 않으면 검색 문제가 발생하지 않습니다.
또한 (웹에서) MD5와 같은 일부 알고리즘이 더 이상 안전한 것으로 간주되지 않는다는 사실을 수집했습니다. 스스로 판단할 수는 없지만 생각해 볼 일이다.
Jeremy C
독립 실행형 서버에서 DB를 열고 이 기능이 필요한 각 웹 서버에 암호화된 원격 연결을 제공합니다. 관계형 DB일 필요는 없으며 테이블과 행 대신 폴더와 파일을 사용하여 FTP 액세스가 가능한 파일 시스템일 수 있습니다. 가능하면 웹 서버에 쓰기 전용 권한을 부여하십시오.
일반 사람들처럼 검색할 수 없는 암호 암호화를 사이트의 DB에 저장합니다("pass-a"라고 함). :) 각각의 새로운 사용자(또는 비밀번호 변경)에서 원격 DB에 비밀번호의 일반 사본을 저장하십시오. 서버의 ID, 사용자의 ID 및 "pass-a"를 이 암호의 복합 키로 사용하십시오. 암호에 양방향 암호화를 사용하여 밤에 잠을 더 잘 수 있습니다.
이제 누군가가 비밀번호와 컨텍스트(사이트 ID + 사용자 ID + "pass-a")를 모두 얻으려면 다음을 수행해야 합니다.
("pass-a", user id ) 쌍 또는 쌍을 얻기 위해 웹사이트의 DB를 해킹하십시오.
일부 구성 파일에서 웹 사이트의 ID를 가져옵니다.
원격 암호 DB를 찾아 해킹하십시오.
비밀번호 검색 서비스의 접근성을 제어할 수 있으며(보안 웹 서비스로만 노출, 하루에 일정량의 비밀번호 검색만 허용, 수동으로 수행 등) 이 "특별 보안 조치"에 대해 추가 비용을 청구할 수도 있습니다. 암호 검색 DB 서버는 많은 기능을 제공하지 않고 보안이 더 잘 될 수 있기 때문에 꽤 숨겨져 있습니다(권한, 프로세스 및 서비스를 엄격하게 조정할 수 있음).
대체로 해커의 작업을 더 어렵게 만듭니다. 단일 서버에서 보안 침해가 발생할 가능성은 여전히 동일하지만 의미 있는 데이터(계정 및 비밀번호 일치)를 수집하기 어려울 것입니다.
Amir Arad
고려하지 않았을 수 있는 또 다른 옵션은 이메일을 통한 작업을 허용하는 것입니다. 다소 번거롭지만 시스템의 특정 부분을 보기(읽기 전용)하기 위해 시스템 "외부" 사용자가 필요한 클라이언트를 위해 구현했습니다. 예를 들어:
사용자가 등록되면 일반 웹사이트와 같이 전체 액세스 권한을 갖습니다. 등록에는 이메일이 포함되어야 합니다.
데이터 또는 작업이 필요하고 사용자가 비밀번호를 기억하지 못하는 경우 일반 " 제출 " 버튼 바로 옆에 있는 특별한 " 허가를 위해 나에게 이메일 보내기" 버튼을 클릭하여 작업을 수행할 수 있습니다.
그런 다음 작업을 수행할 것인지 묻는 하이퍼링크와 함께 요청이 이메일로 전송됩니다. 이는 비밀번호 재설정 이메일 링크와 유사하지만 비밀번호를 재설정하는 대신 일회성 작업을 수행합니다.
그런 다음 사용자는 "예"를 클릭하고 데이터를 표시해야 하는지 또는 작업을 수행해야 하는지, 데이터를 공개해야 하는지 등을 확인합니다.
의견에서 언급했듯이 이메일이 손상된 경우 작동하지 않지만 암호를 재설정하고 싶지 않다는 @joachim의 의견을 처리합니다. 결국 암호 재설정을 사용해야 하지만 더 편리한 시간에 또는 필요에 따라 관리자나 친구의 도움을 받아 재설정할 수 있습니다.
이 솔루션을 변형하면 신뢰할 수 있는 타사 관리자에게 작업 요청을 보낼 수 있습니다. 이것은 노인, 정신적 장애가 있거나 아주 어리거나 혼란스러운 사용자의 경우에 가장 잘 작동합니다. 물론 이러한 사람들이 자신의 작업을 지원하려면 신뢰할 수 있는 관리자가 필요합니다.
Sablefoste
평소와 같이 사용자의 비밀번호를 솔트 앤 해시합니다. 사용자 로그인 시 사용자의 비밀번호(솔팅/해싱 후)를 모두 허용하고 사용자가 문자 그대로 입력한 내용도 일치하도록 허용합니다.
이를 통해 사용자는 비밀 암호를 입력할 수 있지만 다른 사람이 데이터베이스에서 읽을 암호의 솔트/해싱 버전을 입력할 수도 있습니다.