Роман, при правильном использовании HTTPS, пароль может утечь только с сервера.
Утечка из базы
В базе пароль хранится хэшированным (дважды: после того, как хэшированный пароль пришел с клиента, он дополнительно солится и хешируется еще раз) - таким образом, при угоне базы, хакерам придется брутить пароли для того, чтобы получить их тексты.
Утечка пароля другим способом, в сторону сотрудников сервиса - сотрудники сервиса и так много куда имеют доступ, так что знание текста пароля пользователя им бессмысленно. Но если у них есть текст пароля, они могут использовать его для авторизации на других ресурсах, и именно этого можно избежать, хэшируя пароль на клиенте при авторизации.
Если с сервиса утечет первично хешированный пароль, его можно будет использовать только на этом сервисе.
Если же с сервиса утечет не хэшированный пароль, его можно будет использовать и на других сервисах.
В этом - разница.
Все эти меры защиты только снижают вероятность и размер ущерба.
Роман
я уже примерно пятый раз повторяю, что это разные векторы атаки.
Утечка пароля при MITM (то о чем утверждаете вы) исключается при использовании HTTPS и его друзей (HSTS, пин сертификата). Я говорю о другой проблеме
Я же говорю об исключении ситуации попадания текста пароля на сервер даже при регистрации, потому что пароль, например может (умышленно или нет) попасть в логи, а логи могут попасть в паблик - например, в процессе неумелой отладки (включили запись всех POST в лог + расшарили папку с логом)
Еще один раз напишу - сетевой обмен защищается при помощи HTTPS. Хэширование же пароля нужно для защиты от утечек, как в сторону разработчиков/админов сервиса (то, о чем настаиваю я), так и в сторону хакеров, угнавших базу, логи и тому подобные сведения.
Bavashi, о, еще один (вы) не понимает разницы в векторах атаки.
хэширование пароля на клиенте делают не для того, чтобы его украли по дороге на сервер (MITM).
Это делают для того, чтобы на сервере пароль никогда не появлялся даже при регистрации.
