Максимальная защита от хэша - обсуждение концепций

Question

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

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

Решение, используйте сайт "перец" плюс пользовательскую соль, тогда, даже если они получат БД, им все равно придется знать файл конфигурации. Проблема: если они могут проникнуть в вашу БД, они также могут попасть в вашу файловую систему и обнаружить ваш сайт.

Итак, со всем этим известным - давайте предположим, что злоумышленник зайдет на ваш сайт и получит все, ВСЕ. Так что ты сейчас делаешь?

На этом этапе обсуждения большинство людей отвечают: «Кого это волнует?». Но это просто дешевый способ сказать: «Я не знаю, что делать дальше, так что это не может быть так важно». К сожалению, везде я задавал этот вопрос, который был ответом. Что показывает, что большинство программистов упускают очень важный момент.

Позволяет представить, что ваш сайт похож на другие 95% сайтов, а пользовательские данные - или даже полный доступ - не стоит приседать. Злоумышленник случайно выбрал одного из ваших пользователей «Боб», потому что он знает, что «Боб» использует тот же пароль на вашем сайте, что и на сайте банка. Он также знает, что у Боба есть сбережения. Теперь, если злоумышленник сможет просто взломать наши хэши сайтов, остальное будет просто пирогом.

Итак, вот мой вопрос: как увеличить длину пароля без отслеживания пути? Или как сделать процесс хеширования сложным для своевременного дублирования? Единственное, что я придумал, это то, что вы можете повторно хэшировать несколько тысяч раз и увеличивать время, необходимое для создания окончательной радужной таблицы, в 1000 раз. Это потому, что злоумышленник должен следовать по тому же пути при создании своих таблиц.

Есть еще идеи?

Answer 1

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

Это рассуждение ошибочно.

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

Answer 2

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

Разве это не то, о чем говорит хеш на основе Blowfish BCrypt ? Увеличивать время, необходимое для вычисления хэша, чтобы взломать методом грубой силы (и создать радужную таблицу) стало невозможно?

«Мы представляем два алгоритма с адаптивной стоимостью (...)»

Подробнее об адаптивных алгоритмах хэширования затрат: http://www.usenix.org/events/usenix99/provos.html

Answer 3

хм ... Хорошо, мой взгляд на это:

• Вы не можете получить исходный пароль из хэша. У меня есть ваш хэш, я могу найти пароль, который соответствует этому хэшу, но я не могу войти на любой другой сайт, который использует этот пароль, при условии, что они все используют соление. Здесь нет никаких реальных проблем.
• Если кто-то получает вашу БД или даже ваш сайт, чтобы получить ваш конфиг, вы все равно облажались.
• Для администраторов или других супер-учетных записей внедрить второе средство проверки, то есть ограничить входы в систему определенными диапазонами IP-адресов, использовать сертификаты SSL на стороне клиента и т. Д.
• Для обычных пользователей у вас не будет большого шанса. Все, что вы делаете с их паролем, должно храниться в некоторой конфигурации или базе данных, поэтому, если у вас есть ваш сайт, у меня есть и ваше волшебное змеиное масло.
• Сильные ограничения пароля не всегда работают. Некоторые сайты требуют, чтобы пароли имели числовой символ, и в результате большинство пользователей добавляют 1 к своему обычному паролю.

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

Answer 4

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

Конечно, если у них есть доступ ко ВСЕМУ, они могут ненадолго отразиться на активности пользователя ..

Answer 5

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