클라이언트 측에서 해싱 암호를 사용할 가치가 있습니까?

로그인 시스템을 설치하려면 항상 주어진 암호의 MD5를 서버 측의 users 테이블에있는 값과 비교하십시오.

그러나 내 친구가 네트워크 소프트웨어로 "명확한"암호를 스니핑 할 수 있다고 말했습니다.

그래서 내 질문은 : 클라이언트 측에서 암호를 해시하는 것이 좋은 생각입니까? 서버 쪽에서 해시하는 것보다 낫습니까?

기본적으로 친구가 옳습니다. 그러나 단순히 클라이언트 측에서 암호를 해싱하는 것은 아니라 단지 서버에 일반 텍스트로 제출보다 더. 일반 텍스트 비밀번호를 청취 할 수있는 사람은 확실히 해시 된 비밀번호를 청취 할 수 있으며 캡처 된 해시를 사용하여 서버에 대해 인증 할 수 있습니다.

이와 관련하여,보다 안전한 인증 프로토콜은 일반적으로 클라이언트가 암호와 함께 해시되는 임의의 임의 비트를 선택할 수있게하여 이러한 재생 공격이 작동하지 않도록하기 위해 일반적으로 여러 후프를 뛰어 넘습니다. 서버에 공개적으로 제출했습니다.

서버에서 :

• 무작위로 몇 비트 생성
• 이 비트 (일반 텍스트)를 클라이언트에게 보냅니다.

클라이언트에서 :

• 몇 개의 임의의 비트를 생성
• 암호, 서버의 임의의 비트 및 클라이언트 임의의 비트를 연결
• 위의 해시를 생성
• 서버에 임의의 비트 (일반 텍스트) 및 해시 제출

서버는 클라이언트의 임의의 비트뿐만 아니라 자체 임의의 정보를 알고 있기 때문에 (일반 텍스트로 표시) 본질적으로 동일한 변환을 수행 할 수 있습니다. 이 프로토콜은 양 당사자가 매번 다른 "노이즈 비트"를 생성하는 한,이 대화를 듣는 사람이 나중에 기록 된 정보를 사용하여 허위 인증을 위해 정보를 사용할 수 없도록합니다. 손 흔들림이 수행됩니다.

편집이 모든 것은 오류가 발생하기 쉬우 며 지루하며 올바르게 처리하기가 다소 어렵습니다 (읽기 : 보안). 가능하다면, 이미 지식이있는 사람들이 작성한 인증 프로토콜 구현을 사용해보십시오. 위의 내용은 내가 한 번 전에 읽은 책의 기억에 의한 것입니다.) 여러분은 이것을 보통 스스로 작성하고 싶지 않습니다.

우선, 이것은 응용 프로그램의 보안을 향상 시키지 않습니다 (웹 응용 프로그램이라고 가정).

SSL (또는 실제로는 SSL이라고도 함) TLS를 사용하십시오. 실제로는 비싸지 않습니다 (사용 방법을 찾아 최소 임금으로 곱하면 인증서 구매가 거의 항상 승리합니다).

그 이유는 간단합니다. TLS는 암호화에서 상당히 큰 문제 (자체 서명이 아닌 인증서를 구매 한 상태에서 사용하는 경우)를 해결합니다. 대화중인 서버가 대화중인 서버인지 어떻게 알 수 있습니까? TLS 인증서는 "브라우저가 신뢰하는 인증 기관인 나에게 [url]의 웹 사이트에이 공개 키가 있고 해당 개인 키 (서버 만 알고있는 개인 키)가있는 공개 키를 가지고 있음을 인증합니다. 누군가 문서를 변경 한 경우 볼 수 있습니다. "

TLS가 없으면 커피 숍에서 옆에 앉아 있으면 랩탑 / 스마트 폰이 내가 서버이고 MiTM (Man in The Middle)이라고 생각하게 할 수 있기 때문에 암호화가 의미가 없습니다. TLS를 사용하면 사이트와 일치하는 인증 기관 서명 인증서가 없기 때문에 랩톱 / 스마트 폰이 "UNTRUSTED CONNECTION"으로 소리를 지 릅니다. (암호화 대 인증).

면책 조항 : 사용자는 다음 경고를 통해 오른쪽 클릭하는 경향이 있습니다. "신뢰할 수없는 연결? 무엇입니까? 단지 고양이 사진을 원합니다! 예외 클릭 추가 확인을 클릭하십시오 ! 새끼 고양이!"

