Утечка данных покупателей магазинов re:Store, Samsung, Sony Centre, Nike, LEGO и Street Beat

[@Foreglance]

Разве кто-то до сих пор хранит пароли на серверах — не хэши?

[@Protos]

Это логи

[@hunroll]

А это разве оправдывает использование паролей в чистом виде? Что мешает посчитать хеш на клиенте чтобы это никуда не попало?

[@freeExec]

Никто не хеширует пароли на стороне клиента.

[@ivanrt]

Атакующий пошлет сразу правильный хэш. Это не отменяет того что в логах пароли должны или врезаться или заменяться с помощью односторонней функции

[@freeExec]

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

[@ivanrt]

Плюсы есть, хотя весьма сомнительные — если кто-то может перехватить пароль или хэш пароля, то это уже серьёзная проблема. К тому-же хэш будет или без соли или с солью с сервера, а это усложнение протокола с весьма сомнительным выигрышем.

[@Protos]

Не оправдывает наличие конфи в логах да ещё и анализ их в левом ПО. Хэшировать пароли на клиенте ещё глупее занятие, особенно бесит аутентификации по ntlm хэшу, когда достаточно его перехватить и пароль далее не надо знать

[@hunroll]

когда достаточно его перехватить и пароль далее не надо знать

Ну так если мы перехватываем пакет авторизации — то там будет пароль в чистом виде. И перехватчику уже побоку сайт Сони или Найка или кого-то там ещё, он пойдёт вставлять этот пароль в более интересные учётки.
Я не троллю, просто не понимаю, как отправка пароля по сети в чистом виде может быть безопаснее? Как сейчас принято делать «по-уму»?

[@Revertis]

Обычно надеются на HTTPS.

[@KarimSI]

Если считать хэш на клиенте, это будет означать что сервер начинает принимать хэш вместо пароля для авторизации. При утечке базы с хэшами паролей теперь у злоумышленника будет доступ ко всем аккаунтам. Если же сервер принимает только пароли и сам считает хэш, утечка базы с хэшами паролей становится чуть менее страшной.

А с точки зрения перехвата не вижу разницы, слать с клиента пароль или хэш, если и того и другого будет достаточно для авторизации на сервере.

[@onlinehead]

При утечке базы с хэшами паролей теперь у злоумышленника будет доступ ко всем аккаунтам
А при утечке базы с plain text паролями разве не будет?
Кажется логичнее все таки хранить солёные хэши в базе, считать их можно от чистого пароля или от хэша на клиенте. По крайней мере в таком случае оно хотя бы по таблицам искаться не будет в случае утечки.

[@KarimSI]

В базе всегда храним только хэши. Об этом даже речи не идет.
Мой комментарий отвечал на вопрос, где считать хэш — на сервере или клиенте, и в чем разница.

[@Samver]

Надо обязательно солить хэши.
Считать и солить надо на сервере, иначе толку от соли не будет.
Все что происходит на клиенте, можно исследовать, в том числе момент соления.

[@ashotog]

разумеется хранит. я постоянно пишу про это в статьях на Хабре.

[@alexesDev]

Потому что за базы следователь может пригласить?

[@bestie]

Могу лишь предположить, что за выкладывание таких баз, вполне себе, возможно наказание. И возможно, не только денежное.
А вот показать потенциальные проблемы при использовании подобных сервисов не только ненаказуемо, а даже полезно. При том, что владелец исходного ресурса уже уведомлен и исправил проблему на своей стороне.

[@Kellis]

Так есть где база, можно где-то проверить себя?