password_hash -- глюк или есть объяснение?

Прыуэт.

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

Работает:

$options = [
'cost' => 12,
];
echo password_hash("norocos068281969", PASSWORD_DEFAULT, $options);

Работает, но больше минуты:

echo password_hash("norocos068281969", PASSWORD_DEFAULT, ['cost' => 20]);
============

Какое можете дать этому объяснение? Спасибо.

Вкратце - это "стоимость" ресурсов затрачиваемых на генерацию хеша. Или алгоритмические расходы, если хотите. Значение по умолчанию (10) - вполне приемлемое, но при необходимости и имея мощный сервер, вы можете увеличить это значение.

-----
Чем больше узнаю, тем больше я не знаю.

Один из основных способов защиты от нахождения пароля методом перебора - повышение вычислительных затрат на расчет хеша. По-этому, нельзя использовать для хеширования пароля всякие sha1, hash('sha256') и т.п. Еще в 90-х годах, когда был придуман crypt_md5, там делалось тысячу итераций md5. Сейчас это считается ненадежным. Поскольку вычислительные мощности растут, что бы постоянно не внедрять новые алгоритмы - придумали дать возможность задавать число итераций при создании хеша. Например, в случае crypt_blowfish изменение числа на единицу увеличивает время расчета в два раза. Я бы рекоменовал выбирать значение, что бы время расчета на сервере составляло 0.2-0.5 секунды.

-----
self-banned

DelphinPRO

спс за разъяснение.
убрал cost и всё пашет по-быстроляну )
==========
Только не понятно, про какие ресурсы идет речь? Если проц или оперативка, то на момент выполнения скрипта, они НЕ работают на 100%

(Отредактировано автором: 20 Января, 2016 - 12:25:38)

MiksIr расписал более подробно.
(Добавление)
Речь идет о вычислительной скорости.
Чтобы пароль нельзя было подобрать перебором (в разумные сроки), алгоритм должен быть медленным. Грубо говоря, cost "замедляет" алгоритм, если так понятнее.

(Отредактировано автором: 20 Января, 2016 - 13:25:55)

-----
Чем больше узнаю, тем больше я не знаю.

Проц. Должен работать на 100%, но только одно из ядер (ибо один процесс). Если у вас загрузка показывается суммарная по ядрам, то будет не 100%. Оперативка тоже, но в менее заметной степени по сравнению со скриптами, так что можете и не увидеть.

(Отредактировано автором: 20 Января, 2016 - 18:56:25)

-----
self-banned

спс, за ответы.
==========

Но вот снова непонятка:

ф-ия password_verify(), начинает также медленно проверять соответствие пароля около 1 минуты.

в документации написано:




в ответе выше, я говорил, что в password_hash, я cost вообще не ставил.

Так какого хэ password_verify так медленно работает?
==============

стало понятно, тот хэш был создан при косте 20, поэтому он и проверяет так долго.

Но тут ещё такая хрень появилась, пароль зашифрованный при помощи password_hash(), содержащий точку, например:

$2y$10$aRtwfqiCIpWAtn0Ab2Y.Gu3mezS7l3OME7GhaNWD2sZccV6fxWqdS

при проверке выдает:

Undefined variable: aRtwfqiCIpWAtn0Ab2Y in C:\wamp\www\test.php on line 3

и естественно false

Почему?

(Отредактировано автором: 25 Января, 2016 - 13:28:37)

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


PHP решил что $aRtwfqiCIpWAtn0Ab2Y - переменная, Вы случайно хеш без экранирования куском текста(кода) не вставили?

TuX560

возможно при тестировании и разбирании данных функций я так и поступил когда-то. Сейчас проэкранировал \$aRtwf и все трушно )

спс, плюсую +
(Добавление)
как оказалось я так не поступал, зарегил нового пользователя и по новой

$2y$10$zBTlziLKhlfaPYYYq9uOZeyrOZwpTM/K9XCnIALQmIuTXj1slzBg6

Undefined variable: zBTlziLKhlfaPYYYq9uOZeyrOZwpTM



хм, а по другому никак, ведь при вставке в БД(с учетом препарированного запроса), данный хэш и вставляется как строка, без всякого экранирования. А как иначе?

Вот именно как строка, а у Вас он воспринимается как код на php, покажите исходники.