Роман, при правильном использовании HTTPS, пароль может утечь только с сервера.
Утечка из базы
В базе пароль хранится хэшированным (дважды: после того, как хэшированный пароль пришел с клиента, он дополнительно солится и хешируется еще раз) - таким образом, при угоне базы, хакерам придется брутить пароли для того, чтобы получить их тексты.
Утечка пароля другим способом, в сторону сотрудников сервиса - сотрудники сервиса и так много куда имеют доступ, так что знание текста пароля пользователя им бессмысленно. Но если у них есть текст пароля, они могут использовать его для авторизации на других ресурсах, и именно этого можно избежать, хэшируя пароль на клиенте при авторизации.
Если с сервиса утечет первично хешированный пароль, его можно будет использовать только на этом сервисе.
Если же с сервиса утечет не хэшированный пароль, его можно будет использовать и на других сервисах.
В этом - разница.
Все эти меры защиты только снижают вероятность и размер ущерба.
Роман
я уже примерно пятый раз повторяю, что это разные векторы атаки.
Утечка пароля при MITM (то о чем утверждаете вы) исключается при использовании HTTPS и его друзей (HSTS, пин сертификата). Я говорю о другой проблеме
Я же говорю об исключении ситуации попадания текста пароля на сервер даже при регистрации, потому что пароль, например может (умышленно или нет) попасть в логи, а логи могут попасть в паблик - например, в процессе неумелой отладки (включили запись всех POST в лог + расшарили папку с логом)
Еще один раз напишу - сетевой обмен защищается при помощи HTTPS. Хэширование же пароля нужно для защиты от утечек, как в сторону разработчиков/админов сервиса (то, о чем настаиваю я), так и в сторону хакеров, угнавших базу, логи и тому подобные сведения.
Bavashi, о, еще один (вы) не понимает разницы в векторах атаки.
хэширование пароля на клиенте делают не для того, чтобы его украли по дороге на сервер (MITM).
Это делают для того, чтобы на сервере пароль никогда не появлялся даже при регистрации.
Anton Kuzmichev, правильно ли я понимаю, что кроме перехода на личности, содержательных аргументов против того, чтобы не допускать попадание пароля на сервер даже при регистрации пользователя, у вас нет?
galaxy, Все три ваших "факта" будет видно при аудите безопасности - и короткую соль, и одинаковую соль, и слабую функцию.
Насчет ваших поздравлений. Хранилище паролей - это отдельная мера безопасности, которую может применять пользователь по своему желанию. Я же говорю о защите интересов тех пользователей, которые хранилищем не пользуются.
Daria Motorina, это не альтернатива, так как при использовании моего способа, лог попадает в инфраструктуру докера, откуда потом он может попадать в Кубернетис или еще куда-то
Смапив папку, вы просто получите персистентую свалку логов, а инфраструктуру - нет.
Anton Kuzmichev, вы смешиваете в кучу три атаки.
1) кража владельцем сервера пароля пользователя для использования его в своих целях
2) кража пароля третьей стороной в процессе MITM
3) онлайн-брутфорс пароля
От первого мы защищаемся, хэшируя и подсаливая пароль на клиенте (соль дает сервер). Вы грубо ошибаетесь, утверждая, что пароль и хэш тождественны. Располагая соленым хэшем, владелец сервера будет вынужден потратить много-много времени на восстановление из него пароля обратно. Разумеется, для хранения пароля у себя, он должен его посолить еще раз, но это уже защита от Евы, укравшей базу.
От второго мы используем HTTPS, без этого никак
Третье - это просто детская атака, достаточно настроить fail2ban.
xmoonlight, либо пусть ссылаются на рецензированные научные статьи по теме, либо в пусть идут в сад со своими выдумками. Но при этом, я бы хотел иметь перечень имен и компаний - для пополнения стоп листа.
xmoonlight, соленый хэш + злобная функция, которую тяжело считать, вроде bcrypt, практически закрывают эту проблему.
То есть, если мы говорим о подборе пароля "снаружи" сервиса - это очевидно легко детектируется и забанивается вместе с перебирающим.
Если же мы говорим о взломе сервера и угоне хэшей - если хэшей не будет совсем, злоумышленник получит все пароли сразу. Даже просто засунутые в md5 пароли уже потребуют от него минимальной квалификации, а сделанные "правильно (соль + злая функция)" - практически лишат шансов на успех.
Объективно, небольшой джиттер можно обнаружить только при помощи измерений и сличения с эталоном.