Какова рекомендуемая практика хранения паролей пользователей в SQL Server 2008?сохранение паролей в SQL Server
Я сохраняю данные пользователя для интрасети и хотел бы получить совет по наилучшему способу хранения пользовательских данных, таких как имя, пароль и пользовательские права доступа и т. Д. Я думаю о создании столбца nvarchar и затем шифровании этого текст перед вставкой в таблицу.
Это обычно способ сделать это.
Ваше приложение будет обрабатывать шифрование (и, возможно, дешифрование), база данных просто сохранит пароль.
Я рекомендую использовать что-то более сильное, чем датированный Defacto - MD5
Большинство разработчиков .NET, кажется, нравится использовать TDES
Я бы согласился, что вы хотите пойти с чем-то более сильным, чем MD5, когда можете –
MD5 не является алгоритмом шифрования, это алгоритм хеширования. http://en.wikipedia.org/wiki/MD5 –
Согласовано. Я думаю, я не был явным, так что вы получаете вверх :) –
T-Sql включает в себя функции шифрования - 4Guys имел good article on it for SQL Server 2005 аа некоторое время назад, но я думаю, что это все еще применяется к 2008 году.
Эта статья посвящена симметричному шифрованию ключа. Пароли должны быть хэшированы. – Swoogan
Я согласен - статья, с которой я связан, значительно устарела. Вот почему я лично поддержал ответ Элазар-лейбовича выше. –
Шифрование для конфиденциальных данных - это хорошо. Однако с паролями вам никогда не нужно знать исходное значение, и поскольку все, что зашифровано, также может быть расшифровано, вы помещаете эту информацию под угрозу обнаружения.
Вместо этого вы должны сохранить хэш пароля. Этот процесс принимает значение и генерирует то, что составляет очень сложную контрольную сумму. Учитывая число, невозможно вернуться к исходному паролю, что повышает безопасность такой информации. Когда вы хотите узнать, дал ли кто-то правильный пароль, вы получаете значение, которое они дали вам, и сравнивайте хеши.
Безопасность - сложная тема. Даже с помощью хэшей вы можете получить систему с существенными недостатками безопасности. Получение помощи консультанта по безопасности - неплохая идея, если никто из вашей команды уже не обладает такими знаниями.
Очень верно в большинстве случаев. Учитывая, что OP используется в интрасети, могут быть обстоятельства (интеграция с другими приложениями в интрасети, требующая входа в систему), когда полезно получить пароль. –
Обычный способ хранения пароля - использовать хэш-функцию для пароля, но до salt заблаговременно. Важно «солить» пароль, защищаться от атак rainbow table.
Так что ваш стол должен выглядеть примерно так, что
._______._________________.______________.
|user_id|hash |salt |
|-------|-----------------|--------------|
|12 |[email protected]|13%!#tQ!#3t...|
| |... |... |
При проверке, если данный пароль совпадает с пользователем, вы должны сцепить соль для данного пароля, а также вычислить хэш-функцию от строки результата. Если выход хэш-функции соответствует столбцу hash - это правильный пароль.
Важно понимать, что идея соли-хеши имеет конкретную причину - запретить любому человеку, имеющему доступ к базе данных, знать какой-либо пароль (считается сложной проблемой для изменения вывода хэш-функции). Так, например, администратор базы данных банка не сможет войти на ваш банковский счет, даже если у него есть доступ ко всем столбцам.
Вы также должны использовать его, если считаете, что ваши пользователи будут использовать секретный пароль (например, пароль для своей учетной записи gmail) в качестве пароля вашего веб-сайта.
ИМХО это не всегда функция безопасности, которая необходима. Поэтому вы должны подумать, хотите ли вы этого.
См. this article за хорошее резюме этого механизма.
Update: Стоит отметить, что для дополнительной защиты от целенаправленной атаки для реверсирования хэша индивидуального пароля, вы должны use bcrypt, который может быть сколь угодно сложно вычислить. (Но если вы действительно не боитесь таинственного человека в черном, нацеленного на вашу конкретную базу данных, я думаю, что sha1 достаточно хорош. Я бы не представил другую зависимость для моего проекта для этой дополнительной безопасности. Тем не менее, нет причин не использовать sha1 100 раз, что дало бы аналогичный эффект).
ссылка выше не работает, но [это] (http://msdn.microsoft.com/en-us/library/ff649202.aspx) делает. – JumpingJezza
@JumpingJezza, спасибо, он работал, я обновляю ссылку –
Если это домен AD, вы не могли бы позволить аутентификации AD? – Rytmis
Спасибо всем за предложения. Richard – Richard