Вы никогда не должны избегать, обрезать или использовать какой-либо другой механизм очистки паролей, которые вы будете хешировать с помощью PHP, password_hash()по ряду причин, самая большая из которых заключается в том, что для дополнительной очистки пароля требуется ненужный дополнительный код.
Вы будете утверждать (и вы видите это в каждом посте, в котором пользовательские данные принимаются для использования в ваших системах), что мы должны очищать весь пользовательский ввод, и вы будете правы в отношении любой другой информации, которую мы принимаем от наших пользователей. Пароли разные. Хешированные пароли не могут представлять угрозу SQL-инъекций, потому что строка превращается в хэш перед сохранением в базе данных.
Хеширование пароля - это действие по обеспечению безопасности пароля для хранения в вашей базе данных. Хеш-функция не придает особого значения никаким байтам, поэтому по соображениям безопасности очистка входных данных не требуется.
Если вы следуете мантрам, разрешающим пользователям использовать пароли / фразы, которые они хотят, и вы не ограничиваете пароли , разрешая любую длину, любое количество пробелов и любые специальные символы, хеширование сделает пароль / кодовую фразу безопасным, независимо от того, что содержится в пароль. На данный момент наиболее распространенный хеш (по умолчанию) PASSWORD_BCRYPTпревращает пароль в строку шириной 60 символов, содержащую случайную соль вместе с хешированной информацией о пароле и стоимостью (алгоритмической стоимостью создания хеша):
PASSWORD_BCRYPT используется для создания новых хэшей паролей с использованием алгоритма CRYPT_BLOWFISH. Это всегда будет приводить к получению хэша в формате криптографии «$ 2y $», который всегда имеет ширину 60 символов.
Требования к пространству для хранения хэша могут меняться по мере добавления к функции различных методов хеширования, поэтому всегда лучше увеличивать тип столбца для сохраненного хеша, например VARCHAR(255)или TEXT.
Вы можете использовать полный запрос SQL в качестве пароля, и он будет хеширован, что сделает его невыполнимым механизмом SQL, например,
SELECT * FROM `users`;
Может быть хеширован $2y$10$1tOKcWUWBW5gBka04tGMO.BH7gs/qjAHZsC5wyG0zmI2C.KgaqU5G
Посмотрим, как различные методы очистки влияют на пароль -
Пароль I'm a "dessert topping" & a <floor wax>!(В конце пароля есть 5 пробелов, которые здесь не отображаются.)
Когда мы применяем следующие методы обрезки, мы получаем совершенно разные результаты:
var_dump(trim($_POST['upassword']));
var_dump(htmlentities($_POST['upassword']));
var_dump(htmlspecialchars($_POST['upassword']));
var_dump(addslashes($_POST['upassword']));
var_dump(strip_tags($_POST['upassword']));
Полученные результаты:
string(40) "I'm a "dessert topping" & a <floor wax>!" // spaces at the end are missing
string(65) "I'm a "dessert topping" & a <floor wax>! " // double quotes, ampersand and braces have been changed
string(65) "I'm a "dessert topping" & a <floor wax>! " // same here
string(48) "I\'m a \"dessert topping\" & a <floor wax>! " // escape characters have been added
string(34) "I'm a "dessert topping" & a ! " // looks like we have something missing
Что происходит, когда мы отправляем их password_hash()? Все они хешируются, как и запрос выше. Проблема возникает, когда вы пытаетесь проверить пароль. Если мы используем один или несколько из этих методов, мы должны повторно использовать их, прежде чем сравнивать их password_verify(). Следующее не получится:
password_verify($_POST['upassword'], $hashed_password); // where $hashed_password comes from a database query
Вам нужно будет запустить опубликованный пароль с помощью выбранного вами метода очистки, прежде чем использовать результат этого при проверке пароля. Это ненужный набор шагов, и он не сделает хэш лучше.
Используете версию PHP ниже 5.5? Вы можете использовать password_hash() пакет совместимости .
Вам действительно не следует использовать хэши паролей MD5 .