Полная информация о солях хеша

Question

Есть много вопросов о солях и лучших практиках, однако большинство из них просто отвечают на очень конкретные вопросы о них. У меня есть несколько вопросов, которые связаны друг с другом.

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

Это приводит к ряду вопросов:

1. Хотя соль не предназначена для защиты от неясности не будет ли еще безопаснее поместить соли в отдельную таблицу? Таким образом, даже если таблица «пользователей» подвергнется риску, соли не будут.
2. Может ли наличие соли со 2-ым жестко закодированным приложением повысить уровень безопасности? Таким образом, даже если база данных скомпрометирована, фактическое приложение также должно быть скомпрометировано, иначе как соли, так и хэши будут совершенно бесполезны.
3. Какова лучшая длина для соли? Очевидно, что чем дольше, тем лучше, однако при большем количестве пользователей размер базы данных становится проблемой, поэтому какой будет минимальная длина для эффективной соли?
4. Действительно ли необходимо использование стороннего источника для "настоящей случайной соли" (random.org, random.irb.hr)? Я понимаю, что использование соли, основанной на серверном времени, в некоторой степени "предположительно", однако взятие случайной подстроки случайной строки sha1'd кажется эффективным методом соли.

Заранее спасибо.

Answer 1

1. Если хакер имеет доступ к вашей системе баз данных, вы fsckd. Ваша система должна иметь доступ к обеим таблицам для запуска, поэтому вероятность «скрытия» от хакера, который уже взломал систему, почти равна нулю. На мой взгляд, не стоит дополнительной сложности.

2. Добавление "nonce" (в дополнение) к соли для каждого пароля не очень помогает, но на самом деле ничего не вредит.

3. Даже 16 бит соли обычно достаточно, чтобы сделать взлом пароля невозможным, если все сделано правильно. Я бы, наверное, использовал 64 или 128 бит, почему бы и нет?

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

Короче говоря, вам нужна соль для каждого пользователя и хорошая функция хеширования. MD5 ужасен, а SHA-1 больше не «хорош». Вы должны использовать такую ​​систему, как bcrypt, чтобы заставить атакующего тратить значительную долю секунды на каждый хеш. 0,1сек за проверку пароля, вероятно, не имеет большого значения для вас, но это разрушительно для любого вида взлома методом перебора.

Это обязательное чтение для всех, кто внедряет схему защиты паролем:

http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

Answer 2

Что касается # 1, вы, вероятно, можете предположить, что, если таблица users скомпрометирована, они, вероятно, также скомпрометируют таблицу salt, даже если вы ее как-то лучше защитите. Это только замедлит их немного, как это сделает скоростной удар.

Что касается # 2, то жестко запрограммированное солт-значение часто легко воссоздать с помощью декомпиляции или проверки памяти во время выполнения, даже при умеренном количестве запутывания кода. Это поможет повысить безопасность только в том случае, если ваше приложение строго размещено и никто не может получить доступ к вашему скомпилированному приложению.

Относительно # 3: Какова оптимальная длина для хэша пароля? (SO link) - 16 - это хорошо!

Что касается # 4, то внедрение «более истинных» случайных чисел не намного сложнее, в зависимости от платформы, с которой вы работаете. Например, если вы можете компрометировать некоторую производительность , чтобы сгенерировать ваше начальное / случайное число, вы, вероятно, можете вздохнуть с легкостью от того, насколько действительно случайна ваша соль.

Answer 3

1) Нет. Злоумышленник, вероятно, сбросит все данные в вашей системе и в конечном итоге найдет соли (хотя это будет раздражать).

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

3) Единственное требование соли - это то, что она уникальна для каждого пользователя. Длина не имеет значения для безопасности - соли не являются ключами , несмотря на широко распространенную путаницу. 64-битные случайные соли никогда не повторятся. Вы также можете использовать 32-битный счетчик или просто использовать идентификаторы пользователя, если они уникальны.

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

Answer 4

1. Нет. Правильное использование солей увеличит время, необходимое злоумышленнику для взлома всех паролей в вашей базе данных, в миллион раз. Помещение солей в другой стол добавит 30 секунд к времени, которое требуется злоумышленнику для получения солей.

2. Да. Неплохая идея использовать как глобальный ключ, так и соль для каждого пользователя.

3. Соль - это или должна быть криптографический ключ. Сделайте это долго и случайно. Размер базы данных не является проблемой. Соль, как и любой криптографический ключ, может иметь длину 128 бит или 16 байтов (32 байта при хранении в шестнадцатеричном формате).

4. Ваш компьютер должен иметь криптографически стойкий псевдо-ГСЧ. Проверьте API безопасности или шифрования для вашего языка.