Максимальная длина пароля с bcrypt, blowfish
Мой вопрос проистекает из этого Как хэшировать длинные пароли (>72 символов) с blowfish
Я использую bcrypt(blowfish) для хэширования паролей. Итак, как я выяснил из этого вопроса https://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length
у него есть ограничение на количество персонажей 72.
Итак, я начал думать об ограничении максимальной длины пароля, но после этих вопросов и их ответов
Зачем ограничивать длину пароля?
Должен ли я установить максимальную длину для паролей?
Все сказано против этого. Упоминание вещей, как
- сохранить хранилище
- старый опыт системы Unix
- Взаимодействие с устаревшими системами, которые не поддерживают длинные пароли
- Конвенция (то есть "мы всегда так делали")
- Простая наивность или невежество.
- хранение в открытом тексте
- Также,
a maximum length specified on a password field should be read as a SECURITY WARNINGПо этому ответу - /questions/10183915/dolzhen-li-ya-ustanovit-maksimalnuyu-dlinu-dlya-parolej/10183942#10183942 - так далее
Итак, я не думаю, что я подхожу к одному из этих случаев. Конечно, я согласен с глупыми ограничениями, такими как максимальная длина 10 или, что еще хуже, 8 или 6, но разве пароли (соленые) с длиной 30, 40 или более считаются безопасными? Из этой статьи (хоть и немного старой), но там написано
it can make only 71,000 guesses against Bcrypt per second
И это для 8-символьных паролей. Итак, я представляю, насколько огромной будет пользовательская радужная таблица, которая будет грубо форсировать только один пароль длиной 30 или более символов (учитывая, что каждый пароль имеет свою собственную соль), так как размер радужной таблицы увеличивается экспоненциально
цитата из комментариев той же статьи
Каждый раз, когда вы добавляете персонажа в свой пароль, вы экспоненциально увеличиваете сложность взлома с помощью грубой силы. Например, 8-значный пароль имеет пространство клавиш 95^8 комбинаций, а 20-значный пароль имеет пространство клавиш 95^20 комбинаций.
Таким образом, для одного пароля длиной 20 с bcrypt, в соответствии с этим, будет необходимо 95^20 / (71 000 * 3600 * 24 * 365) ~ 10 х 28 градусов (если я все сделал правильно)
qsn1: Теперь, в этом случае с blowfish есть смысл НЕ ограничивать максимальную длину пароля 72, потому что в любом случае после этого все будет усечено, и, следовательно, здесь не будет никакого дополнительного усиления безопасности.
qsn2: Даже если соль существует (которая уникальна для каждого пользователя и сохраняется в БД), в конце концов я хочу добавить перец (который жестко закодирован в приложении, а не сохранен в БД) к паролю. Я знаю, если добавит немного дополнительной безопасности, но я считаю, на случай, если дБ (или резервная копия дБ) только утечка, перец будет полезен. /questions/31758368/obnaruzhenie-pikov-izmeryaemogo-signala/31758380#31758380 Итак, чтобы иметь возможность добавить, скажем, 20 символов перца, мне нужно сделать максимальную длину пароля примерно до 50. Я думаю так: допустим, пользователь при использовании 70 символов, в большинстве случаев (если не всех), это будет какая-то фраза или что-то в этом роде, а не сгенерированная сильная, поэтому не будет ли более безопасным ограничить пользователя максимальной длиной 50 и добавить еще 20-22 характерный перец, который определенно более безопасный / случайный. Кроме того, допустим, что хакер использует радужную таблицу "общих фраз", я думаю, что есть более высокие шансы, что 72 character common phrase будет взломан, чем 50 character common phrase + 22 character random string, Так лучше ли этот подход с перцем и максимальной длиной 50, или я что-то делаю неправильно, и лучше оставить максимальный предел в 72 (если qsn1 в порядке)?
Спасибо
КСТАТИ:
Согласно Оваспу, разумная максимальная длина пароля составляет 160 https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
Google имеет пароль макс. длина 100
WordPress имеет максимальный предел 50
2 ответа
Вопрос 1: Просто нет причин ограничивать длину пароля, BCrypt будет работать с гораздо более длинными паролями, хотя используется только 72 символа. У вас не будет никаких преимуществ, но теоретически вы будете мешать людям с менеджерами паролей использовать более длинные пароли. Если в будущем вы переключитесь на другой алгоритм, предел, вероятно, будет другим, поэтому нет причин ограничивать его 72 символами.
Вопрос 2: Вместо того, чтобы перетекать, вы могли бы лучше использовать другой подход: зашифровать хэш пароля с помощью ключа на стороне сервера. Причина добавления перца заключается в том, что злоумышленник должен получить привилегии на сервере, потому что без ключа он не сможет начать грубое хэширование (SQL-инъекция или выброшенные резервные копии базы данных не подойдут). То же преимущество вы получаете с помощью шифрования (двустороннего) хеша.
- Таким образом, вам не нужно резервировать символы для перца, вы можете использовать все 72 символа из пароля.
- В отличие от перца, ключ на стороне сервера может быть заменен всякий раз, когда это необходимо. Перец фактически становится частью пароля и не может быть изменен до следующего входа в систему.
- Другим обсуждаемым моментом является то, что перец теоретически может вмешиваться в хэш-алгоритм.
Помимо простого хеширования предоставленного пользователем пароля, есть и другие варианты использования для безопасного хэширования всей произвольно длинной строки с использованием bcrypt. Можно также посолить пароль перед его передачей в bcrypt для еще более высокого уровня энтропии.
Один алгоритм, который я использую, чтобы обойти ограничение по количеству символов, - использовать промежуточный хеш. Таким образом, вместо хеширования пароля напрямую, я использую более слабый механизм хеширования, который создает более короткую строку в пределах ограничения длины bcrypt, а затем хеширует эту промежуточную строку с использованием bcrypt. Промежуточный хеш не обязательно должен быть сильным, как bcrypt, хотя, если вы используете сильно рандомизированную и длинную соль, вы максимально увеличите эффективность этого подхода. Мой текущий промежуточный хэш - sha512.
Шаги, которые я использую для хэширования паролей, следующие:
- Создайте длинную криптографически безопасную соль, используя источник, такой как /dev/urandom. (Сделайте это для каждого пользователя. Вы также можете добавить соль для всего приложения, если хотите.) Вам нужно будет хранить эту соль, если вы планируете провести проверку пароля в будущем.
- Конкатенируйте соль с предоставленным пользователем паролем.
- Передайте объединенное значение sha512 и запишите результат, который будет представлять собой строку из 128 символов, представляющую шестнадцатеричное число.
- Чтобы добавить энтропию и использовать всю промежуточную соль, выполните цикл по всему хешу sha512, взяв пары шестнадцатеричных цифр, преобразовав значение пары в символ ascii и используя каждый символ для создания сжатого промежуточного хеша длиной 64 символа там, где есть 256 возможных символов.
- Введите окончательный сжатый промежуточный хеш в bcrypt с вашими предпочтительными параметрами (такими как стоимость) и запишите полученный хеш.
- Теперь у вас есть безопасный хеш, который полностью использует значение вашего длинного пароля.