사이트가 https로 되어 있습니다.
그래서 로그인 할 때 서버에는 암호화가 되어서 전송이 되고.. 실제 db에도 암호화가 되어 들어가죠.
다만, 로그인 폼에서 id, pw를 입력하고서.. 로그인버튼을 눌렀을 때..
웹브라우저에서 F12키를 누르면... 헤더의 request payload 에서 ID, PW가 평문으로 보여집니다. (즉, 서버로 전송되기 직전에는 평문으로 보여지는.. 전송될 때는 암호화 되어 전송..)
이게 보안적인 측면에서 '당연한' 또는 '어쩔수 없는' 부분인 걸까요?
아니면 보안적인 측면에서 저 부분도 당연히 암호화를 해서 보내는것이 맞는걸까요?
보안에 크게 신경을 안쓴다면야 굳이 request payload 부분까지 암호화 할 필요가 없을테고.. 그저 https로만 해도 되겠지만서도...
일부 몇몇 웹개발자들은 저 부분은 어쩔수 없는거고 당연히 보일수밖에 없는거다.
어자피 서버로 암호화 되서 전송되기 때문에 아무 문제가 없다... 라고 하는데..
...흠...
1. 프록시 툴을 이용하여 중간에서 요청값을 가로챌 경우 암호화되어 보호 할 수 있다는 점
2. 이건 좀 극단적인 상황이겠지만..충분히 있을수 있는 일인데...
특정 사이트에 로그인을 하고서.. 잠시 화장실에 간다고 자리를 비웠을 때..
다른 사람이 내 자리에 앉아서 웹브라우저의 F12키를 눌러서 계정정보를 획득하려 할 때 방지할 수 있다는 점
이제 전송레이어를 고민하는데, 전송레이어의 암호화 수준이 충분치 않다고 생각이 되면 각 종단에서 한번더 암호화 복호화를 할수도 있습니다. 실제로 오래전에는 암호화 기술의 사용 제한이나 서버, 클라이언트의 성능상의 이슈로 높은 수준의 암호화를 항상 하기 힘들었고 그래서 로그인 관련된 부분에 부가적인 암호화를 하기도 했습니다.
현재도 오래된 시스템의 경우 낮은 수준의 암호화를 사용할 수도 있습니다. 전적으로 https에 의존하는 경우 셋팅을 다시금 확인해 볼 필요는 있죠.
클라이언트 웹브라우저에서는 당연히 보여지는거라..어쩔수 없다나..? ㅡㅡ
하지만 말씀하신것처럼 클라이언트의 제어권이 해커에게 넘어간 경우...
암호화가 되었다면 중간에서 프록시툴을 이용하여 요청값을 가로채도 볼 수가 없겠죠.
브라우저의 디버깅 창을 보는게 쉬운것도 아니고 그걸 볼 수 있는 상황이면 이미 충분히 브라우저에 대한 권한을 획득했다고 보면 됩니다. 특별히 암호화 한다고 보안성이 많이 올라가지 않습니다.
브라우저에 직접 유저 크리덴셜을 입력하지 않는 다른 채널이나 디바이스를 이용한 인증등도 있습니다만, 비용이 크죠.
종단간 암호화는 각 종단이 무결하다는 전제하에 이루어지는거고, 애초에 한 종단이 오염되어있으면 거기에 무슨 추가적인 보호조치를 해도 소용없습니다.
은행같은데 들어가면 귀찮게 보안프로그램 뜨고 이런게 이 단말이 현재 무결한 상태인지 검증하기 위해서 뜨는거고요.
사실 제가 이 글을 쓴 이유는..
일부 웹개발자들이 저 부분은 클라이언트 웹브라우저에서 보여지는 요청값이므로 원래 보여지는거고, 그게 당연하다는 듯이 얘기를 하길래 써본 글이었습니다.