Подтвердить что ты не робот

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

статья, на которую я наткнулся здесь, в 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/

4b9b3361

ОТВЕТЫ

Ответ 1

У тебя все получилось. Только два предложения:

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

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

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

Ответ 2

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

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

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

Ответ 3

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

  • Хранение паролей хранения
  • 128-битная соль на уровне пользователя, случайная, регенерированная (т.е. вы создаете новые соли при создании новых хэшей паролей, вы не настойчиво сохраняете одну и ту же соль для данного пользователя).
  • Сильный, дорогостоящий метод хеширования
  • Методология, которая несколько отличается (алгоритм хеширования, сколько итераций хеширования вы используете, какой порядок объединяют соли, что-то) от любых "стандартных руководств по реализации", подобных этим, и от любой другой реализации хранилища паролей, которую вы написали

Ответ 4

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

Ответ 5

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

Ответ 6

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