Кража хэша пароля из базы данных учеток равнозначана знанию пароля?
Рассмотрим случай использования подсоленного хэша от пароля.
Очевидно, что после того, как юзер создал аккаунт, в базе данных создалась некая запись о нем, при этом, на сервере будет сохранен не сам пароль, а подсоленный хэш от пользовательского пароля, например, в таком формате: salt:hash
Пусть, H() - используемая функция хэширования. Тогда значение подсоленного хэша: hash = H(password + salt)
Как осуществляется проверка пароля? Зависит от конкретной реализации протокола аутентификации, но, если используется метод аутентификации "вызов-ответ", то упрощенно процесс выглядит следующим образом (для примера предположим, что логин пользователя login1, а значение подсоленного хэша: salt1:hash1):
1. Клиент посылает серверу пару: (login1, random), где random — псевдослучайное, каждый раз новое число.
2. В ответ сервер посылает значение salt.
3. Клиент вычисляет client_side_hash = H(random, H(password + salt)) и отправляет его на сервер.
4. Сервер пароля пользователя не знает, но ему известно значение подсоленнго хэша от этого пароля, в нашем привере - это salt1:hash1.
поэтому сервер вычисляет хэш так: server_side_hash = H(random, hash1) и
5. Сервер сравнивает client_side_hash и server_side_hash. Если они совпадают — аутентификация успешна.
Допустим, злоумышленник через SQLi получил запись login1:salt1:hash1 из базы данных учеток.
Зачем ему брутфорсить пароль от подсоленного хэша? Только, если злоумышленник предополгает, что данный пароль используется пользователем и в других веб-прилоежниях.
Знания salt1:hash1 достаточно, чтобы успешно пройти аутентификацию в данном веб-приложении! Или я ошибаюсь?
Но тогда для хакера возникает вторая задача, которая может быть сформулирована так: изменить client side логику(js скрипт и ajax запросы) таким образом, чтобы не вычислять хэш от пароля, а сразу использовать значение подсоленного хэша. Задача тривиальна. Ее можно решить, например, написав своего клиента и использовать его вместо браузера. Либо использовать прокси, например, burp suite, для вычисления и подмены значений, отправляемых во время аутентификации.
Кража хэша пароля из базы данных учеток равнозначана знанию пароля?
Нет.
Знания salt1:hash1 достаточно, чтобы успешно пройти аутентификацию в данном веб-приложении!
Разумеется нет.
Общая схема такая - пользователь знает пароль, сервер хранит хэш этого пароля.
Для аутентификации пользователь отправляет серверу пароль, сервер его хэширует и сверяет получившийся хэш с тем что хранится в базе, если они совпадают - пользователь аутентифицирован.
Соль используется для затруднения брутафорса при массовой утечке хэшей.
В случае с солью -
Пользователь знает пароль, сервер хранит хэш подсоленого пароля и хэш.
Пользователь отправляет серверу пароль, сервер достает из базы данных соль, добавляет ее к паролю и хэширует получившуюся смесь.
Если получившийся хэш совпадает с тем что хранится в базе - пользователь аутентифицирован.
Если злоумышленник знает хэш - это ему ничего не дает.
На сервер для аутентификации нужно отправить пароль иначе ничего не получится.
Собственно для этого и был придуман метод аутентификации challenge-response, чтобы передавать не сам секрет, а косвенную информацию о секрете, которую обе стороны могут проверить. Но тогда, хранимый в бд хэш позволяет воссоздать необходимый для успешной аутентификации ответ клиента.
FeRViD: Передача пароля является необходимостью, на этом построена собственно парольная аутентификация. Ее невозможно избежать.
И никакие правила хорошего тона тут ни при чем.
Нет передачи пароля - нет парольной аутентификации, только и всего.
А уж как там вы его передаете - дело третье.
Средний
Средний
Средний
Средний
