Лучший способ сохранить пароль в базе данных [закрыто]
То, что вы ищете, называется OLE, Object Linking and Embedding. Первоначально выпущенный в 1990 году, Microsoft Office стал последним основным продуктом Microsoft, который все еще поддерживал его. Время не было добрым к OLE, протокол был сложным и очень трудным для правильного. Также очень вредно для стабильности программы, вы не просто импортируете окна и пользовательские интерфейсы другой программы, но также и все свои ошибки.
Примечательно, что платформа .NET поставляется без какой-либо поддержки для нее. Office 2007 был последним, который поддерживал его, но с ним было несколько неприятных и неразрешимых проблем. DsoFramer был удален с серверов Microsoft перед выпуском бета-версии Office 2010.
Это исчезло навсегда и не вернется. Двигайтесь вперед, встраивая свой интерфейс в программу Office, а не наоборот. Очень хорошо поддерживается в VS с его шаблонами проектов Office. Существуют сторонние продукты, которые поддерживают внедрение текстового процессора или электронной таблицы в вашу собственную программу.
8 ответов
Вы правы, что хранить пароль в текстовом поле - это ужасная идея. Однако , что касается местоположения , для большинства случаев, с которыми вы столкнетесь (и я, честно говоря, не могу придумать никаких контрпримеров), хранящих представление пароль в базе данных - это то, что нужно сделать. Под представлением я подразумеваю, что вы хотите хэшировать пароль, используя соль (которая должна быть разной для каждого пользователя) и безопасный односторонний алгоритм, и сохранить , что , отбросив исходный пароль. Затем, когда вы хотите проверить пароль, вы хешируете значение (используя тот же алгоритм хеширования и соль) и сравниваете его с хешированным значением в базе данных.
Итак, хотя это хорошо, вы думаете об этом и это хороший вопрос, это на самом деле дубликат этих вопросов (по крайней мере):
- Как лучше всего хранить информацию о пользователях, а также логин и пароль пользователя
- Рекомендации по хранению паролей к базе данных
- Salting Your Password: Передовой опыт?
- Можно ли когда-либо хранить пароль в виде обычного текста в переменной php или константе php?
Чтобы уточнить немного подробнее, Опасность простого хеширования пароля и его хранения заключается в том, что если злоумышленник завладеет вашей базой данных, он все равно сможет использовать так называемые радужные таблицы , чтобы иметь возможность «расшифровать» пароль (по крайней мере, те, которые появляются в радужной таблице). Чтобы обойти это, разработчики добавляют к паролям соль , которая, при правильном выполнении, делает невозможным проведение радужных атак. Обратите внимание, что распространенное заблуждение - просто добавлять одну и ту же уникальную длинную строку ко всем паролям; хотя это не ужасно , лучше всего добавлять уникальные соли к каждому паролю. Прочтите это, чтобы узнать больше.
Справочная информация Вам никогда ... правда ... не нужно знать пароль пользователя. Вы просто хотите убедиться, что входящий пользователь знает пароль к учетной записи.
Hash It: Храните пароли пользователей, хешированные (одностороннее шифрование) с помощью надежной хеш-функции. Поиск по запросу «c # encrypt passwords» дает множество примеров.
См. онлайн-создатель хеша SHA1 , чтобы получить представление о том, что производит хеш-функция (но не используйте SHA1 в качестве хеш-функции, используйте что-то более надежное, например SHA256).
Теперь хешированные пароли означают, что вы (и похитители баз данных) не должны иметь возможности вернуть этот хеш-код обратно в исходный пароль.
Как использовать: Но вы спросите, как мне использовать этот запятнанный пароль, хранящийся в базе данных?
Когда пользователь входит в систему, они передают вам имя пользователя и пароль (в исходном тексте) Вы просто используете тот же хэш-код для хеширования введенного пароля, чтобы получить сохраненную версию.
Итак, сравните два хешированных пароля (хэш базы данных для имени пользователя и введенный и хешированный пароль). Вы можете определить, совпало ли «то, что они ввели», с тем, что исходный пользователь ввел для своего пароля », сравнив их хэши.
Дополнительные баллы:
Вопрос: Если бы у меня была ваша база данных, то я бы не смог Я просто беру взломщик, такой как John the Ripper, и начинаю собирать хеши, пока не найду совпадения с вашими сохраненными хешированными паролями? (поскольку пользователи все равно выбирают короткие словарные слова ... это должно быть легко)
Ответ: Да ... да, они могут.
Итак, вам следует «засолить» свои пароли. См. статью о соли в Википедии
В качестве соленого хеша с усиленной ключевой защитой с использованием безопасного алгоритма, такого как sha-512.
Лучшая практика безопасности - это не хранить пароль вообще (даже не в зашифрованном виде), а хранить соленый хеш (с уникальной солью для каждого пароля) зашифрованного пароля.
Таким образом (практически) невозможно получить пароль в виде открытого текста.
I'd thoroughly recommend reading the articles Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes [dead link, copy at the Internet Archive] and How To Safely Store A Password.
Lots of coders, myself included, think they understand security and hashing. Sadly most of us just don't.
Я могу быть немного не по теме, поскольку вы упомянули о необходимости имени пользователя и пароля, и мое понимание проблемы, по общему признанию, не самое лучшее, но стоит ли рассматривать OpenID?
Если вы используете OpenID, тогда вы вообще не сохраните никаких учетных данных, если я правильно понимаю технологию, и пользователи могут использовать учетные данные, которые у них уже есть, избегая необходимости создавать новую личность, специфичную для вашего приложения.
Это может не подходить, если рассматриваемое приложение предназначено исключительно для внутреннего использования, хотя
RPX предоставляет удобный простой способ интегрировать поддержку OpenID в приложение.
В вашем сценарии вы можете взглянуть на членство в asp.net, рекомендуется хранить пароль пользователя в виде хешированной строки в базе данных. вы можете аутентифицировать пользователя, сравнивая хэшированный входящий пароль с паролем, хранящимся в базе данных.
Все было создано для этих целей, проверьте членство в asp.net
Я бы использовал MD5 / SHA1 пароль, если вам не нужно иметь возможность отменить хэш. Когда пользователь входит в систему, вы можете просто зашифровать заданный пароль и сравнить его с хешем. В этом случае коллизии хэшей почти невозможны, если только кто-то не получит доступ к базе данных и не увидит хэш, для которого уже есть коллизия.