Вопрос или проблема
Okta выпустила уведомление о безопасности 4 дня назад, в котором говорится, что учетные записи с именем пользователя длиной более 52 символов могут входить в систему с произвольным паролем при определенных условиях. Некоторые пользователи в X/Twitter подозревают, что Okta использует userid + username + password в качестве входных данных для bcrypt.
Если это правда, тогда пароль будет игнорироваться bcrypt, если userid + username будет достаточно длинным.
Один из комментаторов предложил предварительно хэшировать входные данные с помощью SHA256 перед применением bcrypt, тем самым избегая проблемы с ограничением длины. Этот метод предварительного хэширования также упоминается (и обычно одобряется) в некоторых ответах на этом сайте (1,2).
Тем не менее, чек-лист OWASP недвусмысленно отговаривает от этого:
Альтернативный подход – предварительно хэшировать пароль, предоставленный пользователем, с помощью быстрого алгоритма, такого как SHA-256, а затем хэшировать полученный хэш с помощью bcrypt (т.е.
bcrypt(base64(hmac-sha256(data:$password, key:$pepper)), $salt, $cost)). Это опасная (но распространенная) практика, которой следует избегать из-за password shucking и других проблем при сочетании bcrypt с другими хэш-функциями.
Я не эксперт в области безопасности, поэтому ищу профессиональные мнения:
- Должен ли я строго избегать предварительного хэширования ввода для bcrypt с помощью другой хэш-функции, как упоминается в чек-листе OWASP?
- Буду ли я в серьезных проблемах (например, пароли легко взламываются), если я предварительно хэширую ввод для bcrypt с помощью SHA256?
- Кто-то на Reddit предлагает, что добавление соли к хэшу sha256 ПЕРЕД применением bcrypt может предотвратить password shucking. Это правда?
Существует обсуждение о использовании соли для защиты от password shucking в этом вопросе, который стоит прочитать.
Так что да, вы можете защититься от этого, используя соль. Однако вам нужно убедиться, что вы применяете соль к паролю, а не к хэшу. То есть, ваша конструкция должна быть bcrypt(sha256($password.$salt)), а не bcrypt(sha256($password).$salt).
Так что, если вы правильно применяете достаточно длинную и уникальную соль, и ваша реализация не имеет никаких проблем с такими вещами, как нулевые байты в выходе sha256 (и вы уверены, что это никогда не изменится), то с предварительным хэшированием пароля перед его bcrypt ничего строго неправильного нет.
Но если предположить, что вы просто хэшируете пароль пользователя (не делая что-то странное, добавляя его к концу имени пользователя/ID, как вы предложили в своем посте), то я бы сомневался, действительно ли вы что-то выигрываете по сравнению с просто соблюдением ограничения ввода в 72 байта (или сколько ваша реализация поддерживает).
И если вас беспокоит это ограничение длины ввода, то, вероятно, вам лучше будет перейти на argon2id (который не имеет практического ограничения длины ввода), а не добавлять сложности, пытаясь обойти ограничения bcrypt.
Ответ или решение
Вопрос: Строка перед хешированием пароля перед применением bcrypt для предотвращения ограничения длины пароля
Введение
Недавнее сообщение о безопасности от Okta всколыхнуло обсуждения в IT-сообществе, касающиеся выбора методов хеширования паролей. Как стало известно, учетные записи с именами пользователей длиной более 52 символов могут войти в систему с произвольным паролем при определенных условиях. Это вызывает сомнения в архитектуре, использующей комбинацию userid + username + password в процессе хеширования с использованием bcrypt. Критики предполагают, что длинные значения идентификатора и имени пользователя могут подавить обработку пароля, что ставит под сомнение целостность системы аутентификации.
Дискуссия о предхешировании
В качестве решения проблемы некоторые эксперты предлагают предхешировать ввод пароля с использованием алгоритма SHA-256 перед применением bcrypt, чтобы избежать проблем с ограничениями длины. Однако, согласно OWASP, такой подход не рекомендуется по следующим причинам:
- Увеличение уязвимости к атакам: Предхеширование может привести к проблеме, известной как "password shucking", когда злоумышленник может эффективно использовать предсказуемую структуру хешей для разрушения системы аутентификации.
- Комбинирование хеш-функций: Смешивание bcrypt, который был спроектирован для хранения паролей безопасным образом, с быстро вычисляемыми хеш-функциями создает дополнительные уязвимости.
Ответы на ключевые вопросы
-
Следует ли строго избегать предхеширования входа bcrypt с использованием другой хеш-функции?
Да, рекомендуется следовать рекомендациям OWASP и избегать предхеширования. Безопасность системы является наивысшим приоритетом, и любые варианты, увеличивающие риск несанкционированного доступа, должны быть отклонены. -
Буду ли я в серьезной опасности (например, пароли легко поддаются взлому), если я предхеширую ввод bcrypt с SHA256?
Использование SHA256 в качестве предхеширования может серьезно подорвать безопасность. Хотя это может показаться улучшением производительности, реализация словно создает новый вектор атаки, который может быть использован злоумышленниками для нахождения паролей. -
Сможет ли соль, добавляемая к SHA256 перед применением bcrypt, защитить от password shucking?
Соля можно использовать для улучшения безопасности, однако, она должна применяться к паролю, а не к его хешу. Таким образом, конструкция должна выглядеть какbcrypt(sha256($password.$salt)), а неbcrypt(sha256($password).$salt). Тем не менее, важно также понимать, что многие решения для хеширования паролей, такие как Argon2, предоставляют большую гибкость и безопасность, чем bcrypt, без ограничений на длину входных данных.
Заключение
Учитывая обсужденные аспекты, важно следовать принципам безопасного управления паролями, следуя рекомендациям авторитетных организаций, таких как OWASP. Интеграция методов, которые могут привести к дополнительным уязвимостям, не является целесообразным подходом. Вместо этого стоит рассмотреть возможность перехода на более современные алгоритмы хеширования, такие как Argon2, чтобы избежать ограничений и повысить безопасность пользователей.