Есть ли стандарт для использования PBKDF2 в качестве хэша паролей?

Присоединяйтесь ко мне в борьбе со слабыми хэшами пароля.

Хэш пароля PBKDF2 должен содержать соль, количество итераций и сам хеш, чтобы можно было позже проверить. Существует ли стандартный формат, например RFC2307 {SSHA}, для хэшей паролей PBKDF2? BCRYPT отлично, но PBKDF2 проще реализовать.

По-видимому, нет спецификации. Итак, вот моя спецификация.

>>> from base64 import urlsafe_b64encode
>>> password = u"hashy the \N{SNOWMAN}"
>>> salt = urlsafe_b64decode('s8MHhEQ78sM=')
>>> encoded = pbkdf2_hash(password, salt=salt)
>>> encoded
'{PBKDF2}1000$s8MHhEQ78sM=$hcKhCiW13OVhmLrbagdY-RwJvkA='

Обновление: http://www.dlitz.net/software/python-pbkdf2/ определяет замену crypt(). Я обновил свою маленькую спецификацию, чтобы соответствовать ему, кроме его стартов с $p5k2$ вместо {PBKDF2}. (Мне нужно перейти от других типов LDAP {SCHEMES}).

Это {PBKDF2}, число итераций в нижнем регистре шестнадцатеричных, $, urlsafe_base64 закодированная соль, $ и urlsafe_base64 закодированный вывод PBKDF2. Соль должна быть 64 бита, количество итераций должно быть не менее 1000, а выход PBKDF2 с выходом HMAC-SHA1 может быть любой длины. В моей реализации по умолчанию всегда 20 байтов (длина хэша SHA-1).

Пароль должен быть закодирован в utf-8 перед отправкой через PBKDF2. Нет слов о том, следует ли его нормализовать в Unicode NFC.

Эта схема должна быть порядка iterations раз более дорогостоящей для грубой силы, чем {SSHA}.

Ответ 1

Существует спецификация параметров (соль и итерации) PBKDF2, но она не включает хеш. Это включено в PKCS # 5 версии 2.0 (см. Приложение A.2). Некоторые платформы имеют встроенную поддержку для кодирования и декодирования этой структуры ASN.1.

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

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

Ответ 2

Я присоединяюсь к вам в борьбе со слабыми хэшами.

В OWASP есть Cheat Sheet (https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet) с некоторыми рекомендациями; они рекомендуют 64 000 итераций PBKDF2 по состоянию на 2012 год, удваивая каждые два года (т.е. 90 510 в 2012 году).

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

Обратите внимание, что наличие широко варьируемого количества итераций для каждого пользователя и сохранение количества итераций вместе с солью добавит некоторую сложность для взлома программного обеспечения и может помочь предотвратить определенные оптимизации. Например, "bob" зашифровывается с помощью итераций 135817, тогда как "alice" использует 95121 итераций, то есть, возможно, минимум (90510 + RAND (90510)) для 2013 года.

Обратите внимание, что все это бесполезно, если пользователям разрешено выбирать слабые пароли, такие как "пароль", "пароль1!", "P @$$ w0rd" и "P @$$ w0rd123", все из которых будут можно найти по правилам словарных атак очень быстро (последний - это просто "пароль" со следующими правилами: прописная первая буква, 1337-говорить, добавить трехзначное число до конца). Возьмите базовый список словарей (phpbb, для хорошего, небольшого стартового словаря) и примените к нему правила, подобные этому, и вы будете взламывать большое количество паролей, где люди могут попробовать "умные" трюки.

Поэтому при проверке новых паролей не просто применяйте "все четыре цифры верхнего, нижнего, цифрового, не менее 11 символов", так как "P @$$ w0rd123" соответствует этому, казалось бы, очень жесткому правилу. Вместо этого используйте этот базовый список словарей и посмотрите, могут ли его основные правила взломать (это намного проще, чем попытка пробить трещины - вы можете использовать свой список и их слово в нижнем регистре, а затем просто писать код типа "если последние 4 символа общий год, проверьте все, кроме последних четырех символов, на список слов", и "если последние 3 символа являются цифрами, проверьте все, кроме последних 3 символов, на список слов" и "проверьте все, кроме последних двух символов, на список слов", и "De-1337 пароль - превратите @в a, 3 в e и т.д., а затем проверьте его на список слов и попробуйте другие правила".

Что касается кодовых фраз, в целом это отличная идея, особенно если некоторые символы добавлены к середине слов, но если и только если они достаточно длинные, так как вы отказываетесь от многих возможных комбинации.

Обратите внимание, что современные машины с графическим процессором составляют до десятков миллиардов хеш-итераций (MD5, SHA1, SHA-256, SHA-512 и т.д.) в секунду, даже в 2012 году. Что касается словосочетания "правильная лошадь" Батарея штапельного типа", это, в лучшем случае, очень скромный пароль - всего четыре слова нижнего регистра длиной 7 или менее с пробелами. Итак, если мы ищем поисковые пароли XKCD с 18-миллиметровой догадкой второй установки: современный маленький англо-английский словарь имеет: 6k слов длиной 5 или менее 21k слов длиной 7 или менее 36k слов длиной 9 или менее 46k слов длиной 11 или менее 49 k слов длиной 13 или менее

С кодовой фразой в стиле XKCD и не утруждая себя фильтрацией слов по популярности ( "правильный" и "стул" против "дампье" против "геморрообразования" ), мы имеем 21k ^ 4, что составляет всего лишь 2E17 возможностей. С установкой 18 миллиардов/сек (единственная машина с 8 GPU, если мы сталкиваемся с одной итерацией SHA1), это около 4 месяцев, чтобы исчерпывающий поиск в пространстве ключей. Если бы у нас было десять таких установок, это примерно две недели. Если бы мы исключили маловероятные слова типа "dumpier", это намного быстрее для быстрого первого прохода.

Теперь, если вы получаете слова из "огромного" словаря linux american english, например "Balsamina" или "Calvinistically" (оба выбраны с помощью функции "перейти к строке", тогда у нас будет 30k слов длина 5 или менее 115 тыс. слов длиной 7 или менее 231 тыс. слов длиной 9 или менее 317 тыс. слов длиной 11 или менее 362 тыс. слов длиной 13 или менее

Даже с максимальным пределом длины 7 с этим огромным словарем как базовым и случайным образом выбранными словами мы имеем возможности 115k ^ 4 ~ = 1.8E20, или около 12 лет, если установка будет обновлена (удвоение мощности каждые 18 месяцев). Это очень похоже на пароль с 13 символами, нижний регистр + номер. "300 лет" - это то, что вам скажут большинство оценок, но они не учитывают закон Мура.