Хеширование пароля на стороне клиента в браузере: есть резон?

MD5 - довольно простой и хорошо задокументированный алгоритм, самому написать функцию хеширования на любом языке не составит труда. Но, вы правы, главный вопрос - нужно ли? Все равно однажды (при регистрации) вам придется отправить пароль в чистом виде, чтобы проконтролировать его сложность и прочее, не вижу смысла изощряться.

Насколько помню, на форумах у забугорного вебмастерского сообщества digitalpoint.com пароли перед отправкой на сервер хешировались (хешируются).

Так что, наверно, какой-то смысл в этом есть.

А поповоду проверки сложности - что мешает её сделать на клиенте?

Ну а так - если хеширование - это защита от перехвата траффика - то посмотрите в сторону https.

Ну есть тут некое рациональное зерно, но не при хэшировании, а при шифровании. Таким образом можно защититься от перехвата пользовательских паролей.

А какие вы цели преследуете хешированием? Ну, ясно что безопасность. Конкретнее, от каких атак защищаетесь?

Вы дыру этим самым делаете в безопасности. С размеров с Луну.

md5 и другие методы хэширования в чистом виде для хранения паролей это дыра. Всегда используется пароль+соль, и даже соль1+пароль+соль2.

А вы хотите без соли хэшировать? Дыг сольют вашу базу и вот они все пароли всех юзерей.

А если с солью, то что? Тоже её передавать в javascript? Ну и какой смысл тогда в ней? Опять дыра.

LEOnidUKG, от MITM может помочь.

Да на стороне юзера хоть пусть все вирусы мира сидят и перехватывают данные. Важнее безопасность остальных на сервере и их данных. Если у одного проблемы, это не должно касаться других. Если перехватывать, то перехватят куки и всю сессию, пароль нафиг никому не сдался.

Все нормальные сервисы (и даже CMS) давно не шлют пароли в открытом виде, а дают юзерам задать их самостоятельно.

https - фиговый листик. Никому нафик не нужно снифить траф для получения паролей. Вернее да, есть куча любопытствующих соседей по вайваю в макдональдсах, но это можно сказать частный случай и забота юзера.

Коме того - тот же юзер может легко принять (и примет!) левый сертификат от роутера, который весь трафик (https в тч) будет читать без проблем.

А вот двухфакторная авторизация/енум/етс (если юзер захочет юзать) - это решение.

LEOnidUKG, допустим, кто-то взломал сайт и поставил скрипт, читающий $_POST. И при чём тут вирусы на клиенте? Пароли всех юзеров сайта у злоумышленника в кармане. А если будет приходить шифрованный пароль, то тут ещё повозиться придётся, просто так голый пароль уже не вытащишь.

Если взломали сайт, то слили уже базу и посмотрели соль. И пошли счастливые перебирать пароли. На ко хрен им какой-то post вставлять и считывать пароли?! Ну он может также и Ajax вставить и отправлять пароль при вводе символов.

А может ещё поле ввода заменить...

А может ещё...

А может...

А...