Что следует хранить в таблице при использовании bcrypt
Я шел через Эта статья и нашел следующий формат хэша, который возвращается, пока мы используем bcrypt. Я обнаружил, что этот хэш должен храниться в базе данных (в формате varchar (60) или около того) и использоваться, когда требуется какая-либо аутентификация пользователя.
Я сомневаюсь, что если моя база данных будет скомпрометирована, злоумышленник уже будет знать алгоритм, стоимость и соль, которую я использую, что сделает его работу очень легкой. Я так думаю, потому что теперь ему даже не нужно угадывать алгоритм (bcrypt, SHA, MD5 и т. Д.), Который он должен использовать, чтобы получить пароль пользователя методом грубой силы.
Вместо этого я чувствую, что должен использовать только последнюю часть (часть после последнего $) и добавить другую часть в мой скрипт перед тем, как сопоставление будет таким
<?php
$options = array('cost' => 11);
echo password_hash("akki", PASSWORD_BCRYPT, $options)."\n";
// $2y$11$mrblnrK01GWt4g55.Z8Zs.1RslouNzBqCVW826QfBEuaRaVyq96c2
?>
Я могу хранить mrblnrK01GWt4g55.Z8Zs.1RslouNzBqCVW826QfBEuaRaVyq96c2 часть в базе данных
Чтобы проверить предоставленный пользователем пароль по существующему хешу, я могу использовать следующую функцию:
<?php
// Query the db to get $hash.
$hash = 'mrblnrK01GWt4g55.Z8Zs.1RslouNzBqCVW826QfBEuaRaVyq96c2';
$hash = '$2y$11$'.$hash;
if (password_verify('akki', $hash)) {
echo 'Password is valid!';
} else {
echo 'Invalid password.';
}
?>
Я нашел похожий вопрос Вот но это не говорит о том, почему показ алгоритма (и стоимости) не является риском, хотя я понимаю, почему раскрытие соли не является проблемой. Также причина, по которой это может помочь, когда я пытаюсь изменить свой алгоритм или стоимость, кажется, не стоит риска.
Решение
почему показ алгоритма (и стоимости) не является риском
Потому что перебор все равно будет практически невозможен. Нет значимого увеличения риска. Даже зная алгоритм и стоимость, это займет много много лет за пароль.
Единственное, что вы делаете, не сохраняя эту информацию, усложняет модернизацию алгоритма и / или увеличивает стоимость на более поздний срок. Эти вещи нужно модернизировать, так как в игру вступают такие вещи, как более мощное оборудование, новые методы атаки и более сильные алгоритмы.
Практически для большинства целей нужно, чтобы время, необходимое для вычисления одного хеша, составляло примерно 0,3-0,5 секунды.
Все, что вы делаете для усложнения апгрейда и перефразировки, снижает вероятность того, что это произойдет. Это то, что представляет риск.
Что вы делаете, когда эффективный путь атаки появляется против используемой вами хеш-функции?
Это не теоретически. Многие люди были довольны SHA1, пока не появились атаки с ускорением на GPU.
Если вы храните всю строку, тривиально пропустить ее password_needs_rehash() когда пользователь входит в систему и перефразирует пароль при необходимости.
Если вы разделили индикаторы алгоритма и опций и жестко их запрограммировали — как вы обновитесь *? Простое их изменение означает, что никто со старым хешем не может войти в систему. И вы не можете сгенерировать новый хеш до тех пор пользователь входит в систему, так что вам нужно поддерживать это отображение алгоритма + опции где-то в хеши …
Где-то вроде базы данных.
Сохраните всю строку.
* Если вы не обновляете и вместо этого полагаетесь на безопасность через неизвестность, тогда злоумышленнику нужно только определить метод, который вы использовали один раз чтобы все было открыто. Я даже не собираюсь рассматривать это как вариант.
Другие решения
Других решений пока нет …