Ultimate Hash Protection - Обсуждение концепций

Question

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

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

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

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

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

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

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

Любые другие идеи?

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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