client side 에서의 해싱이 일반적이지 않게 된 건 보안의식 상향과 SSL의 일반화가 절묘하게 맞물린 결과지 client side hashing이 무의미해서가 아님. 단순히 생각해 보면 서버 입장에서는 평문 비밀번호나 클라이언트에서 해싱한 비밀번호나 다를 게 전혀 없으므로 어느 쪽을 탈취하게 되든 똑같이 계정을 탈취할 수 있다고 생각할 수 있겠지만 실상은 조금 더 복잡함.


1. 우선 평문 비밀번호가 탈취되는 것과 해싱된 비밀번호가 탈취되는 건 완전히 다른 유형의 사고임. 해싱된 비밀번호가 탈취된다면 같은 해싱 알고리즘을 클라이언트에서 사용하는 서비스들에서만 로그인을 시도해 볼 수 있겠지만, 평문 비밀번호가 털린다면 해당 사용자가 이용하는 모든 서비스에 평문 비밀번호를 대입해 볼 수 있음. 물론 서비스마다 비밀번호를 모두 다르게 쓰는 사용자 풀이라면 아무 문제 없겠지만 이게 가능할 리는 없음.


2. SSL이 일반화되기 전까지는(사실 꽤 최근까지도) 보안 의식이 매우, 매우 미비했었음. 비밀번호를 평문으로 저장해서는 안 된다는 걸 지키지 않는 곳도 적지 않았었고, 이는 대기업도 마찬가지 였던 것으로 보임. 꽤 최근(2019년)에도 페이스북이 비밀번호 수억개를 평문으로 저장해 왔음을 실토했었음. (https://krebsonsecurity.com/2019/03/facebook-stored-hundreds-of-millions-of-user-passwords-in-plain-text-for-years/)


3. 보안의식 상승과 함께 SSL이 일반화됐고, 비밀번호 평문 저장 금지 원칙 역시 함께 일반화됐음. client side hashing 사례를 찾아보기 쉽지 않은 건 아마 이게 주 원인이 아닐까 싶음. 평문으로 전송하고 평문으로 저장하던 방식에서 바로 믿을 수 있는 통신 방식으로 평문을 보내고 해싱해서 저장하는 방식으로 넘어갔으니, 믿을 수 없는 통신 방식으로 해싱된 걸 보내고 이걸 다시 해싱해서 저장하는 방식을 찾아보기 힘들게 된거 아닐까 싶음.


4. 결정적으로 비밀번호 저장 단계에서 해싱을 거친다고 해도, 간단한 실수나 설계 오류로 클라이언트에서 받아온 평문 비밀번호가 어딘가 기록될 가능성이 있음. Github에서도 클라이언트에서 받아온 평문 비밀번호를 로그로 저장한 사고가 터진 바 있었음. (https://www.bleepingcomputer.com/news/security/github-accidentally-recorded-some-plaintext-passwords-in-its-internal-logs/)


사실 지금도 카페 같은 곳에서 ARP Spoofing 걸어놓고 http 패킷들을 살펴 보면 평문으로 날아다니는 누군가의 비밀번호를 심심치 않게 발견할 수 있을거임. (당연히 범죄니까 진짜로 해 보는 깃붕이는 없기를 바라겠음) 대학교 구닥다리 LMS들이 이 쪽으로 특히 취약한 거 같으니 깃붕이들은 특별히 조심해서 쓰도록 하자.