Является ли принудительное использование сложных паролей более важным, чем соление?

Я провел последние 2 часа, читая о соляных паролях, чтобы убедиться, что я понял эту идею. Я надеялся, что некоторые из вас поделятся своими знаниями о моих выводах.


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

Если это правда, то кажется, что соление на самом деле не так уж сильно помогает. Это лишь незначительно замедляет атакующего.

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

Я предполагаю, что это не столько вопрос, сколько просьба о других знаниях о ситуации.


person Galen    schedule 17.11.2009    source источник
comment
Вам необходимо указать конкретное использование шифрования, которое вы имеете в виду, а также тип атак, которые вы хотите предотвратить. Например, вы указываете брать все соли в таблице, непонятно, что это значит.   -  person mjv    schedule 17.11.2009
comment
На самом деле я не имел в виду какой-то конкретный метод шифрования. Меня больше интересовала общая идея соления и лучшие практики. Отредактировал, надеюсь, стало понятнее, спасибо.   -  person Galen    schedule 17.11.2009


Ответы (7)


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

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

person Bill the Lizard    schedule 17.11.2009
comment
Согласитесь, солить не обязательно. Он устраняет целый вектор атаки, который может поставить под угрозу всю систему безопасности, тогда как использование слабых паролей может поставить под угрозу только отдельные учетные записи. - person Kitson; 17.11.2009
comment
Вы также должны упомянуть, что нет смысла создавать словарь для каждого пользователя — быстрее просто взломать их пароль методом перебора. - person Nick Johnson; 17.11.2009
comment
Наиболее важным моментом здесь является то, что создание этого совершенно нового словаря занимает столько же времени, сколько потребуется для прямого подбора соленого хэша этого пользователя - радужные таблицы являются оптимизацией только в том случае, если одна и та же таблица может использоваться против нескольких хэшей паролей. - person caf; 17.11.2009

Является ли поддержание надлежащего обезвоживания более важным, чем дыхание?

person bcat    schedule 17.11.2009

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

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

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

person tvanfosson    schedule 17.11.2009
comment
Я никогда не понимал глобальную соль. Предположим, вы используете 8-байтовую соль для каждого пользователя, выбранную хорошим ГСЧ. Какую дополнительную ценность представляет глобальная соль? - person erickson; 17.11.2009
comment
+1. Многоуровневая политика — отличная идея для защиты привилегированных учетных записей. - person Bill the Lizard; 17.11.2009
comment
@erickson - обычно соль для каждого пользователя хранится в БД. Если вы скомпрометируете БД, взлом паролей будет лишь вопросом времени и ресурсов. Глобальная соль, хранящаяся в алгоритме, требует, чтобы они взломали сервер приложений, а также БД. Дополнительным преимуществом является то, что взломщику необходимо проверять в два раза больше перестановок из трех при хешировании. - person tvanfosson; 17.11.2009
comment
+1 к идее парольной фразы. кроме того, человеку легче запомнить, в то же время длина усложняет пароль. - person Jimmy Chandra; 17.11.2009
comment
Спасибо, мне нравится идея иметь соль для каждого пользователя и глобальную соль. - person Galen; 17.11.2009

Хорошо, давайте посмотрим на реальные цифры:

Одна Nvidia 9800GTX может вычислить 350 миллионов хэшей MD5 в секунду. При такой скорости все пространство клавиш строчных и прописных буквенно-цифровых символов будет заполнено за 7 дней. 7 символов, два часа. Применение соли удвоит или утроит это время в зависимости от вашего алгоритма.

Дешевые современные графические процессоры легко могут похвастаться миллиардом хэшей MD5 в секунду. Решительные люди обычно связывают около 6 из них и получают 6 миллиардов в секунду, что делает 9-символьное пространство ключей устаревшим за 26 дней.

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

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

И бум, ваше 10-символьное пространство ключей выполняется за 9,7 дня, но тогда 11-символьные пароли занимают 602 дня. Обратите внимание, что на этом этапе добавление 10 или 20 специальных символов в список разрешенных символов приведет только к увеличению времени взлома 10-символьного пространства ключей до 43 или 159 дней соответственно.

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

