Предположим, вы можете решить, как хешированные пароли должны храниться в СУБД. Есть ли очевидные недостатки в схеме, подобной этой?

Чтобы создать хеш-значение, хранящееся в СУБД, возьмите:

A value that is unique to the DBMS server instance as part of the salt, And the username as a second part of the salt, And create the concatenation of the salt with the actual password, And hash the whole string using the SHA-256 algorithm, And store the result in the DBMS.

Это будет означать, что любой, кто хочет столкнуться с коллизией, должен будет выполнить работу отдельно для каждого имени пользователя и каждого экземпляра сервера СУБД в отдельности. Я планирую сохранить фактический механизм хеширования в некоторой степени гибким, чтобы можно было использовать новыеNIST стандартный алгоритм хеширования (SHA-3) это все еще продолжается.

«Значение, которое является уникальным для экземпляра сервера СУБД» не должно быть секретным - хотя это не будет разглашено случайно. Цель состоит в том, чтобы гарантировать, что если кто-то использует один и тот же пароль в разных экземплярах сервера СУБД, записанные хэши будут отличаться. Кроме того, имя пользователя не будет секретным - только пароль.

Будет ли какое-либо преимущество в том, чтобы сначала иметь пароль, а также имя пользователя и «уникальное значение»? во-вторых, или любая другая перестановка из трех источников данных? Или как насчет чередования строк?

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

Есть довольно много связанных вопросов SO - этот список вряд ли будет исчерпывающим:

Encrypting/Hashing plain text passwords in database Secure hash and salt for PHP passwords The necessity of hiding the salt for a hash Clients-side MD5 hash with time salt Simple password encryption Salt generation and Open Source software Password hashes: fixed-length binary fields or single string field?

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