Прочитав руководство по password_hash
он выглядит в $aa$bb$
, bb
, кажется, стоит за «стоимость» алгоритма, используемого и aa
, кажется (по крайней мере в настоящее время) всегда 2y
.
Не будет ли часть $2y$10$
дать намек на то, что алгоритм был использован и сделать его проще для злоумышленника знать, что исходная строка была?
Да даст подсказку, но
- так делает весь остальной строки для многих функций (например, md5/sha1 хэш всегда будет состоять ровно 32/40 шестнадцатеричных символов).
- это не должно быть проблемой, потому что вы все равно не должны полагаться на обфускацию, а на сильный алгоритм (как правильно указывает аркаша в his comment).
$2y$10$
Почему используется?
Потому что кто-то думал, что это хорошая идея.
Может ли это измениться в будущем?
думаю.
Вторая часть уже изменена, и первая часть упоминается в the manual как the "$2y$" identifier
, но нет никакой гарантии, что никакой другой идентификатор не будет добавлен.
Итак, у меня в БД у меня есть пароли с $2y$10$
, а некоторые с $2y$25$
? и все будет работать плавно с помощью password_verify?
Посмотрите на examples in the manual - это уже так.
password_hash(..., PASSWORD_DEFAULT)
похоже, что создает префикс $2y$10$
, но password_hash(..., PASSWORD_BCRYPT, ['cost' => 12])
производит $2y$12$
.
Могу ли я просто сохранить строку после $2y$10$
и объединить ее в любое время, когда мне нужно работать с паролем?
Я бы посоветовал против этого.
Возможно, вы можете заставить его работать, и вы, возможно, даже не сможете его нарушить при любых изменениях, но если ваша единственная проблема заключается в том, что зашифрованная строка подсказывает используемый метод шифрования, лучшим вариантом было бы добавить дополнительный слой симметричного шифрование.
Например:
$password = password_hash("12345", PASSWORD_DEFAULT);
$key = pack('H*', md5('lorem').md5('ipsum')); // Must be 16, 24 or 32 bits
$secret = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $password, MCRYPT_MODE_ECB);
// Store $secret in the database
Таким образом, если злоумышленник не имеет исходный код, они не имеют возможности сказать, что означает, что зашифрованные данные, и если они имеют доступ к исходному коду, они могут просто взгляните на то, какое шифрование используется в любом случае.
Но опять же, даже если злоумышленник знает, что password_hash
и PASSWORD_DEFAULT
используются, они не могут его взломать.
Да, дается подсказка, но это не снижает безопасность. Уровень безопасности _not_ определяется обфускацией, а качеством алгоритма. – arkascha
Да, вот для чего. Не будет объективно облегчать хеширование трещин. Это самый распространенный алгоритм хэширования и растягивания, легко вывести из длины хэша даже без префикса. Хранение его по отдельности - это даже не безопасность по неизвестности, а просто бессмысленный код. (3) Да, для будущей совместимости с новыми алгоритмами в будущем. – mario