Как защитить зашифрованный пароль, даже самый слабый?

Question

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

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

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

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

Есть идеи?

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

Answer 1

Повторное шифрование не поможет с вашей проблемой.

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

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

Другая часть - соль для каждого применения. Вы можете сохранить его в конфигурации приложения или в специальном хранилище паролей, которое предлагает ОС.

Преимущество этого разделения состоит в том, что недостаточно, если злоумышленник просто получает доступ к базе данных, но ему нужно получить доступ к тому месту, где хранится соль вашего приложения. Так, например, простого SQL-инъекции, крадущего вашу базу данных, недостаточно. Если злоумышленник может выполнить код, он, вероятно, вообще не поможет.

---

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

Этого можно добиться, используя функцию получения ключа на основе пароля , например PBKDF2.

Answer 2

Вы можете использовать «растяжение ключа»: повторять хэш, скажем, миллион раз, после засолки.Затем сохраните хеш-значение, соль и количество итераций.Тогда злоумышленник может проверить в миллион раз меньше паролей в секунду, чем когда вы хешируете один раз.Но очень короткий пароль все равно упадет: обратите внимание, что вы сами, чтобы проверить действительный пароль, должны выполнить ту же операцию.Предположим, что вы принимаете проверку на 1 секунду для себя, тогда злоумышленник может также проверять пароли по 1 секунде на пароль на аналогичной машине (и больше, если он использовал больше или более быстрые машины!)И 1 секунды на пароль все еще может быть достаточно для проверки слабого и короткого пароля, стандартных словарей и т. Д. На самом деле защиты от него нет, только усложняется.

Answer 3

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

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