HTTPS를 통한 일반 텍스트 비밀번호

현재 HTTPS (따라서 SSL 암호화)를 통해 작동하는 PHP OpenID 공급자를 개발 중입니다. 암호를 일반 텍스트로 전송하는
것이 잘못 입니까? 이론상 HTTPS는 가로 챌 수 없으므로 잘못된 것은 없습니다. 아니면 이것은 어떤 수준에서 안전하지 않고 나는 이것을 보지 못하고 있습니까?

그것은 안전하다. 이것이 전체 웹이 작동하는 방식입니다. 양식의 모든 비밀번호는 항상 일반 텍스트로 전송되므로 보안을 위해 HTTPS까지 가능합니다.

여전히 GET이 아닌 POST 요청을 통해 전송했는지 확인해야합니다. GET 요청을 통해 보내면 사용자의 브라우저 기록 로그 또는 웹 서버의 액세스 로그에 일반 텍스트로 저장 될 수 있습니다.

HTTP가 비활성화되고 HTTPS 만 사용하는 경우 어쨌든 실제로 암호를 일반 텍스트로 전송하지 않습니다.

클라이언트 측 해시. 왜? 약간의 실험에 대해 말씀 드리겠습니다. 회사 카페테리아에있는 컴퓨터로 걸어가십시오. 회사 웹 사이트 로그인 페이지 (https)로 브라우저를 엽니 다. F12 키를 누르고 네트워크 탭을 클릭 한 다음 로그 유지를 확인하고 콘솔을 최소화하되 로그인 페이지에 웹 페이지를 열어 둡니다. 앉아서 점심을 먹습니다. 직원이 회사 웹 사이트에 로그온 한 후 직원이 일을 마치면 로그 아웃하는 것을 지켜보십시오. 점심 식사를 마치고 컴퓨터에 앉아 네트워크 탭을 열고 양식 본문에있는 모든 사용자 이름과 암호를 일반 텍스트로 확인합니다.

특별한 도구도, 특별한 지식도, 멋진 해킹 하드웨어도, 키로거도없고, 좋은 오래된 F12도 없습니다.

하지만 필요한 것은 SSL 뿐이라고 계속 생각하십시오. 나쁜 놈들은 당신을 사랑할 것입니다.

이전 답변에 대한 몇 가지 메모를 작성하겠습니다.

첫째, 클라이언트 측에서 해시 알고리즘을 사용하는 것이 최선의 방법은 아닐 것입니다. 암호가 서버 측에서 솔트 된 경우 해시를 비교할 수 없습니다 (최소한 클라이언트 해시를 암호의 해싱 레이어 중 하나에 데이터베이스에 저장하지 않으면 동일하거나 보다 나쁜). 그리고 클라이언트 측에서 데이터베이스가 사용하는 해싱 알고리즘을 구현하고 싶지는 않을 것입니다.

둘째, 암호화 키를 거래하는 것도 이상적이지 않습니다. MITM은 이론적으로 (클라이언트에 루트 인증서가 설치되어 있음을 고려할 때) 암호화 키를 변경하고 자신의 키로 변경할 수 있습니다.

키를 교환하는 이론적 서버의 원래 연결 (tls는 고려하지 않음) :

클라이언트 요청 공개 키> 서버가 개인 키를 보유하고, 클라이언트에 공개 키를 생성> 서버가 클라이언트에 공개 키를 보냅니다.

이제 이론적 인 MITM atrack에서 :

클라이언트 요청 공개 키> MITM에서 가짜 개인 키 생성 > 서버에서 개인 키 보유, 클라이언트에 대한 공개 키 생성> MITM은 원래 서버에서 공개 키를받습니다. 이제 우리는 가짜 공개 키를 클라이언트에 자유롭게 보낼 수 있습니다. 클라이언트에서 요청이 올 때마다 가짜 키로 클라이언트 데이터를 해독하고 페이로드를 변경 (또는 읽음)하고 원래 공개 키로 암호화 > MITM은 가짜 공개 키를 클라이언트로 보냅니다.

이것이 TLS에서 신뢰할 수있는 CA 인증서를 갖는 요점이며 인증서가 유효하지 않은 경우 브라우저 경고 메시지를받는 방법입니다.

OP에 대한 응답으로 : 제 생각에는 그렇게 할 수 없습니다. 조만간 누군가가 귀하의 서비스에서 사용자를 공격하고 귀하의 프로토콜을 위반하려고 할 것이기 때문입니다.

그러나 할 수있는 일은 사람들이 동일한 비밀번호로 로그인을 시도하지 못하도록 2FA를 구현하는 것입니다. 하지만 리플레이 공격에주의하십시오.

나는 암호화가 좋지 않다. 내가 틀렸다면 나를 고쳐주세요.

다른 포스터는 맞습니다. 이제 SSL을 사용하여 암호 전송 을 암호화하고 있으므로 좋은 알고리즘과 솔트를 사용하여 해싱 하여 휴지 상태 에서도 보호되도록하십시오 .

@CodeDog 예제에 문제가 있습니다 ..

예, 사용자가 카페테리아 상자에 로그인 할 것이라고 믿을 수 있습니다. 당신이 기업 caffeteria에서 로그를 캡처하는 경우, 당신은 보안 위반입니다. 회사 카페테리아 상자를 비활성화해야합니다 (예 : 용어 없음, 로거 없음, 원격 액세스 없음 등). 내부 해커를 방지하기 위해.

이 예는 컴퓨터 액세스 보안의 좋은 예이며 실제로 네트워크 보안과 관련이 없습니다. 클라이언트 측 해싱에 대한 근거로 제공되지만 컴퓨터에 액세스 할 수있는 경우 키 입력 로거를 사용하고이를 우회 할 수 있습니다. 클라이언트 측 해시는 다시 관련이 없습니다. @CodeDog의 예는 컴퓨터 액세스 해킹이며 네트워크 계층 해킹과 다른 기술이 필요합니다.

또한 위에서 언급했듯이 공용 컴퓨터 해킹은 위협으로부터 시스템을 손상시킴으로써 보호됩니다. 예 : 공용 카페테리아 컴퓨터에 크롬 북을 사용합니다. 그러나 그것은 물리적 해킹에 의해 우회됩니다 . 업무 외 시간에는 카페테리아에 가서 비밀 카메라를 설정하여 사용자의 키보드 누름을 기록합니다. 그러면 카페테리아 컴퓨터가 무력화되었는지 또는 어떤 유형의 암호화가 사용되는지는 중요하지 않습니다.

물리적 계층-> 컴퓨터 계층-> 클라이언트 계층-> 네트워크 계층-> 서버 계층

네트워킹의 경우 https / ssl 레이어가 일반 암호를 암호화하므로 클라이언트 측에서 해시해도 상관 없습니다. 따라서 다른 사람들이 언급했듯이 TLS가 안전하면 클라이언트 해싱이 중복됩니다.