хранение паролей в SQL Server

Question

Как рекомендуется хранить пароли пользователей в SQL Server 2008?

Я храню данные о пользователях для интрасети и хотел бы получить совет о том, как лучше хранить данные о пользователе, такие как имя, пароль, права доступа пользователя и т. Д. Я думаю о создании столбца nvarchar и шифровании этого текста перед вставкой в ​​таблицу.

Answer 1

Обычный способ хранения пароля - использовать хеш-функцию для пароля, но salt заранее. Важно «засолить» пароль, защитить себя от радужного стола атак.

Итак, ваш стол должен выглядеть примерно так

._______._________________.______________.
|user_id|hash             |salt          |
|-------|-----------------|--------------|
|12     |adsgasdg@g4wea...|13%!#tQ!#3t...|
|       |...              |...           |

При проверке соответствия данного пароля пользователю необходимо объединить соль с данным паролем и вычислить хеш-функцию строки результата. Если выходные данные хеш-функции соответствуют столбцу hash - это правильный пароль.

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

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

ИМХО, это не всегда функция безопасности, которая необходима. Так что вы должны подумать, хотите ли вы этого.

См. в этой статье для краткого описания этого механизма.

Обновление: Стоит отметить, что для дополнительной защиты от целевой атаки при обращении хэша отдельного пароля вам следует использовать bcrypt , который может быть произвольно сложным для вычисления. (Но если вы действительно не боитесь, что таинственный человек в черном нацелится на вашу конкретную базу данных, я думаю, что sha1 достаточно хорош. Я бы не стал вводить другую зависимость для моего проекта для этой дополнительной безопасности. При этом нет причин не использовать sha1 100 раз, что даст аналогичный эффект).

Answer 2

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

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

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

Answer 3

T-Sql включает в себя функции шифрования - у 4Guys была хорошая статья для SQL Server 2005 аа, но я думаю, что все это относится и к 2008 году.

Answer 4

это вообще способ сделать это.

Ваше приложение будет обрабатывать шифрование (и, возможно, расшифровку), база данных будет просто хранить пароль.

Я рекомендую использовать что-то более сильное, чем устаревшее дефакто - MD5

Большинству разработчиков .net нравится использовать TDES