비밀번호 재사용을“보호”하기 위해 제출하기 전에 클라이언트에서 웹 페이지에서 비밀번호를 해시하고 서버에서 다시 해시하는 웹 페이지가 거의없는 이유는 무엇입니까?

인터넷에는 로그인 정보가 필요한 사이트가 많이 있으며 암호 재사용을 방지하는 유일한 방법은 서버에서 암호가 해시되는 "약속"입니다. 항상 그런 것은 아닙니다.

그래서 클라이언트 컴퓨터에서 암호를 해시하는 웹 페이지 (Javascript로)를 다시 해시 할 서버로 보내기 전에 얼마나 어려운지 궁금합니다. 이론적으로 이것은 추가 보안을 제공하지는 않지만 실제로는 서버에서 비밀번호를 해시하지 않는 "불량 사이트"로부터 보호하는 데 사용될 수 있습니다.

왜 사용되지 않습니까? 제로 게인에 대한 추가 작업이 많기 때문입니다. 이러한 시스템은 더 안전하지 않습니다. 심지어 수 있습니다 덜 이, 더 안전한 것 (암호 재사용, 사전 암호 등 같은) 덜 안전한 방법을 채택하는 사용자를 선도의 잘못된 인상을주기 때문에 보안.

이론적으로 이것은 추가 보안을 제공하지는 않지만 실제로는 서버에서 비밀번호를 해시하지 않는 "불량 사이트"로부터 보호하는 데 사용될 수 있습니다.

이것이 정확히 당신을 어떻게 보호합니까? 당신이하고 싶은 것은 무의미한 해시 암호를 해시하는 것입니다. 해시 된 비밀번호가 비밀번호가되기 때문입니다.

인터넷에는 로그인 정보가 필요한 사이트가 많이 있으며 암호 재사용을 방지하는 유일한 방법은 서버에서 암호가 해시되는 "약속"입니다. 항상 그런 것은 아닙니다.

하나 이상의 사이트에 동일한 비밀번호를 사용하지 않는 것은 어떻습니까. 이론적으로 웹 사이트에서 비밀번호를 해시하는 이유는 계정이 노출 된 경우 귀하의 계정에 대한 액세스를 차단하기 위해서입니다. 여러 웹 사이트에 동일한 암호를 사용하는 것은 어리석은 일입니다.

자바 스크립트를 사용했다면, "해커"가 해쉬 된 해시 암호에서 같은 방법을 사용하면됩니다. 일단 해시 된 정보를 확보 한 후에는 계정 액세스를 방해하는 요소 인 데이터베이스에서 비밀번호-> 동일한 해시를 계산하는 데 걸리는 시간입니다.

가치가 거의 없거나 전혀 없기 때문에. 해싱의 이유는 데이터베이스가 해킹되면 해커가 유효한 암호 목록이없고 해시 만 있기 때문입니다. 따라서 사용자를 가장 할 수 없습니다. 시스템에 비밀번호를 모르고 있습니다.

보안은 SSL 인증서와 일부 인증 형식에서 제공됩니다. 사용자가 암호를 제공하여 해시를 계산할 수 있기를 원합니다.

또한 해싱 알고리즘은 서버의보다 안전한 영역에 있습니다. 숨겨진 참조 스크립트 파일 인 경우에도 클라이언트에 배치하면 Javascript의 소스 코드를 쉽게 얻을 수 있습니다.

해결책은 그것보다 간단합니다. 클라이언트 인증서. 내 컴퓨터에서 클라이언트 인증서를 만듭니다. 웹 사이트에 등록 할 때 클라이언트 인증서와 서버 인증서를 사용하여 악수를합니다.

암호는 교환되지 않으며 누군가 데이터베이스를 해킹하더라도 내 클라이언트 인증서의 공개 키 (추가 보안 수준을 위해 서버에서 솔트하고 암호화해야 함)입니다.

