Information Security
IT Infrastructure
Database Administration
Comments 21
+2
Никогда такого не было и вот...
А если серьёзно, то:
«Для доступа в систему необходимо перейти по следующей ссылке: xyz.ru
В поле Логин введите: xxxxx
Ваш пароль для доступа в систему: yyyyy»
Письмо от одного из ведущих вендоров телеком железок и потребительской электроники, при восстановлении/плановом обновлении пароля для доступа к некоторым сервисам.
А вы тут про магазины.

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

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

0
Так то да, но атакующий не узнает исходного пароля, и в другом месте, если там другая хеш-функция, не сможет воспользоваться. Так что плюсы а таком подходе есть.
0
Плюсы есть, хотя весьма сомнительные — если кто-то может перехватить пароль или хэш пароля, то это уже серьёзная проблема. К тому-же хэш будет или без соли или с солью с сервера, а это усложнение протокола с весьма сомнительным выигрышем.
+1

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

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

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

А с точки зрения перехвата не вижу разницы, слать с клиента пароль или хэш, если и того и другого будет достаточно для авторизации на сервере.
0
При утечке базы с хэшами паролей теперь у злоумышленника будет доступ ко всем аккаунтам
А при утечке базы с plain text паролями разве не будет?
Кажется логичнее все таки хранить солёные хэши в базе, считать их можно от чистого пароля или от хэша на клиенте. По крайней мере в таком случае оно хотя бы по таблицам искаться не будет в случае утечки.
0
В базе всегда храним только хэши. Об этом даже речи не идет.
Мой комментарий отвечал на вопрос, где считать хэш — на сервере или клиенте, и в чем разница.
0
Надо обязательно солить хэши.
Считать и солить надо на сервере, иначе толку от соли не будет.
Все что происходит на клиенте, можно исследовать, в том числе момент соления.
+2
разумеется хранит. я постоянно пишу про это в статьях на Хабре.
UFO landed and left these words here
UFO landed and left these words here
+4
Могу лишь предположить, что за выкладывание таких баз, вполне себе, возможно наказание. И возможно, не только денежное.
А вот показать потенциальные проблемы при использовании подобных сервисов не только ненаказуемо, а даже полезно. При том, что владелец исходного ресурса уже уведомлен и исправил проблему на своей стороне.
Only those users with full accounts are able to leave comments.  , please.