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

Ответ 1

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

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

._______._________________.______________.
|user_id|hash             |salt          |
|-------|-----------------|--------------|
|12     |[email protected]|13%!#tQ!#3t...|
|       |...              |...           |

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

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

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

IMHO это не всегда функция безопасности, которая необходима. Поэтому вы должны подумать, хотите ли вы этого.

См. эту статью для хорошего резюме этого механизма.

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

Ответ 2

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

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

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

Ответ 3

как правило, это способ сделать это.

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

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

Большинство разработчиков .net, похоже, любят использовать TDES

Ответ 4

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