я не могу войти с помощью password_verify в MVC [duplicate]

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

Вы будете спорить (и вы видите это в каждом сообщении, в котором пользовательские данные принимаются для использования в ваших системах), что мы должны очищать все пользовательские данные, и вы были бы правы для любую другую информацию, которую мы принимаем от наших пользователей. Пароли разные. Хэшированные пароли не могут предложить угрозу 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 &quot;dessert topping&quot; &amp; a &lt;floor wax&gt;!     " // double quotes, ampersand and braces have been changed
string(65) "I'm a &quot;dessert topping&quot; &amp; a &lt;floor wax&gt;!     " // 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 .