Вопрос по database, passwords – Лучший способ сохранить пароль в базе данных [закрыто]

424

Я работаю над проектом, который должен иметь аутентификацию (имя пользователя и пароль)

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

Я использую C # и подключаюсь к экспресс-серверу 2008 года. Может ли кто-нибудь предложить (используя как можно больше примеров), как лучше всего хранить данные такого типа?

P.S Я открыт для идеи, что эта информация не будет храниться в базе данных, если есть веские основания.

Лучше придерживаться стандартов - смотритеen.wikipedia.org/wiki/PBKDF2 Вам нужно только найти реализацию на вашем языке Boris Treukhov
Что бы вы ни делали, если вы используете шифрование, не храните ключ в коде, как упоминалось ранее. Это просто плохая практика. Woody
«Как правильно делать пароли?» это жизненно важный вопрос. Это сложная проблема, и ошибки имеют серьезные последствия (вспомните, что случилось с Tesco и LinkedIn). Я думаю, что этот вопрос должен быть вновь открыт вprogrammers.stackexchange.com Colonel Panic
На этот вопрос широко отвечают на форуме безопасности:security.stackexchange.com/questions/211/… gioele

Ваш Ответ

8   ответов
3

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

Все было построено для этих целей, проверьтечленство в asp.net

26

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

Таким образом (практически) невозможно получить незашифрованный пароль.

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
6

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

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

Это может не подойти, если рассматриваемое приложение предназначено исключительно для внутреннего использования.

RPX предоставляет хороший простой способ интегрировать поддержку OpenID в приложение.

Error: User Rate Limit Exceeded Crash893
10

Я настоятельно рекомендую прочитать статьи.Достаточно таблиц Rainbow: что нужно знать о безопасных схемах паролей [мертвая ссылка,копия в интернет архиве] а такжеКак безопасно хранить пароль.

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

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceededcodahale.com/how-to-safely-store-a-password
47

Background Вы никогда ... действительно ... не должны знать пароль пользователя. Вы просто хотите убедиться, что входящий пользователь знает пароль для учетной записи.

Hash It: Храните хэши паролей пользователей (одностороннее шифрование) с помощью сильной хэш-функции. Поиск & quot; c # зашифрованных паролей & quot; дает множество примеров.

Увидетьонлайн создатель хеша SHA1 для понимания того, что создает хеш-функция (но не используйте SHA1 в качестве хеш-функции, используйте что-то более сильное, например SHA256).

Теперь хешированные пароли означают, что вы (и воры базы данных) не сможете вернуть этот хэш обратно в исходный пароль.

How to use it: Но, вы говорите, как я могу использовать этот пароль, хранящийся в базе данных?

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

Итак, сравните два хешированных пароля (хэш базы данных для имени пользователя и введенный хешированный пароль). Вы можете сказать, "набрали ли они" в & quot; соответствует тому, что "первоначальный пользователь ввел для своего пароля"; сравнивая их хэши.

Extra credit:

Question: Если бы у меня была ваша база данных, то я не мог бы просто взять взломщик, такой как Джон Потрошитель, и начать делать хэши, пока не найду совпадения с вашими хешированными паролями? (так как пользователи выбирают короткие словарные слова в любом случае ... это должно быть легко)

Answer: Да ... да, они могут.

Таким образом, вы должны «соль» ваши пароли. УвидетьСтатья в Википедии о соли

Увидеть& quot; Как хэшировать данные с солью & quot; C # пример

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
2

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

Error: User Rate Limit Exceededmscs.dal.ca/~selinger/md5collision
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
370

Вы правы в том, что хранение пароля в текстовом поле являетсяhorrible идея. Тем не мение,as far as location goesв большинстве случаев, с которыми вы столкнетесь (и я, честно говоря, не могу придумать никаких контрпримеров), сохраняющихrepresentation пароль в базе данных это правильная вещь. Под представлением я подразумеваю, что вы хотите хэшировать пароль, используя соль (которая должна быть разной для каждого пользователя) и безопасный односторонний алгоритм и хранилищеthat, выбрасывая оригинальный пароль. Затем, когда вы хотите проверить пароль, вы хэшируете значение (используя тот же алгоритм хэширования и соль) и сравниваете его с хешированным значением в базе данных.

Итак, хотя вы думаете об этом хорошо, и это хороший вопрос, на самом деле это дубликат этих вопросов (по крайней мере):

Чтобы прояснить немного подробнее о соли, опасность простого хеширования пароля и его сохранения заключается в том, что если нарушитель захватит вашу базу данных, он все равно может использовать то, что известно какрадуга столы быть в состоянии "расшифровать" пароль (по крайней мере, те, которые отображаются в радужной таблице). Чтобы обойти это, разработчики добавляютповаренная соль к паролям, которые, если все сделано правильно, делают атаки типа «радуга» просто невозможными. Обратите внимание, что распространенным заблуждением является просто добавление одинаковой и длинной строки ко всем паролям; пока это неhorribleЛучше всего добавлять уникальные соли для каждого пароля.Прочитайте это для большего.

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
31

В качестве закаленного ключа хеш-кода с использованием безопасного алгоритма, такого как sha-512.

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceededsecurity.stackexchange.com/questions/211/…Error: User Rate Limit Exceeded

Похожие вопросы