Comments 14
Да у вас в IT четверть всех проблем проистекает из того, что 10, 20 или даже 100 лет назад кто-то подумал: "этого будет достаточно для всех, никому никогда не понадобится больше". 5 битов в коде Бодо, 7 битов в ASCII-символе, 4 гигабайта в файле на FAT32, 65536 цилиндров на жестком диске, 32 бита в секундах системного времени...
А еще четверть проблем - из того, что кто-то подумал: "а вдруг кому-нибудь когда-нибудь понадобится больше".
Меня в конце чуток зацепил совет писать в лог длину введённого пароля. Для диагностики это удобно, но точную длину я бы всё-таки без надобности не хранил, т.к. auth-логи обычно живут долго и потом разъезжаются по куче систем. Вероятно, безопаснее писать просто ">72 bytes" или сам факт срабатывания проверки. Для поиска проблемы этого хватит, а лишняя информация о пароля нигде не выплывет.
Да, справедливо. Флага «длиннее лимита» тут и правда достаточно, само число ничего не добавляет.
У себя мы просто не принимаем такие пароли: форма отказывает сразу, и слишком длинная строка до хеширования не доходит. Тогда и в лог писать почти нечего.
Спотыкались мы там на другом: длину надо мерить в байтах, а не в символах. 30 кириллических символов — это уже 60 байт, так что на форме человек видит одно число, а упирается совсем в другое.
Да, тогда, пожалуй, ещё логичнее писать в лог не сам порог, а код причины вроде "password_too_long". Конкретные 72 байта всё-таки деталь bcrypt: если потом алгоритм поменяется, сам порог тоже может измениться. А причина отказа и для статистики останется понятной, и логи не будут привязаны к конкретной реализации.
Помню как на сайте Microsoft пароль втихаря резался то ли до 12 то ли до 16 символов. И я потом долго не мог понять почему я на сайт зайти могу, а через Миранду в их мессенджер ( MSN кажется ) не могу.
Что там было в новых правилах про запрет нейрослопа?…
Вы на полном серьёзе считаете что пароль в 72 символа это мало? Или пароль на КИРИЛИЦЕ в 36 символов это "ту лоу"? Но при этом прекрасно отдаёте себе отчёт что брутом пароль в 10 символов подобрать при нынешних мощностях практически нереально?
Страх за будущее и квантовые компутеры? Так там вроде бы длина пароля уже будет не важна.
Или статья просто для тех кто любит пароли 72+, про то что всё что больше 72 уже не важно? Но и тут не понятно - люди с такими паролями явно руководствуются чем то другим чем какая то там безопасность... Тут больше про психиатрию.
72 байта — это достаточно для защиты от взлома. Статья не утверждает обратного.
Проблема в другом: bcrypt тихо игнорирует всё, что длиннее 72 байт. Если пользователь ввёл пароль из 100 символов, система запомнит только первые 72. Пользователь думает, что его пароль уникален, а на самом деле последняя часть пароля не имеет значения.
Главная опасность — не взлом, а сбой при обновлении библиотек: новые версии Python-модуля bcrypt не обрезают пароль, а падают с ошибкой, если он длиннее 72 байт. Если у вас в форме нет ограничения длины — пользователи с длинными паролями не смогут войти после обновления.
Не. Главная опасность позади - криптографическая дыра. А явная ошибка = правильный способ ткнуть разрабов носом, чтобы фиксили.
Don't shoot the messenger, даже если он уронил прод. Только это натыкается на мантру "никогда, ни при каких условиях не падать, даже если совсем-совсем ошибка есть." Когда разраб рядом, пофиксить - прямая обязанность. А если нет?
Общий 72-байтовый префикс делает пароли неразличимыми. Сценарий надуманный ровно до тех пор, пока в компании не появляется корпоративный шаблон вроде длинного постоянного префикса плюс что-то в конце.
Может организации лучше менеджер пароля завести и начать использовать случайные пароли как и должно быть?
Зачем менять хвост если префикс останется?
Вы правы. В этом сценарии проблема не в bcrypt, а в самом корпоративном шаблоне: общий префикс не добавляет стойкости, хвост легко перебрать, и менеджер паролей здесь — правильное решение.
Статья приводит этот пример не как основную угрозу, а как иллюстрацию того, что неожиданное поведение bcrypt может накладываться на уже плохие пользовательские практики и создавать ложное ощущение уникальности.
Пользователь придумал пароль из 100 символов. От 28 из них ваша проверка не зависит