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

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

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

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

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

8 ответов


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

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

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


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

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

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

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

Как использовать: Но, скажете вы, как мне использовать этот размятый пароль, хранящийся в базе данных?

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

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

дополнительно:

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

ответ: да ... да, могут.

Итак, вы должны "солить" свои пароли. Вижу статья Википедии о соли

посмотреть " как хэшировать данные с солью " пример C#


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


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

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


Я бы тщательно рекомендую прочитать статьи Достаточно Радужных Таблиц: Что Вам Нужно Знать О Безопасных Схемах Паролей [битая ссылка, копировать в интернет-архив] и Как Безопасно Хранить Пароль.

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


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

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

Это не может быть подходит, если приложение в вопросе чисто для внутреннего использования, хотя

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


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

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


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