#asp.net #sql-server
#asp.net #sql-сервер
Вопрос:
Мне интересно, как зашифровать столбец моего пароля в SQL Server 2008. Я прочитал эту статью, но я все еще понятия не имею, как … есть ли более простое для понимания руководство? Спасибо!
Комментарии:
1. Похоже, что ваша ссылка на «эту статью» пропала без вести.
2. упс, начинается msdn.microsoft.com/en-us/library/ms179331.aspx
3. @user133466 — Почему вы не сохраняете хэши паролей из исходного приложения?
4. можете ли вы показать мне статью об этом? Я использую ASP.net (VB.net )
5. @user133466 — Если вы используете проверку подлинности Forms с помощью SqlMembershipProvider, он обработает все хэширование за вас.
Ответ №1:
Обычной практикой является сохранение хэша пароля. Нравится:
HASHBYTES('SHA1', convert(varbinary(32), @password))
С помощью хэша вы можете проверить, совпадает ли пароль, но вы не знаете сам пароль. Таким образом, даже если хакер получит полный доступ к вашей базе данных, он все равно не знает паролей.
В Интернете есть много руководств.
Комментарии:
1. Также неплохо использовать значение salt. Случайный (криптографически надежный) int или bigint могут работать отлично.
2. как мне проверить учетные данные? Обычно я использую If ProfileDataset. Таблицы («RO_User»).Строки. Count = 1 и strPassword. toString <> ProfileDataset. Таблицы («RO_User»). Строки(0).Элемент(«User_psw»). Затем ввести строку… но теперь мне негде разместить функцию hashbytes
3. @user133466: хэшируйте учетные данные таким же образом, как и исходный пароль. Если хэши совпадают, строки равны.
4. @user133466 — Следует отметить, что вы должны сделать это в БД. Т.е. передать обычный текстовый пароль в БД, использовать для него хэш-байты, а затем вернуть, соответствует ли результат хэшу, хранящемуся в БД. Кроме того, это означает, что вы передаете в базу данных обычный текстовый пароль в формате clear, если только вы не зашифровали соединение с базой данных.
Ответ №2:
Вместо этого вам следует рассмотреть возможность хранения хэшей паролей вместо использования шифрования. На случай, если вы не знаете о различиях, хэш (также называемый односторонним хэшем) принимает входные данные и выдает какую-то чушь (называемую хэшем), так что для одного и того же ввода создается одна и та же чушь. Аутентификация выполняется путем хэширования того, что пользователь ввел на клиенте, и сравнения его с информацией в базе данных. Если они совпадают, пароли совпадают. Не вдаваясь в подробности, хэши никогда не могут быть возвращены обратно в обычный текст, который является их защитой. Однако шифрование включает в себя создание шифра таким образом, что при наличии ключа дешифрования вы можете вернуть шифр обратно в обычный текст.
Если вы используете SQL Server и ASP.NET вам следует изучить аутентификацию форм с помощью SqlMembershipProvider.
Комментарии:
1. Именно поэтому мы используем соль, которая никогда не покидает базу данных. Хэш пользовательского интерфейса соль = хэш базы данных.
2. Проголосуйте за MembershipProvider. На мой взгляд, вам понадобится действительно веская причина, чтобы не использовать его. Также для gobbledygook.
3. @Simon: MembershipProvider привязывает вас к ASP.NET клиент. Также довольно сложно добавить к нему новую функциональность.
4. @Andomar — OP уже сказал, что он использовал ASP.NET (и SQL Server). Первое правило безопасности — не делайте этого самостоятельно. Если пользователь использует функцию Hashbytes, ему необходимо знать о солях и последствиях передачи обычного текста вплоть до базы данных
5. @Andomar: Верно, но, учитывая, что OP заявил, что он использует ASP.NET и спрашивает об основах, таких как хеширование, я подозреваю, что MembershipProvider сделает все, что ему нужно на данный момент. @user133466: Я предлагаю вам проверить это и принять обоснованное решение относительно того, соответствует ли это вашим потребностям.
Ответ №3:
Microsoft упростила это с помощью быстро названного
FormsAuthentication.HashPasswordForStoringInConfigFile .
http://www.adventuresindevelopment.com/2009/05/23/a-simple-way-to-hash-passwords-in-aspnet/