Ніколи не слід уникати, обрізати чи використовувати будь-який інший механізм очищення паролів, які ви стикаєте з 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 .