클라이언트 인증서는 스마트 카드에 저장하고 마스터 암호를 사용하여 안전한 온라인 볼트에 업로드 할 수 있습니다.

이 모든 것의 장점은 피싱 개념을 제거한다는 것입니다. 웹 사이트에 암호를 입력하지 않고 해당 웹 사이트와 핸드 셰이 킹하는 것입니다. 그들이 얻는 것은 개인 키없이 쓸모없는 공개 키입니다. 유일한 취약성은 핸드 셰이크 중에 충돌을 발견하는 것이며 단일 웹 사이트에서 한 번만 작동합니다.

Microsoft는 Windows에서 Cardspace와 함께 이와 유사한 것을 제공하려고 시도했으며 나중에 공개 표준으로 제출했습니다. OAuth는 다소 유사하지만 중간 "발행자"에 의존합니다. 반면에 정보 카드는 자체 발급 될 수 있습니다. 그것은 암호 문제에 대한 진정한 해결책입니다 ... 암호를 모두 제거하십시오.

OAuth는 올바른 방향으로 나아가는 단계입니다.

대부분의 답글은 클라이언트 쪽 비밀번호 해싱의 요점을 완전히 놓친 것 같습니다.

포인트입니다 하지 해시를 차단하는 것은 일반 텍스트 암호를 차단보다 더 안전하지 않기 때문에, 당신은에 로그인되어있는 서버에 안전하게 액세스 할 수 있습니다.

요점은 실제로 사용자 암호 를 보호 하는 것입니다. 대부분의 사용자는 여러 사이트에서 암호를 재사용하기 때문에 일반적으로 개별 사이트 로그인 액세스보다 훨씬 가치가 있습니다 (그렇지 않아야하지만 실제로는 그렇게하지 않아야합니다. ).

ssl은 mitm 공격으로부터 보호하는 데 유용하지만 서버에서 로그인 응용 프로그램이 손상되면 ssl은 사용자를 보호하지 않습니다. 누군가가 웹 서버에 악의적으로 액세스 한 경우 대부분의 경우 암호는 서버의 스크립트에 의해 해시되기 때문에 암호를 일반 텍스트로 가로 챌 수 있습니다. 그런 다음 공격자는 비슷한 사용자 이름을 사용하여 다른 (보통 더 가치있는) 사이트에서 해당 암호를 시도 할 수 있습니다.

보안은 철저한 방어이며 클라이언트 측 해싱은 단순히 다른 계층을 추가합니다. 자신의 사이트에 대한 액세스를 보호하는 것이 중요하지만 다른 사이트에서 암호를 다시 사용하기 때문에 사용자의 암호를 보호하는 것이 훨씬 중요합니다.

확실히 가능하며 실제로 웹 사이트를 기다릴 필요가 없습니다.

SuperGenPass를 살펴보십시오 . 북마크입니다.

단순히 비밀번호 필드를 인식하고, 웹 사이트 도메인에 입력 한 내용을 연결하고, 해시하고, 비밀번호에 "허가 된"문자 만 가져 오도록 약간 엉킨 다음 해시 된 비밀번호 만 유선으로 전송됩니다.

프로세스에서 사이트 도메인을 사용하면 항상 동일한 비밀번호를 재사용하더라도 사이트 당 고유 한 비밀번호를 얻을 수 있습니다.

매우 안전하지는 않지만 (base64-MD5) 원하는 경우 sha-2 기반 구현을 완벽하게 배포합니다.

도메인이 변경되면 유일한 단점은 암호를 직접 복구 할 수 없기 때문에 웹 사이트에 암호를 재설정하도록 요청해야한다는 것입니다 ...하지만 자주 발생하지는 않습니다. 허용 가능한 균형.

나는 X4u의 답변을 좋아하지만, 내 의견으로는 브라우저 / HTML 사양에 통합되어야한다고 생각합니다. 현재 답변의 절반에 불과합니다.

