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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

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

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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