안전하다는 메시지가 나오면 적용이 된 것이라는 검색 결과대로 일단 적용이 됐다고 가정을 했습니다.
서론이 길었고 그래서 제가 궁금한 것은 HTTPS를 적용하면 Post로 Body에 [FromForm]으로 폼 데이터를 보내거나 [FromBody]로 Json을 보내게 되면 암호화가 되어 전송이 된다는 글을 본 것 같은데요. 그러면 로그인 시 사용자 검증을 위해 아이디와 패스워드를 서버로 보낼 때 클라이언트에서 별도의 암호화 알고리즘을 사용하여 암호화를 하지 않아도 되는걸가요?
서버에서는 HMACSHA512로 Salt를 이용하여 해쉬로 저장을 해주고 있습니다.
그런데 보내는 과정에서 탈취가 될 수도 있다는데, HTTPS로 보내면 암호화가 된 상태로 보내지니 별도로 암호화 알고리즘으로 암호화 하는 작업 필요 없이 그냥 보내도 되는지가 궁금해서 여쭤봤습니다.
클라이언트에서 패스워드를 암호화해서 보낸다고 보안이 강화되지 않습니다. 보내는 과정에서 탈취가 SSL 하이재킹을 뜻하는 것 같아서, SSL 하이재킹에 성공한 경우에는 나중에 로그인할 때 같은 요청을 보내는 방법을 생각하면 로그인할 때 암호화를 해서 보내면 로그인이 성공하게 되기에 보안 강화에 의미가 떨어진다고 생각합니다.
하지만 민감한 의료정보, 금융정보, 메세지 경우에는 노출되면 그대로 해석할 수 있기때문에 종단 간 암호화를 사용해서 쉽게 정보만을 탈취하는 것을 방지합니다.
아하, 그러니간 예를 들면 비밀번호가 1234인걸 abcd로 암호화가 됐다고 한들
이걸 탈취해서 로그인할 때 그대로 abcd라는 암호화 된 패스워드를 보내면 결국 로그인에 성공하게 되는거니 보안 강화의 의미가 떨어지는 것이고 다만 금융 정보, 의료 정보 이런 것들은 로그인 처럼 어떤 기능 보다는 그냥 계좌번호, 이름 그 해석 된 정보 그자체로 의미가 있고 노출 되면 안되기에 말씀하신 종단간 암호화를 사용한다 이런식으로 이해하면 될가요?
그러면 결론적으로 그럼 패스워드 같은 정보는 암호화 해서 보내지 않고 그냥 평문 그대로 보내도 된다고 알고 있어도 되는걸가요?
일단 HTTPS의 기술적 정의부터가 비대칭 암호화를 사용하는 SSL 소켓 통신이라, 인증서에 문제가 없고, 연결 간에 프록시 서버처럼 MITM (Man-In-The-Middle, 중간자) 공격을 허용할 여지를 두지 않는다면 "저렴하고 손쉬운 방법"으로 정보를 가로채는 것이 어렵습니다.
클라이언트 측에서 자체적으로 암호화를 해서 관리해야 할 필요가 있다고 하는 것은 보통 클라이언트에 신원 불상/미상의 공격자가 마음대로 접근할 수 있도록 시스템을 개방한 상태이고, 원하는대로 스크립트를 마음껏 실행할 수 있는 상황에서 취할 수 있는 최소한의 방어책일겁니다.
이는 공용 PC나 PC방의 여러 단말 PC들처럼 물리 보안을 지키기 어려운 상황이 아니라면 보통 생각하기 어려운 상황이라고 봅니다. 즉, 사용 시나리오에 따라서 클라이언트 암호화까지도 고려해야 할 수 있지만 정말 필요한 솔루션인지는 개발하는 제품의 상황에 따라 다르다고 볼 수 있겠습니다.
개인적으로 이런 상황은 제품 수준에서 일일이 대응하는 것보다는 사용자에게 보안 상의 위험 사항을 사전 고지하는 것이 바람직하고 경제적인 대응책이라고 생각합니다. 키 로거나 악성 브라우저 익스텐션이 설치되어있을지도 모르는 PC방의 환경까지 책임지기는 어려우니까요.
덧. 최근 이슈가 되고 있는 어느 통신사의 고객/가입자 상대 컴플라이언스 이슈도 전형적인 MITM 공격을 보여주는 사례입니다. 바꿔말하면 기술적인 헛점을 파고 들어서 암호화 된 콘텐츠를 크래킹하는 것보다는, 사회 공학적인 방법이나 위계 질서, 권력, 정치력에 의한 힘으로 MITM 공격을 성공시키는 방법이 일반적으로 훨씬 더 저렴하고 효과적이라는 뜻도 됩니다.