그러나 실제로 인증서를 사고 싶지 않다면 여전히 클라이언트 측 자바 스크립트 해싱을 구현 마십시오 (그리고이를 위해 standford 라이브러리 (SJCL)를 사용하지 마십시오 . 절대로 구현하지 마십시오 ).

왜? 비밀번호 재사용! HTTPS없이 쉽게 세션 쿠키를 훔칠 수 있습니다 (내가있는 서버로 척 할 수 있음) (firesheep 참조). 그러나 자바 스크립트를 로그인 페이지에 추가하여 전송하기 전에 비밀번호를 해시합니다 (SHA256을 사용하거나 더 나은 경우 SHA256을 사용하고 생성 한 공개 키를 전송 한 다음 해시 된 비밀번호를 암호화하여 소금을 사용할 수 없음) 이를 사용하여 해시 / 암호화 된 비밀번호를 서버로 보냅니다. 소금을 사용하여 서버의 해시를 다시 해시하고 데이터베이스에 저장된 것과 비교하십시오 (암호를 다음과 같이 저장하십시오).

(SHA256(SHA256(password)+salt))

(소금도 데이터베이스에 일반 텍스트로 저장하십시오). 다음과 같이 비밀번호를 보내십시오.

RSA_With_Public_Key(SHA256(password))

다음과 같이 비밀번호를 확인하십시오.

if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok

