2015-09-10 2 views
1

Я пытаюсь внедрить более сильный механизм хэширования/хранения пароля и выбирать самый простой подход: password_hash() и password_verify().Определите, был ли пароль ранее использован при реализации случайных солей

Я разрешаю PHP генерировать случайную соль, как рекомендовано, и все это имеет смысл. Кроме того, часть политики «надежного пароля», которую мне нужно реализовать, заключается в том, чтобы отклонить пользователя от повторного использования ранее использованного пароля. Теоретически я мог бы реализовать это, сохранив архив хешированных паролей. Когда пользователь меняет свой пароль, мы проверяем новый хэш на архив хешей. Если есть совпадение, мы знаем, что пароль был ранее использован и отклонил его. Однако внедрение случайной соли, в то время как значительно более безопасное, эффективно делает этот хеш-пароль для архива бесполезным.

Итак, мой вопрос заключается в том, как реализовать эту политику паролей при использовании случайных солей? Конечно, кто-то другой столкнулся с этой проблемой.

+1

Почему бы не сохранить случайную соль вместе с сгенерированным паролем в базе данных, чтобы вы могли проверить его на соответствие в будущем? – Maximus2012

+0

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

+0

Feck, просто сохраните простой текстовый пароль :-) –

ответ

2

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

Чтобы проверить наличие хеша с солью, вам нужны как хэш, так и его соль, они должны храниться вместе. Функция password_hash() будет включать соль в полученном хеш-значении, поэтому вам не нужно заботиться о сохранении соли самостоятельно.

$2y$10$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa 
| | |      | 
| | |      hash-value = K0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa 
| | | 
| | salt = nOUIs5kJ7naTuTFkBy1veu (22 characters) 
| | 
| cost-factor = 10 = 2^10 iterations 
| 
hash-algorithm = 2y = BCrypt 

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

+0

По существу, запустите password_verify() с новым (предлагаемым) паролем пользователя против каждого хэша в архиве для этого пользователя. До тех пор, пока каждый результат password_verify() возвращается как false, мы знаем, что пароль не соответствует? –

+0

@JeffWalden - Да, так мы можем безопасно хранить список старых паролей. – martinstoeckli

Смежные вопросы