Тогда есть еще одна проблема, будет ли пользователь использовать этот «надежный» пароль, который вы заставили его использовать на всех своих других сайтах? Если он не сохранит их в файле мастер-паролей, то наверняка сделает это. И эти другие сайты не будут использовать те же сильные алгоритмы хеширования, которые используете вы, что противоречит цели вашей системы. Я действительно не понимаю, почему вы хотите, чтобы ваши хэши были очень надежными, если это не для того, чтобы пользователи не использовали один и тот же пароль на нескольких сайтах; если злоумышленник имеет доступ к вашим хэшам, вы, скорее всего, уже проиграли.

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

Чтобы наивно ответить на ваш вопрос: надежный пароль поддерживается только надежным алгоритмом хеширования.

person L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o&#x    schedule 17.11.2009
comment
Применение соли удвоит или утроит это время в зависимости от вашего алгоритма. - хм, соли предназначены не для того, чтобы усложнить взлом отдельных паролей, а скорее для предотвращения использования предварительно сгенерированной таблицы хэшей паролей. - person Nick Johnson; 17.11.2009
comment
Я знаю, я говорил о времени грубой силы, поскольку атаки с прообразом обычно бесполезны, если есть сильная система случайных солей. - person L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o&#x; 17.11.2009
comment
Известная соль вообще не изменит время, необходимое для поиска в заданном пространстве. Но поскольку мы выполняем тысячи итераций хэша, бум, 10-символьное пространство ключей занимает десятилетия. - person erickson; 18.11.2009
comment
Да, но вы забываете, что пароль для одного сайта обычно не настолько важен, если только у цели нет одного и того же пароля на нескольких сайтах, и в этом случае схема надежного хеширования паролей не будет я> помочь вообще. В противном случае, если пароль является важным только для вашего сайта, вы, скорее всего, уже потеряли... - person L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o&#x; 18.11.2009
comment
В любом случае, вы правы в том, что сильный, итерированный, соленый хэш идеально подходит для мест, где вы не можете использовать настоящую аутентификацию, например сертификаты клиентов. , но я бы никогда не использовал технику хэширования в реальном сценарии (за исключением гибрида с клиентским сертификатом). - person L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o&#x; 18.11.2009

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

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

В первые дни процессоры шифрования с двумя простыми числами были настолько медленными, что люди, как правило, использовали арифметику int32 для повышения скорости. Это позволило мне предположить, что простые числа находятся в диапазоне от 0 до четырех миллиардов. Люди всегда выбирали большие простые числа, потому что общепринятое мнение гласит, что чем больше, тем лучше. Поэтому я использовал заранее составленный словарь простых чисел и работал с известным потолком, зная, что люди обычно выбирают ключи, близкие к этому потолку. Обычно это позволяло мне взломать их ключ примерно за 30 секунд.

Настаивайте на длинных проходных фразах и используйте соление без каких-либо других ограничений.

Когда люди говорят «сложные» техники, они часто имеют в виду сложные. Преобразование может быть очень сложным и, тем не менее, коммутативным, и, к сожалению, если вы не знаете, что это значит, вы не в состоянии оценить достоинства метода. Сложность алгоритма дает только безопасность через неизвестность, что немного похоже на получение дома за городом и не запирание дверей.

person Peter Wone    schedule 18.11.2009
comment
Но разве это не упрощает взлом? Если минимальная длина пароля равна 2, то вполне вероятно, что некоторые пользователи выберут двухсимвольный пароль. В любом случае, это миллисекунды для атаки методом перебора пароля или, по крайней мере, пара секунд для неизвестной соли из 12 бит. - person wallyk; 18.11.2009
comment
Под минимальной длиной пароля я подразумевал использование достаточно длинных паролей. - person Peter Wone; 20.11.2009

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

Но не мешайте своим пользователям. Предлагайте предложения, но не становитесь на их пути.

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

person yfeldblum    schedule 17.11.2009
comment
Вы несете ответственность перед другими пользователями за то, чтобы все пользователи использовали правильные пароли. По мере того, как важность данных возрастает, возрастает и важность применения хороших политик. Ваши данные защищены настолько, насколько наименее защищен доступ к ним вашего пользователя. - person tvanfosson; 17.11.2009
comment
По мере того, как важность данных возрастает и по мере того, как рассматриваемый пользователь получает больше доступа к большему количеству более важных данных, можно рассмотреть возможность принудительного использования надежных паролей. Пока учетная запись каждого пользователя содержит только его собственные данные, этот пользователь несет ответственность за свою учетную запись. - person yfeldblum; 17.11.2009

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

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

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

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

person Kelly Gendron    schedule 17.11.2009