왜냐하면 경우 누군가가 당신의 클라이언트를 스니핑, 그들은 당신의 클라이언트 (세션 하이재킹)로 로그인 할 수 있지만,이 것 결코 (일반 텍스트 암호를 볼 그들이 당신의 자바 스크립트를 변경하지 않는 한, 그러나, 해커 아마 하우투 알 수 없습니다 / 관심이 스타 벅스 따라서 이들은 웹앱에 액세스 할 수 있지만 이메일 / 페이스 북 등에는 액세스 할 수 없습니다. (사용자가 동일한 비밀번호를 사용할 가능성이 높습니다). (이메일 주소는 로그인 이름이거나 webapp의 프로필 / 설정에서 찾을 수 있습니다).

Dirk은 악의적 인 사용자가 네트워크에있는 암호를 해시하고 해시가 전송되는 것을 확인하고 단순히 동일한 해시를 직접 전송할 수 있다고 언급하더라도 걱정하지 않아도됩니다.

그것은는 약간 은 암호가 무엇인지 알고에서 악의적 인 사용자를 방지한다는 점에서 더 나은,하지만 그들은 여전히 로그인 (또는 잠재적으로 수 있기 때문에 원래 암호를 재구성 ), 그 도움이되지 있다고.

일반적으로 사용자의 비밀번호와 데이터의 안전성에 대해 걱정이된다면 안전한 SSL 서버를 사용하는 것이 좋습니다. 이것이 어떤 이유로 든 당신에게 관심이 없다면 해싱을 방해하지 않을 것입니다. 그것은 모호함을 통한 보안 입니다.

2014 년 8 월 편집 : 통신 자체를 보호하는 것이 네트워크 스니핑 공격을 막는 유일한 방법이기 때문에 Google은 웹 사이트가 어디에서나 HTTPS 로 전환 할 수 있도록 점점 더 많은 노력을 기울이고 있습니다 . 전송 된 데이터를 난독 화하려는 시도는 전적으로 공격자를 막는 것이 아니라 방해하지 않으며 개발자에게 위험한 잘못된 보안 감각을 부여 할 수 있습니다.

실제로이 경우 클라이언트 측 해싱이 더 안전하다는 데 동의하지 않습니다. 덜 안전하다고 생각합니다.

실제 비밀번호 (또는 암호화 된 비밀번호)와 달리 데이터베이스에 비밀번호의 해시를 저장하는 요점은 해시에서 원래 비밀번호를 얻는 것이 수학적으로 불가능하다는 것입니다 (이론적으로 충돌을 얻는 것이 가능하지만) 해시 입력의 난이도는 해싱 알고리즘의 보안 강도에 따라 다릅니다. 여기서 가능한 공격 경로는 잠재적 인 공격자가 어떻게 든 암호 저장소 데이터베이스를 손상시킨 경우에도 사용자의 원래 암호를 얻을 수 없다는 것입니다.

인증 메커니즘이 비밀번호의 해시를 전송하는 경우이 보안 침해 시나리오에서 공격자는 실제 비밀번호를 알 필요가 없습니다. 침입자는 자신이 가지고있는 해시를 보내면 특정 사용자의 계정에 액세스 할 수 있습니다. 그리고 확장하여 전체 시스템. 이것은 처음에 해시 된 암호를 저장하는 지점을 완전히 물리칩니다!

이를 수행하는 가장 안전한 방법은 클라이언트에게 암호를 암호화하기 위해 일회용 공개 키를 보낸 다음 서버 측에서 암호를 해독하고 다시 해시하는 것입니다.

그런데 이런 종류의 질문은 아마도 Security StackExchange에 대해 더 많은 전문가 응답을 얻을 것입니다.

제 3 자로부터 비밀번호를 안전하게 유지하는 것만으로는 충분하지 않습니다.

즉시로 개인 정보가 포함된다 (그리고 그것을하지 않을 때 지금까지, 요즘은?) 당신이 암호를 알고 싶지 않아요. 가지고 있지 않은 것을 남용하거나 유출 할 수 없습니다 일반 텍스트 암호를 절대 보지 않으면 귀하와 고객 모두 더 잘 수 있습니다.

따라서 클라이언트 측 해싱 / 암호화가 의미가 있습니다.

클라이언트 측 해싱을 사용할 수 있지만 서버 측 솔트는 사용할 수 없습니다.

클라이언트 측의 암호 암호화 링크를 확인하십시오.

나는 최근에 이것에 대해 많은 일을 해왔다. IRL은 클라이언트 측 해시 / 대칭에 두 가지 문제가있다 실제로 아이디어를 죽이는 암호화와 . 클라이언트 쪽에서는 암호가 필요합니다 ... 목적을 무너 뜨립니다. 2. 해싱 구현 (대부분의 사이트가 3 개 또는 4 개 해싱 알고리즘 중 하나를 사용하므로 많은 거래가 아님)을 노출시켜 공격을보다 쉽게 ​​만듭니다 (n보다는 하나만 시도하면 됨).

내가 결국 갔던 것은 OpenPGP.js 또는 이와 유사한 것을 사용하는 클라이언트의 비대칭 암호화였습니다 ... 클라이언트에서 가져온 키 또는 클라이언트 측 생성 키와 공개 키를 보내는 서버에 의존합니다. 클라이언트의 공개 키만 서버로 다시 보낼 수 있습니다. 이것은 MIM 공격으로부터 보호하고 장치만큼 안전합니다 (현재는 클라이언트의 개인 키를 기본적으로 localStore에 저장합니다. 데모입니다).

이것의 주요 장점은 서버 / 데이터 저장소에서 암호화되지 않은 메모리에 사용자 데이터를 저장할 필요가 없으며 서버의 개인 키는 물리적으로 분리 할 필요가 없다는 것입니다

이것의 기초는 사람들이 HTTPS가 제한되는 곳 (예 :이란 / 북한) 등을 안전하게 통신 할 수있는 방법과 재미있는 실험을 제공하는 것이 었습니다.

나는 이것을 생각하기 위해 처음부터 FAR입니다. http://www.mailvelope.com/ 은 이것을 사용합니다.

누군가가 연결에서 데이터를주고받을 수 있으면 인증이 저장되지 않습니다. 대신 나는 비밀스러운 것들을 위해 다음을 할 것입니다.

서버로 전송되기 전에 클라이언트 측에서 비밀번호가 사전 해시되었습니다. 서버는 브라우저에서 보낸 해시의 다른 해시 및 솔트 값을 저장합니다.

따라서 중간 사용자 공격으로 로그인 할 때와 동일한 해시 값을 보낼 수 있지만 사용자 비밀번호는 알 수 없습니다. 이렇게하면 다른 곳에서 로그인하기 위해 동일한 자격 증명으로 다른 서비스를 시도하지 못하게됩니다.

사용자 데이터는 브라우저 측에서도 암호화됩니다.

아, 중개인 공격은 암호화 된 데이터를 얻지 만, 로그인에 사용 된 실제 암호가 없으면 암호를 해독 할 수 없습니다. (로그인 할 때 브라우저의 DOM에 저장된 사용자 비밀번호). 따라서 실제 사용자는 해독 된 내용을 볼 수 있지만 중간 사람은 볼 수 없습니다. 이것은 또한 NSA 또는 다른 기관이 귀하 / 회사 / 호스팅 제공 업체에게이 데이터의 해독이 불가능하기 때문에이 데이터의 암호 해독을 요청할 수 없음을 의미합니다.

이 두 가지 방법 중 일부 작은 예는 내 블로그 http://glynrob.com/javascript/client-side-hashing-and-encryption/에 있습니다.

최근 GitHub와 Twitter는 내부 로그에 비밀번호를 저장했다고 발표했습니다. 나는 실수로 버그 보고서와 splunk 등에 들어가는 다른 로그에서 이런 일이 일어났다. 트위터의 경우 트럼프의 암호가 거기에 있으면 관리자가 "보"는 것이 큰 일이 될 수있다. 관리자가 많이 사용하지 않기 때문에 큰 거래입니다. 관리자에 관계없이 우리는 암호가 우리를 보는 것을 좋아하지 않습니다.

따라서 해싱이 보안을 위해 클라이언트 측에서 발생해야하는지에 대한 질문이지만, 결국 서버 측에서 암호를 해시하고 비교하여 어떻게 든 로그되지 않도록 암호를 보호 할 수 있습니까?

암호화는 개발자가 적어도 몇 가지 문제를 겪어야하기 때문에 나쁜 생각이 아니며 암호를 로그에 넣은 것을 발견하면 암호화 키를 변경하고 원본을 파괴하면 데이터가 쓸모 없게됩니다. 밤마다 키를 돌리는 것이 더 좋으며 창을 크게 줄일 수 있습니다.

사용자 레코드에서 해시를 해시 할 수도 있습니다. 유출 된 비밀번호는 일반 텍스트 비밀번호로 해시됩니다. 서버는 해시의 해시 버전을 저장합니다. 물론 해시는 암호가되지만 사진 메모리가 없으면 60 문자 bcyrpt를 기억하지 못할 것입니다. 사용자 이름과 소금. 로그인 프로세스 중에 사용자에 대해 무언가를 수집 할 수 있다면 (사용자 레코드가 노출되지 않음) 사이트와 공유 할 수없는보다 강력한 해시를 생성 할 수 있습니다. 중간에 아무도 사이트 사이에 캡처 된 해시를 잘라 붙여 넣을 수 없습니다.

서버에 다시 제출되지 않은 쿠키와 결합하면 무언가 문제가 발생할 수 있습니다. 먼저 요청시 키를 사용하여 쿠키를 클라이언트에 제출 한 후 쿠키가 로그인 서비스로 돌아 가지 않도록 쿠키가 기록되지 않도록하십시오. 세션 저장소에 키를 저장 한 다음 로그인이 발생하거나 세션이 만료되면 바로 삭제하십시오 ...이 상태는 JWT 녀석이 필요하지만 nosql 서비스를 사용할 수도 있습니다.

따라서 관리자는 해시 및 암호화 된 비밀번호 중 하나를 splunk 또는 버그보고 도구를 통해 보게됩니다. 그들이 더 이상 암호화 키를 찾을 수 없기 때문에 쓸모가 없어야하며, 그렇게하더라도 해시를 무차별 처리해야합니다. 또한 최종 사용자는 줄을 따라 일반 텍스트를 보내지 않았으므로 중간에있는 사람은 적어도 시간이 더 어려워 다른 사이트로 뛰어 가서 로그인 할 수 없습니다.

이걸 고려하세요:-

클라이언트가 서버에 요청을 보냅니다. "확인할 비밀번호가 있습니다".

서버는 클라이언트에게 일회성 임의 문자열을 보냅니다. R $

클라이언트는 적용하려는 (변수) 규칙에 따라이 문자열에 사용자 비밀번호를 포함시킵니다.

클라이언트는 문자열을 서버로 보내고 암호가 정상이면 서버가 사용자를 로그인합니다.

서버가 R $를 사용하여 다른 로그인 요청을 받으면 사용자가 로그 아웃되고 계정은 조사 대기 중입니다.

분명히 다른 모든 (일반적인) 보안 예방 조치가 취해질 것입니다.

클라이언트 쪽 해싱에 대한이 아이디어는 사이트가 아닌 사용자를 보호하는 것입니다. 이미 여러 번 언급했듯이 일반 텍스트 또는 해시 비밀번호는 모두 사이트에 동일하게 액세스 할 수 있습니다. 보안 혜택은 없습니다.

그러나 사용자는 실제 일반 텍스트, 비밀번호 만 알고 있어야합니다. 그들이 암호로 선택한 것을 아는 것은 다른 사이트 및 시스템에서 암호로 사용할 수있는 정보입니다. 귀하는 서버 개발자 또는 제 3자가 비밀번호 선택을 발견하지 못하도록 보호하는 고객 중심 사이트입니다.