Нужно ли соль быть случайным, чтобы защитить хеш пароля?
Я очень мало знаю о безопасности (мне нужно найти базовое объяснение основ) и пытаюсь найти разумный способ хранения пользовательских паролей в базе данных с использованием.Net.
Вот мое текущее решение:
private static byte[] HashPassword(string password)
{
using (var deriveBytes = new Rfc2898DeriveBytes(password, 10))
{
byte[] salt = deriveBytes.Salt;
byte[] key = deriveBytes.GetBytes(20);
return salt.Concat(key).ToArray(); //Return Salt+Key
}
}
Я храню результаты HashPassword() в базе данных. Чтобы проверить пароль пользователя, я делаю это:
var salt = //1st 10 bytes stored in the DB
var key = //Next 20 bytes stored in the DB
using (var deriveBytes = new Rfc2898DeriveBytes(password, salt))
{
byte[] newKey = deriveBytes.GetBytes(20);
if (newKey.SequenceEqual(key) == false) //Check if keys match
{
return "No Match";
}
else { return "Passwords match"; }
Мой вопрос заключается в том, должна ли соль быть случайной и храниться в БД, как эта, или если я могу сгенерировать 10-байтовую соль, сохранить ее в своем коде и всегда использовать ту же самую соль, чтобы сохранить себя, храня соль в БД и просто хранить ключ?
Также, если кто-то увидит какие-либо другие проблемы с тем, что я делаю, буду признателен за любые советы.
2 ответа
Мой вопрос заключается в том, должна ли соль быть случайной и храниться в БД, как эта, или если я могу сгенерировать 10-байтовую соль, сохранить ее в своем коде и всегда использовать ту же соль, чтобы сохранить себя, храня соль в БД и просто хранить ключ?
ТОЧНО НЕТ.
Вы вообще не понимаете назначение соли, даже если задаете этот вопрос.
Соль в том, чтобы злоумышленнику было произвольно сложнее использовать предварительно вычисленную таблицу хешированных общих паролей. Если соль всегда одна и та же, то злоумышленник просто вычисляет таблицу хэшированных общих паролей с этой солью.
Позвольте мне сделать это более ясным. Предположим, что злоумышленник получил вашу базу данных паролей и в свободное время проводит атаку на все сохраненные хэши, чтобы выяснить, какой пароль соответствует хешу. Если каждая соль отличается, то злоумышленник должен провести новую атаку против каждой записи в базе данных. Если все соли одинаковы, то атака одного пользователя атакует каждого пользователя.
Более того: предположим, что вы используете одну и ту же соль для каждого пользователя. Предположим, у двух пользователей один и тот же пароль. И предположим, что злоумышленник получил базу паролей. Теперь злоумышленник знает, какие два пользователя имеют один и тот же пароль, поскольку у них одинаковый соленый хеш, и может сделать разумное предположение, что это самый слабый пароль в базе данных. Злоумышленник может сосредоточить свои усилия (какими бы они ни были) на том, чтобы атаковать этого пользователя в частности. И как только она узнает пароль этого пользователя, вероятно, что пользователь использовал это имя пользователя и слабый пароль в других системах, которые злоумышленник теперь может скомпрометировать, не имея своих файлов паролей.
Хорошо, что вы хотите узнать о безопасности; плохо, что вы пытаетесь написать реальную систему паролей с вашим уровнем понимания. Если это для реальной системы, которая должна защищать реальных пользователей, используйте систему, созданную экспертами, или наймите своего собственного эксперта. Вы создадите систему, которую вы не сможете сломать, а не систему, которую злоумышленник не сможет сломать.
Более того: вы просите незнакомцев в интернете о помощи в вопросах безопасности. Незнакомцы, которых вы не знаете, знают ли они, о чем говорят, или просто придумывают. Получить настоящий эксперт по безопасности (и это не я - я эксперт по семантическим анализаторам). Построение системы безопасности является одной из самых сложных задач программирования; Вам нужна профессиональная помощь.
Подробное введение в основные схемы аутентификации по паролю см. В моей серии статей:
Вам не нужно применять случайную соль, но если вы сделаете это, ваши пароли будут более безопасными. Очевидно, что если вы примените случайную соль, то вам нужно сохранить ее с хешированным паролем в БД, чтобы вы могли сверяться с предоставленным паролем.
Быстрый Google показал этот пост, который может вам помочь.