http를 통해 전송 된 비밀번호의 공격 경로는 무엇입니까?

고객에게 로그인이 필요한 웹 사이트에 대한 SSL 비용을 지불하도록 설득하려고합니다. 누군가 전송중인 비밀번호를 볼 수있는 주요 시나리오를 올바르게 이해하고 싶습니다.

저의 이해는 길을 따라 어떤 홉에서든 패킷 분석기 를 사용하여 전송 되는 것을 볼 수 있다는 것입니다. 이것은 해커 (또는 악성 코드 / 봇넷)가 패킷이 목적지에 도착하기 위해 가져 오는 홉과 동일한 서브넷에 있어야하는 것으로 보입니다. 맞습니까?

이 서브넷 요구 사항의 특징을 충족한다고 가정하면 모든 홉 또는 첫 번째 홉에 대해 걱정해야합니까? 내가 분명히 사람이 듣기 할 수 있기 때문에 그들이 공공 와이파이 네트워크에 있다면 걱정할 수있는 첫 번째. 해야 나는 패킷이 외부에서 여행을 것 서브넷에에 무슨 일이 일어나고 있는지에 대해 걱정? 나는 네트워크 트래픽에 대해 많은 것을 알지 못하지만 주요 통신 사업자의 데이터 센터를 통해 흐르고 있다고 가정 할 것입니다.

패킷 분석기로 듣는 사람이 아닌 다른 곳에서 걱정할 다른 벡터가 있습니까?

나는 네트워킹 및 보안 멍청한 놈 이므로이 중 하나에서 잘못된 용어를 사용하고 있다면 자유롭게 설정하십시오.

다른 사람들이 여기서 언급하지 않은 점은 일부 브라우저가 양식 데이터를 캐시한다는 것입니다. SSL 사이트의 기본 동작은 일반적으로 "비밀번호 저장"을 선택하지 않으면 아무것도 캐시하지 않는 것입니다. 일반적으로 암호 필드는 어쨌든 캐시되지 않지만 몇 가지 이상한 점이 있습니다 (일반적으로 신용 카드 정보는 실제로 질문의 주제가 아닙니다).

주목할 점은 SSL 암호화는 TCP 핸드 셰이크에서 시작한다는 것입니다. SSL을 사용하면 포트 번호를 통한 가정과는 별개로 SSL을 통한 HTTP와 SSL을 통한 HTTP를 구별 할 수 없습니다.

또한 로그인 요청을 "Im just browse"요청과 구별 할 수 없으며, 이는 해커로부터의 페이지 흐름을 혼란스럽게하며 암호 데이터뿐만 아니라 인터넷 사용 기록 / 쿠키 데이터 / 및 귀하의 계정과 함께 제공되는 개인 정보.

종합적으로 스펙트럼에서 중간자 (man-in-the-middle) 공격을 제거하면 많은 잠재적 인 공격을 줄일 수 있습니다. 또한 영역 지정 정책 은 사용자가 사이트 외부로 리디렉션되는 경우 영역을 변경하므로 XSS 공격으로부터 사용자를 보호하는 데 도움이됩니다.

데이터는 첫 단계 나 마지막 단계뿐만 아니라 경로의 어느 곳에서나 취약합니다. 전송과 관련된 시스템이 사용자 이름, 암호 및 기타 민감한 데이터를 검색하는 것이 가능합니다. 따라서 민감한 데이터는 보안이 유지되는 링크를 통해서만 이동해야하며 물론 SSL과 정확히 일치해야합니다. 관련된 데이터에 따라 SSL을 규정하는 현지 법률이있을 수 있습니다.

데이터를 저장할 수있는 프록시 서버가 있습니다.

그러나 사용자 암호를 안전하게 유지해야 할 의무도 있습니다. 많은 사용자가 제한된 암호 세트를 사용하므로 안전하지 않은 사이트는 예를 들어 홈 뱅크 암호를 손상시킬 수 있습니다.

당신의 분석은 합리적입니다, IMHO.

주의해야 할 것은 경로에 캐시가있을 수 있다는 것입니다. 따라서 요청이 어딘가에 기록 될 수 있습니다 (특히 로그인이 GET을 통해 끔찍한 경우).

아마도 고려해야 할 것은 대부분의 네트워크 액세스가 동일한 네트워크에 다른 많은 사람들이있는 영역에서 발생한다는 것입니다. Work / Uni / School이 주요 예입니다. 집에서는 걱정할 필요가없는 길이 기 때문에 덜 위험하다고 주장 할 수 있습니다.

그러나 실제로 여기에는 의문의 여지가 없습니다. 로그인 할 때 SSL을 사용합니다. 아마도 그 사람에게 가장 매력적인 주장은 웹 사이트를보다 신뢰할 수있게 만드는 것입니다. 이상적으로는 일반 대중은 SSL 기반 로그인 화면이없는 사이트에 로그인하지 않을 것입니다. .

그러나 현실적이 되십시오. 확실히이 공격 경로는 시스템이나 사용자가 타협하는 방식이 아닙니다.

HTH.

본인의 질문에 대답하려는 KevinM의 생각에 동의 할 수 있으며 John Gardeniers가 올바른 방향을 가리키고 있습니다. 또한 "이상적으로-일반 대중은 SSL 기반 로그인 화면이없는 사이트에 절대 로그인하지 않을 것"이라는 말에 동의해야하지만 이것이 현대의 사례가 아니라는 점을 지적해야합니다. 조금도.

나는 "일반적인"대중이 어리석은 유비쿼터스 인식으로 이끄는 실키 톤 (아마도 의도하지 않은)에 동의하지 않는다. KevinM의 클라이언트는 SSL이 필요 없다는 개념을 분명히 가지고 있지 않으며, 이것이 바로 평범한 사람입니다. 그들은 바보가 아니며 단순히 모릅니다. "당신은 이것을 필요로합니다"라고 말하면, "나는 그것없이 x 년을 살았고 x 더 잘 살 것입니다", 또는 더 나쁜 반응을 보일 것입니다. " 그러므로 조심 해주시길 바랍니다!

당신의 우려는 합법적입니다, 케빈 고객은 SSL 인증서가 필요합니다. 당신의 진짜 관심사는 그것들을 판매하는 방법이어야한다고 생각합니다. 사용자 로그인뿐만 아니라 관리자 및 운영자 로그인도 SSL에 의해 보호되는 이점이 있습니다.

예, 이와 관련하여 XSS 와 같은 패킷 스니핑보다 더 중요한 것이 있습니다. 그것들은 많고 문서화되어 있습니다.

HTTP를 통해 스니핑 할 수 있고 데이터를 볼 수있는 경우 전체 경로에서 패킷이 뒤 따릅니다 (TOR와 같은 프록시에서 HTTP를 사용하더라도 하베스트 공격 등). 프록시가 데이터 패킷을 유출하도록 속일 수 있습니다 ... 따라서 민감한 (비밀번호, 개인 정보, 개인 이미지 등)에 가까운 것이 있으면 HTTPS를 통해 전송하는 것이 적합합니다.

또한 HTTPS조차도 잘못된 구현으로 취약하며 그에 적용 가능한 몇 가지 SSL 공격이지만 여전히 신중하게 구현하면 피할 수 있습니다.

그러나 일반 텍스트에 HTTP를 사용하는 것은 초보자도 아이들에게 암호를 스니핑하도록 초대하는 것과 같습니다.