Ключ к правильному применению криптографии - определить с достаточной точностью, какие свойства вы ищете.
Обычно, когда кто-то хочет хэшировать пароли, это происходит в следующем контексте: сервер аутентифицирует пользователей; пользователи показывают свой пароль через конфиденциальный канал (HTTPS ...). Таким образом, сервер должен хранить пароли пользователей или, по крайней мере, хранить что-то, что можно использовать для проверки пароля. Мы не хотим хранить пароли «как есть», потому что злоумышленник, получивший доступ на чтение к базе данных сервера, узнает все пароли. Это наша модель атаки .
A пароль - это то, что вписывается в мозг обычного пользователя, поэтому его нельзя полностью угадать. Некоторые пользователи выбирают очень длинные пароли с высокой энтропией, но большинство выбирают пароли с энтропией, скажем, не более 32 бит. Это способ сказать, что злоумышленнику придется «попробовать» в среднем менее 2 31 (около 2 миллиардов) потенциальных паролей, прежде чем найти правильный.
Что бы ни хранил сервер, достаточно проверить пароль; следовательно, у нашего злоумышленника есть все данные, необходимые для использования паролей, ограниченные только вычислительной мощностью, которую он может собрать. Это известно как атака по словарю в автономном режиме .
Надо полагать, что наш злоумышленник может взломать один пароль. На данный момент мы можем надеяться на два свойства:
- взломать один пароль должно быть сложно (считанные дни или недели, а не секунды);
- взломать два пароля должны быть вдвое такими же сложными, как взломать один.
Эти два свойства требуют различных контрмер, которые можно комбинировать.
1. Медленный хэш
Хэш-функции работают быстро. Вычислительная мощность дешева. В качестве точки данных, с SHA-1 в качестве хэш-функции и графической картой NVidia за 130 $, я могу хэшировать 160 миллионов паролей в секунду. Стоимость 2 31 оплачивается примерно за 13 секунд. Таким образом, SHA-1 слишком быстр для безопасности.
С другой стороны, пользователь не увидит никакой разницы между аутентификацией в 1 мкс и аутентификацией в 1 мс. Таким образом, хитрость заключается в том, чтобы деформировать хэш-функцию таким образом, чтобы она замедлялась.
Например, если дана хеш-функция H , используйте другую хеш-функцию H ', определенную как:
H '(x) = H (x || x || x || ... || x)
где ' || ' означает конкатенацию. Проще говоря, повторите ввод достаточно много раз, чтобы вычисление функции H ' заняло некоторое незначительное время. Таким образом, вы устанавливаете цель времени, например, 1 мс, и настройте количество повторений, необходимое для достижения этой цели. 10 мс означает, что ваш сервер сможет аутентифицировать 10 пользователей в секунду, затратив всего 10% его вычислительной мощности. Обратите внимание, что речь идет о сервере, хранящем хешированный пароль для собственного скрытого использования, поэтому здесь нет проблемы взаимодействия: каждый сервер может использовать определенное количество повторений, специально разработанное для его мощности.
Предположим теперь, что злоумышленник может в 100 раз увеличить вашу вычислительную мощность; например злоумышленник - скучающий студент - заклятый враг многих систем безопасности - и может использовать десятки компьютеров в своем университетском городке. Также злоумышленник может использовать более тщательно оптимизированную реализацию хэш-функции H (вы говорите о PHP, но злоумышленник может выполнить сборку). Более того, злоумышленник - пациент : пользователи не могут ждать более доли секунды, но достаточно скучающий студент может попробовать несколько дней. Тем не менее, попытка 2 миллиардов паролей все еще потребует около 3 полных дней вычислений. Это не совсем безопасно, но намного лучше, чем 13 секунд на одном дешевом ПК.
2. Соли
A salt - это часть общедоступных данных, которую вы хэшируете с паролем для предотвращения общего доступа .
«Совместное использование» - это то, что происходит, когда злоумышленник может повторно использовать свои попытки хэширования для нескольких атакованных паролей. Вот что происходит, когда у злоумышленника есть несколько хешированных паролей (он прочитал всю базу хешированных паролей): всякий раз, когда он хеширует один потенциальный пароль, он может искать его против всех хешированных паролей он пытается атаковать. Мы называем это параллельная атака по словарю . Другим примером совместного использования является случай, когда злоумышленник может создать предварительно вычисленную таблицу хешированных паролей, а затем повторно использовать свою таблицу (путем простого поиска). Fabled rainbow table - это особый случай предварительно вычисленной таблицы (это всего лишь компромисс времени и памяти, который позволяет использовать предварительно вычисленную таблицу намного больше, чем умещается на жестком диске; таблица все еще требует хеширования каждого потенциального пароля). Пространственно-временные параллельные атаки и предварительно вычисленные таблицы - это одна и та же атака.
Соление побеждает разделение. Соль - это элемент данных public , который изменяет процесс хеширования (можно сказать, что соль выбирает хеш-функцию среди целого набора различных функций). Дело в том, что он уникален для каждого пароля. Злоумышленник больше не может делиться усилиями по взлому, потому что любая предварительно вычисленная таблица должна будет использовать определенную соль и будет бесполезна против пароля, хешированного с другой солью.
Соль должна использоваться для проверки пароля, поэтому сервер должен хранить для каждого хешированного пароля значение соли, которое использовалось для хеширования этого пароля. В базе данных это просто дополнительный столбец. Или вы можете объединить соль и хеш-пароль в одном двоичном объекте; это только вопрос кодирования данных, и это зависит от вас.
Предполагая, что S является солью (т.е. несколько байтов), процесс хеширования для пароля p равен: H '(S || p) ( с функцией H ', определенной в предыдущем разделе). Вот и все!
Соль в том, чтобы быть, насколько это возможно, уникальным для каждого хешированного пароля. Простой способ добиться этого - использовать случайные соли : всякий раз, когда пароль создается или изменяется, используйте генератор случайных чисел, чтобы получить 16 случайных байтов. 16 байтов должно быть достаточно, чтобы сделать повторное использование соли маловероятным. Обратите внимание, что соль должна быть уникальной для каждого пароля : использование имени пользователя в качестве соли недостаточно (некоторые отдельные экземпляры сервера могут иметь пользователей с одинаковым именем - сколько существует "bob") ? - а также, некоторые пользователи меняют свой пароль, и новый пароль не должен использовать ту же соль, что и предыдущий пароль).
3. Выбор хеш-функции
Хеш-функция H ' построена на хеш-функции H . В некоторых традиционных реализациях использовались алгоритмы шифрования, скрученные в хеш-функции (например, DES для Unix crypt()). Это способствовало использованию выражения «зашифрованный пароль», хотя оно не является правильным (пароль не зашифрован, потому что нет процесса расшифровки; правильный термин - «хешированный пароль»). Однако представляется более безопасным использовать настоящую хеш-функцию, предназначенную для хеширования.
Наиболее часто используемые хэш-функции: MD5, SHA-1, SHA-256, SHA-512 (последние две известны под общим названием "SHA-2"). Некоторые недостатки были обнаружены в MD5 и SHA-1. Эти слабые стороны оказывают серьезное влияние на некоторые использования, но не для того, что описано выше (слабые стороны касаются столкновений, тогда как мы работаем здесь над сопротивлением прообразу). Тем не менее, по связям с общественностью лучше выбрать SHA-256 или SHA-512: если вы используете MD5 или SHA-1, вам, возможно, придется оправдываться. SHA-256 и SHA-512 отличаются размером выходных данных и производительностью (в некоторых системах SHA-256 намного быстрее, чем SHA-512, а в других SHA-512 быстрее, чем SHA-256). Однако производительность здесь не является проблемой (независимо от внутренней скорости хэш-функции, мы делаем ее намного медленнее за счет повторений ввода), и 256 битов вывода SHA-256 более чем достаточно. Усечение вывода хеш-функции до первых n битов, чтобы сэкономить на хранении, является криптографически допустимым, если вы сохраняете не менее 128 бит ( n> = 128 ) .
4. Заключение
Всякий раз, когда вы создаете или изменяете пароль, генерируйте новую случайную соль S (16 байт). Затем хэшируйте пароль p как SHA-256 (S || p || S || p || S || p || ... || S || p) где шаблон ' S || p ' повторяется достаточно много раз, чтобы процесс хеширования занимал 10 мс. Сохраните S и результат хеширования. Чтобы проверить пароль пользователя, получите S , пересчитайте хэш и сравните его с сохраненным значением.
И ты будешь жить дольше и счастливее.