Как правильно хранить пароли *?

Question

Статья , на которую я наткнулся здесь, в SO, предоставила ссылки на другие статьи , которые в свою очередь предоставили ссылки на еще больше статей и т.д.

И, в конце концов, я остался совершенно в тупике - так какой же лучший способ хранения паролей в БД? Из того, что я могу собрать, вы должны:

• Используйте длинную (не менее 128 полностью случайных битов) соль, которая хранится в открытом тексте рядом с паролем;
• Используйте несколько итераций SHA-256 (или даже более высокий уровень SHA) для посоленного пароля.

Но ... чем больше я читаю о криптографии, тем больше понимаю, что на самом деле ничего не понимаю, и что то, что я считал правдой в течение многих лет, на самом деле совершенно неверно. Здесь есть специалисты по этому вопросу?

Добавлено: Кажется, что некоторые люди упускают суть. Я повторяю последнюю ссылку, приведенную выше. Это должно прояснить мои опасения.

https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2007/july/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/

Answer 1

Вы правильно поняли. Всего два предложения:

1. Если однажды SHA1 станет слишком слабым, и вы захотите использовать что-то другое, то невозможно восстановить старые пароли и перефразировать их по новой схеме. По этой причине я предлагаю прикрепить к каждому паролю номер «версии», который говорит вам, какую схему вы использовали (длина соли, какой хэш, сколько раз). Если в один прекрасный день вам нужно перейти с SHA на что-то более сильное, вы можете создавать пароли нового стиля, сохраняя при этом пароли старого стиля в базе данных, и при этом различать их отдельно. Мигрировать пользователей по новой схеме будет проще.

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

Редактировать: Оказывается, bcrypt превзошел меня в идее № 1. Сохраненная информация - это (стоимость, соль, хеш), где стоимость - это сколько раз хэширование было выполнено. Похоже, bcrypt сделал что-то правильно. Увеличение количества раз, которое вы хэшируете, может быть выполнено без вмешательства пользователя.

Answer 2

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

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

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

Answer 3

Использование:

1. Хранение хешированного пароля
2. 128+-битная соль уровня пользователя, случайная, регенерированная (т. Е. Вы создаете новые соли, когда вы делаете новые хэши паролей, вы не всегда сохраняете ту же соль для данного пользователя)
3. Сильный вычислительно дорогой метод хеширования
4. Методология, которая несколько отличается (алгоритм хеширования, сколько итераций хэширования, в каком порядке объединяются соли, что-то ) как от любых «стандартных руководств по реализации», подобных этим, так и от любого другого пароля реализация хранилища, которую вы написали

Answer 4

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

Answer 5

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

Answer 6

Я думаю, что никакой дополнительной итерации по паролю не требуется, просто убедитесь, что есть соль и более сложная;) Я лично использую SHA-1 в сочетании с 2 солевыми ключевыми фразами.