Хранить метаданные о паролях в базе данных?

Question

Я разговаривал с моим другом, и он заявил, что для хранения пользовательских паролей в базе данных он и я цитируем:

1. Принимает пароль пользователя
2. Хэши со случайной солью
3. Затем он добавляет префикс результата # 2 к типу хеша и соли, соединяя их со строкой, разделенной символом трубы. (например, SHA1 | RANDOMSALT | afde4343 ....)
4. Сохраняет результат # 3 в БД

Он утверждает, что это читабельно, поскольку он "может мгновенно узнать", какой тип хэш-дайджеста используется.

Я не думаю, что когда-либо видел это раньше, но я ищу причины того, почему это было бы плохо, помимо факта, что неавторизованный пользователь может мгновенно узнать, какой тип хэша используется для шифрования пароли и дополнительное место, необходимое для хранения поля.

Моя внутренняя реакция заключается в том, что такой подход к работе с паролями глуп, поскольку любые признаки, помогающие злоумышленнику взломать пароли, являются слабым местом. Какие еще причины я должен использовать, чтобы убедить его, что это плохая идея?

Спасибо!

Answer 1

Это хорошая идея. Все так делают, в том числе в файле /etc/password (/etc/shadow ...) в системах Unix.

Любая приличная модель безопасности предполагает, что злоумышленник знает, какая хеш-функция используется, хотя бы потому, что хеш-система представляет собой часть программного обеспечения, хранящуюся на жестком диске. И наоборот, вера в то, что не объявляется, какая хеш-функция используется, сродни безопасности через неизвестность , и это плохо.

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

PS: это не шифрование пароля, это хеширование пароля. Хеширование не является разновидностью шифрования.

Answer 2

Хорошей практикой также является сохранение «стоимости» хэша (сколько раз хэш был растянут ), даже crypt() делает это. Возможно, худшая проблема заключается в том, что вам сначала нужно запросить базу данных (чтобы узнать соль, стоимость, алгоритм), а затем проверить по сгенерированному хешу, для этого требуется дополнительная поездка в БД.

Почему это хорошая практика? Что ж, если у вас есть специфичные для пользователя соли, их нужно где-то хранить ... Кроме того, вы можете (в будущем) захотеть увеличить стоимость (количество раз, когда хеш "повторно хэшируется") ваших хешей до следуйте закону Мура, если вы не знаете первоначальной стоимости, вы ничего не сможете сделать.

Я настоятельно рекомендую вам прочитать этот пост в блоге о (безопасном) хешировании пароля .