Является ли форсирование сложных паролей "более важным", чем соление?

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

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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

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

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

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

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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