Что произойдет, так это то, что новые хэшированные пароли будут использовать новый алгоритм - очевидно.
Однако вы не должны беспокоиться об этом, потому что все это связано с передовой совместимостью - ваш код не будет разбит, если алгоритм по умолчанию изменится, если вы используете password_*()
правильно функционирует.
Правильно, я имею в виду использование password_verify()
.
password_verify()
принимает пароль с открытым текстом и хэш, и он может легко определить, какой алгоритм используется, просматривая хэш, который вы его кормите. Поэтому он все равно сможет проверить пароль, который был хэширован с использованием старого алгоритма - не только предыдущего, но и любого поддерживаемого алгоритма.
Фактически единственной целью константы PASSWORD_DEFAULT
является то, что вы можете легко перенести старые хэши в новый алгоритм (после добавления). Это происходит следующим образом:
- Когда пользователь входит в систему, вы проверить свой пароль через
password_verify()
(любой алгоритм хэширования, который имеет постоянную PASSWORD_<name>
будет работать).
- Вы вызываете
password_needs_rehash()
, и если только что подтвержденный пароль использует старый алгоритм (или более низкий параметр «cost»), он вернет логический TRUE.
- Если логическое TRUE действительно было возвращено, теперь вы можете заменить старый хэш на тот, который использует новый алгоритм; вы можете сделать это во время входа в систему, потому что пользователь только что дал вам пароль и, вы подтвердили, что это правильно.
В целом - это действительно, действительно хорошо продуманные API и он решает проблемы для вас, что вы даже не думали о. Не беспокойтесь об этом.
Edit (отмечено в комментариях):
Следует, однако, отметить, что новые алгоритмы будут достаточно probly привести к большей длине хэша, так что если вы храните пароли в базе данных - не ограничьте длину поля (т. е. используйте поле varchar(255)
).
Спасибо. Это было полезно. – Ambitions
Добро пожаловать.: :) – Narf
Существует одна действительно важная разница, которая может привести к тому, что некоторые новые хэши не будут проверяться. Поскольку мы не знаем, какие алгоритмы будут использоваться в будущем, это может означать, что длина хэша может измениться. Вот почему руководство рекомендует использовать 'VARCHAR (255)' для хранения хэшей, хотя максимальная длина хэширования bcrypt составляет ~ 55 символов. – Mike