여기에 사용자로서의 문제점이 있습니다. 데이터베이스에 저장할 때 다른 쪽 끝에서 비밀번호가 해시되는지 여부는 알 수 없습니다. 나와 서버 사이의 줄은 잘 암호화되어 있지만 목적지에 도달하면 비밀번호가 어떻게되는지 전혀 알 수 없습니다. 아마 일반 텍스트로 저장 될 수도 있습니다. 데이터베이스 관리자는 데이터베이스 판매를 끝낼 수 있으며,이를 알기 전에 전 세계가 사용자의 비밀번호를 알고 있습니다.

대부분의 사용자는 비밀번호를 재사용합니다. 기술을 잘 모르는 사람은 더 잘 모르기 때문입니다. 기술적 인 사람들은 일단 15 번째 암호에 도달하면 대부분의 사람들은 암호를 적어 두지 않으면 기억할 가능성이 없기 때문입니다 (우리 모두도 나쁜 생각입니다).

Chrome 또는 IE 또는 내가 사용하는 것이 암호 상자가 서버에서 생성 된 소금을 사용하여 클라이언트 측에서 즉시 해시되고 암호 자체를 효과적으로 샌드 박스로 만들 것이라고 말할 수 있다면 사용자로서 재사용 할 수 있음을 알 것입니다 위험이 적은 암호. 나는 여전히 암호화 된 채널을 원할뿐만 아니라 전송 중에 처마가 떨어지는 것을 원하지 않습니다.

사용자는 자신의 비밀번호를 서버로 전송할 수 없으며 해시 만 사용할 수 있음을 알아야합니다. 현재 X4U 솔루션을 사용하는 경우에도 해당 기술이 사용 중인지 알 수 없기 때문에 이것이 사실인지 알 방법이 없습니다.

프레임 워크, CMS, 포럼 소프트웨어 등과 같이 설치 될 서버를 제어하지 않는 것을 구축 할 때 사용하는 것이 좋은 방법이라고 생각합니다. 즉, 로그인 및 로그인 된 활동에 항상 SSL을 사용하는 것이 좋습니다. 그러나 framework / cms를 사용하는 일부 사이트에는 SSL이 없으므로 여전히 혜택을 누릴 수 있습니다.

다른 사람들이 지적했듯이, 여기서 이점은 MITM 공격으로 다른 사람 이이 특정 사이트에 로그인 할 수 없다는 것이 아니라 공격자가 동일한 사용자 이름 / 암호 콤보를 사용할 수 없다는 것입니다 계정이있는 수십 개의 다른 사이트에 로그인하십시오.

이러한 체계는 임의의 소금 또는 사이트 별 및 사용자 이름 별 소금의 콤보로 소금을 사용해야 암호를 얻는 사람이 다른 사이트에서 동일한 사용자 이름으로 사용할 수 없습니다 (동일한 해싱 구성표를 사용하는 사이트조차도) ) 또는 같은 비밀번호를 가진 사이트 사이트의 다른 사용자를 상대로하지 않아야합니다.

다른 사람들은 사용자가 사용하는 모든 단일 사이트에 대해 고유 한 암호를 만들거나 암호 관리자를 사용해야한다고 제안했습니다. 이것은 이론 상으로는 건전한 조언이지만, 우리는 이것이 현실 세계에 의존하는 것이 어리 석다는 것을 알고 있습니다. 이 중 하나를 수행하는 사용자의 비율은 적으며 곧 변경 될 것으로 의심됩니다.

따라서 자바 스크립트 암호 보유자는 사이트 소유자와 최종 사용자 모두가 무시할 경우 프레임 워크 / cms 개발자가 운송 중 암호를 가로채는 사람 (요즘 Wi-Fi 네트워크를 통해 쉽게)을 제한하기 위해 할 수있는 최소한의 것입니다. 보안에 관한 것입니다.