В 2024 году я переводил исследование Hive Systems, лежащее в основе регулярно появляющихся в интернете цветных таблиц «времени взлома паролей». Тогда главным изменением по сравнению с предыдущими годами стал переход от MD5 к bcrypt, что приводило к парадоксальной картине: вычислительные мощности растут а скорость перебора уменьшается. Алгоритм bcrypt требует гораздо больше вычислений, чем MD5, но это не должно создавать иллюзию безопасности. В большинстве систем (в частности в Windows) алгоритмы по прежнему остались уровня MD5.
В июле 2026 года Hive Systems опубликовала очередное обновление. На этот раз авторы не только заменили оборудование, но и изменили саму модель нарушителя: вместо одной условной машины с большим количеством видеокарт используется реально арендуемый кластер из двух узлов с конкретной стоимостью аренды.
Новая работа интересна измеренными показателями и оценкой стоимости атаки. Но воспринимать цвет таблицы как оценку безопасности конкретного пароля по-прежнему нельзя. Более того, в тексте Hive Systems есть спорные и местами просто некорректные утверждения. Поэтому я отказался от идеи опубликовать просто перевод оригинальной статьи и сделал разбор методики, результатов и ограничений исследования.
Оригинал исследования: Are Your Passwords in the Green?, Corey Neskey, Hive Systems, 14 июля 2026 года.
Что именно показывает таблица
Начнём с самого важного ограничения. Таблица описывает не подбор пароля через форму входа на сайте, а офлайн-атаку.
Предполагается, что злоумышленник уже получил базу, содержащую хэши паролей. Он переносит её на собственное оборудование и проверяет варианты локально. В этой ситуации не действуют блокировка учётной записи, ограничение частоты запросов, CAPTCHA и уведомления о подозрительном входе: обращений к атакуемому сайту (или не сайту) вообще не происходит.
При этом Hive Systems моделирует очень специальный случай:
пароль сгенерирован случайно и равновероятно из заданного набора символов;
пароль раньше не встречался в утечках;
злоумышленник не знает о пользователе ничего, что помогло бы выбрать более вероятные варианты;
хэш получен с помощью bcrypt с параметром стоимости
cost = 10;перебор выполняется на 16 видеокартах RTX 5090;
в таблице указано время проверки всего пространства вариантов.
Итоговая таблица показывает верхнюю границу продолжительности полного перебора, чем прогноз времени раскрытия пароля. Если искомый пароль расположен в случайном месте пространства, математическое ожидание времени его нахождения примерно вдвое меньше. Для паролей, придуманных человеком, равномерное распределение отсутствует, поэтому и это упрощение обычно не работает.
Как менялась модель Hive Systems
Год |
Оборудование |
Функция и параметры |
|---|---|---|
2020 |
1 × RTX 2080 |
MD5 |
2022 |
8 × NVIDIA A100 |
MD5 |
2023 |
12 × RTX 4090 |
MD5 |
2024 |
12 × RTX 4090 |
bcrypt, cost 5 |
2025 |
12 × RTX 5090 |
bcrypt, cost 10 |
2026 |
2 узла по 8 × RTX 5090 |
bcrypt, cost 10 |
Сравнивать официальные таблицы разных лет напрямую нельзя. В 2024 году одновременно с оборудованием изменилась функция формирования хэша, а в 2025 году параметр bcrypt вырос с 5 до 10. Увеличение cost на единицу приблизительно удваивает вычислительную работу: значение 10 соответствует порядку 2^10, то есть 1024 внутренних итераций дорогостоящего преобразования.
Для сопоставления 2024–2026 годов Hive Systems отдельно пересчитала результаты 2024 года с cost = 10. Для случайного восьмисимвольного пароля, содержащего буквы обоих регистров, цифры и восемь выбранных специальных символов, получилось:
2024 год — 225 лет;
2025 год — 164 года;
2026 год — 132 года.
Изменение расчётного времени полного перебора в 2024–2026 годах при сопоставимых параметрах bcrypt. Источник: Hive Systems.
В этом сравнении параметры bcrypt одинаковы, поэтому уменьшение времени действительно характеризует рост доступной нарушителю производительности.
Почему теперь используется 16 видеокарт
Раньше Hive Systems рассматривала одну машину с двенадцатью GPU. В 2026 году авторы попытались арендовать подобную конфигурацию и обнаружили, что на рынке Vast.ai доступны главным образом узлы с восемью RTX 5090. Вместо одной редкой машины они арендовали два восьмикарточных узла и разделили пространство вариантов между ними.
Измеренная суммарная производительность составила 138 675 H/s для bcrypt cost 10. Это примерно на 24 % больше прошлогоднего ориентира в 111 490 H/s для двенадцати RTX 5090.
Максимальное время полного перебора случайных восьмисимвольных паролей на различном оборудовании. Используется bcrypt cost 10. Источник: Hive Systems.
Такой подход реалистичнее прежнего: полный перебор хорошо распараллеливается. Разным узлам можно назначить независимые диапазоны паролей, почти не обмениваясь данными между ними.
Важно и другое наблюдение. Увеличение количества арендованных узлов сокращает календарное время атаки, но при линейной тарификации почти не уменьшает её общую стоимость. Нарушитель покупает скорость получения результата, а не более дешёвое вычисление каждого варианта.
Откуда берутся 132 года
В правом столбце таблицы Hive Systems используются:
26 строчных латинских букв;
26 прописных латинских букв;
10 цифр;
8 специальных символов:
^*%$!&@#.
Всего получается 70 возможных символов. Для пароля длиной восемь символов пространство составляет:
70^8 = 576 480 100 000 000 вариантов.
Если проверять 138 675 вариантов в секунду, полный перебор займёт:
70^8 / 138 675 ≈ 4,157 млрд секунд ≈ 132 года.
Проверка нескольких других ячеек даёт следующие значения:
Случайный пароль |
Полное пространство |
Максимальное время |
|---|---|---|
8 цифр |
|
около 12 минут |
8 строчных латинских букв |
|
около 17 дней |
8 латинских букв обоих регистров |
|
около 12 лет |
8 символов из набора из 70 знаков |
|
около 132 лет |
10 строчных латинских букв |
|
около 32 лет |
12 строчных латинских букв |
|
около 21,8 тыс. лет |
15 цифр |
|
около 228 лет |
Эти расчёты одновременно показывают пользу и опасность таблицы. Она хорошо демонстрирует экспоненциальный рост пространства вариантов, но результат зависит не только от длины, а сразу от трёх независимых обстоятельств:
как сформирован пароль;
как он хранится на стороне сервиса;
какими ресурсами располагает нарушитель.
Пользователь контролирует главным образом первый пункт. Функцию хэширования и её параметры выбирает владелец информационной системы.
Интерактивный калькулятор
По мотивам исследований Hive Systems я сделал онлайн-калькулятор времени полного перебора паролей. В отличие от статической инфографики, он позволяет менять исходные параметры и сразу видеть, насколько результат зависит не только от длины пароля, но и от алгоритма хранения и оборудования нарушителя.
В калькуляторе можно выбрать:
алгоритм или формат хэша — от MD5 и NTLM до bcrypt с разными значениями cost, Argon2id, scrypt, PBKDF2 и хэшей, используемых в Wi-Fi и базах данных;
модель GPU и количество видеокарт;
диапазон длины пароля;
набор допустимых символов.
Результат можно представить в виде цветной таблицы и выгрузить в PNG. Калькулятор использует ту же базовую модель T = N^L / R и показывает максимальное время полного перебора случайного пароля при офлайн-атаке. Вводить в него свой настоящий пароль не требуется: сервис рассчитывает пространство вариантов по выбранным параметрам, а не анализирует или проверяет переданную секретную строку.
Калькулятор полезен и для демонстрации ограничений подобных таблиц. Например, можно оставить длину неизменной и увидеть, насколько результат меняется при переходе от NTLM к bcrypt или Argon2id. Это наглядно показывает, почему вопрос «насколько надёжен мой пароль?» нельзя отделить от вопроса «как именно сервис хранит пароли?».
Сколько стоит такой перебор
По данным Hive Systems, два узла по восемь RTX 5090 стоили суммарно приблизительно 8,54 доллара в час.
Полный перебор восьмизначного PIN (авторы называют PIN-ом цифровой пароль,) занимает около 12 минут и обходится примерно в 2 доллара. Для восьми случайных строчных букв требуется около двух недель и приблизительно 3400 долларов аренды.
Однако эту оценку нельзя автоматически переносить на похищенную базу из миллионов хэшей. При проверке одного кандидата bcrypt должен вычисляться отдельно для каждой соли, что существенно ограничивает эффект массовой атаки. Соль не делает слабый пароль сильным, но не позволяет один раз вычислить результат и бесплатно сопоставить его со всеми учётными записями.
Возможность потратить тысячи долларов на один конкретный хэш зависит от ценности цели. Для массовых утечек рациональная стратегия совсем другая: сначала проверяются распространённые пароли, словари, утёкшие комбинации и типовые преобразования.
Почему реальный пароль может раскрыться за секунды
Главная таблица предполагает равномерный перебор случайных строк. Настоящие атаки начинаются не с aaaaaaaa, после чего механически переходят ко всем последующим комбинациям.
Сначала проверяются:
пароли из прежних утечек;
словарные слова и их сочетания;
имена, даты и названия;
клавиатурные последовательности;
замены наподобие
a→@,s→$;добавление года, цифры или восклицательного знака;
варианты, построенные с учётом сведений о конкретном пользователе.
Для ранее украденных, повторно используемых и предсказуемых паролей основная таблица полного перебора неприменима. Источник: Hive Systems. В 2026 году Hive Systems впервые дополнила теоретическую фиолетовую таблицу практическим измерением. На одной арендованной RTX 5090 пароль вида o#mA24ft был найден примерно за три секунды, когда вместо полного перебора использовались приоритетные догадки. Сходный результат авторы получили при атаке на распространённый пароль с помощью списка rockyou.txt и правил Hashcat.
Этот опыт не означает, что любой восьмисимвольный пароль раскрывается за три секунды. Он показывает другое: внешне сложная комбинация может иметь очень низкую фактическую энтропию, если она получена предсказуемым способом.
Повторное использование пароля ещё опаснее. Если исходная строка уже раскрыта в одной утечке, на другом сайте её вообще не требуется подбирать — достаточно проверить готовую пару логин–пароль.
Ускоряет ли ИИ подбор паролей
Hive Systems уделяет ИИ отдельный раздел, но здесь полезно разделить две разные задачи.
Нейросеть не увеличивает физическую скорость вычисления bcrypt на одной видеокарте. Для полного перебора требуется выполнить определённое количество однотипных операций; рассуждения языковой модели эту работу не заменяют. Специализированная игровая GPU при такой задаче может оказаться эффективнее дорогостоящего ускорителя, оптимизированного под обучение нейросетей.
Однако ИИ снижает организационный порог:
помогает написать скрипты управления арендованными узлами;
разделить маски и диапазоны между машинами;
контролировать выполнение заданий;
подготовить правила и более вероятные кандидаты;
использовать контекстную информацию о цели.
Иначе говоря, ИИ почти не меняет скорость одного вычисления bcrypt, но помогает нарушителю быстрее собрать инфраструктуру и умнее определить порядок догадок. В исследовании Hive Systems именно первый эффект стал одним из обоснований перехода от единой машины к распределённому кластеру.
А что с квантовыми компьютерами
Раздел Hive Systems о квантовых вычислениях требует осторожного пересказа.
Алгоритм Шора представляет будущую угрозу для широко применяемой криптографии с открытым ключом — RSA и схем на эллиптических кривых. Алгоритм Гровера теоретически даёт квадратичное ускорение поиска по неструктурированному пространству, а не экспоненциальный выигрыш.
Из этого не следует, что bcrypt можно объявить «квантово-устойчивым методом шифрования», как фактически делает исходная статья. Во-первых, bcrypt — не шифрование, а функция формирования производного значения пароля. Во-вторых, перенос абстрактной оценки Гровера на реальную стоимость атаки против bcrypt требует учитывать огромные затраты на отказоустойчивые квантовые вычисления и реализацию обратимого алгоритма. Современных машин, способных выполнить такую атаку, не существует.
Поэтому квантовая тема не меняет практические выводы таблицы 2026 года. Для долгоживущих данных действительно важен переход на постквантовые алгоритмы шифрования и электронной подписи, но выбор длинного уникального пароля и корректной функции его хранения остаётся отдельной задачей.
Почему в 2026 году восемь символов — уже не «рекомендация NIST»
Hive Systems несколько раз называет восемь символов минимальной длиной, рекомендованной NIST. Для актуальной редакции требований это неверно.
NIST SP 800-63B-4 устанавливает:
не менее 15 символов, если пароль используется как единственный фактор;
не менее 8 символов, если пароль применяется только как часть многофакторной аутентификации;
поддержку максимальной длины не менее 64 символов;
отказ от обязательных правил состава вроде «одна прописная буква, одна цифра и один специальный символ»;
проверку нового пароля по перечню распространённых, ожидаемых и скомпрометированных значений;
отсутствие периодической смены пароля без признаков его компрометации.
Таким образом, строка из восьми символов в таблице полезна как наглядный пример расчёта, но не как практическая рекомендация пользователю или разработчику.
Почему выбран bcrypt и стоит ли выбирать его сегодня
Количество опубликованных наборов данных с паролями в разбивке по известному типу хеша. Данные Have I Been Pwned, обработка Hive Systems. Hive Systems анализирует наборы утечек, каталогизированные Have I Been Pwned, и приходит к выводу, что среди идентифицированных способов хранения в последние годы часто встречается bcrypt. Для сравнимости с 2025 годом авторы оставили cost = 10.
Это реалистичный консервативный сценарий, но не эталон современной реализации. OWASP рекомендует для новых систем прежде всего Argon2id. scrypt рассматривается как следующая альтернатива, а bcrypt — главным образом как вариант для устаревших систем, где Argon2 и scrypt недоступны. Для bcrypt OWASP указывает минимальный cost 10, но фактическое значение должно выбираться с учётом допустимого времени проверки на оборудовании конкретной системы.
Называть bcrypt полноценно memory-hard-функцией также не следует. В отличие от Argon2id и scrypt, защита bcrypt в основном основана на вычислительно дорогом расписании ключей и сравнительно небольшом фиксированном объёме памяти. Именно противодействие массовому параллелизму за счёт настраиваемой стоимости памяти стало важным преимуществом более новых функций.
У bcrypt есть и практическое ограничение: многие реализации обрабатывают не более 72 байт входных данных. Для Unicode-пароля количество байт и количество отображаемых символов могут существенно различаться.
Ограничения таблицы Hive Systems
Перед использованием инфографики в обучении или парольной политике стоит явно проговорить её ограничения.
Рассматривается только офлайн-атака на уже похищенный хеш. Таблица ничего не говорит о фишинге, вредоносном ПО, перехвате сессии, восстановлении доступа или атаке на MFA.
Пароль считается случайным. Для строк, придуманных человеком, цвет ячейки может создавать ложное чувство защищённости.
Показано максимальное время полного перебора. Это не среднее и тем более не гарантированное время раскрытия.
Результат относится только к bcrypt cost 10. Для MD5, NTLM, PBKDF2, Argon2id и даже bcrypt с другим cost цифры будут другими.
Выбор bcrypt основан на публично известных утечках. Такие данные подвержены смещению выборки: неизвестные или не опубликованные инциденты в статистику не попадают.
Набор символов искусственно ограничен. В правом столбце учтены только восемь специальных символов, а Unicode, включая кириллицу, исключён.
Не учитывается парольная политика конкретного сервиса. Пользователь часто не знает ни алгоритма хранения, ни его параметров, ни качества реализации.
Модель стоимости ориентирована на одну выбранную облачную площадку и конкретный момент времени. Доступность оборудования и тарифы меняются.
Практические выводы
Пользователю
Использовать уникальный пароль для каждого сервиса.
Генерировать случайные пароли менеджером паролей, а не составлять их по запоминаемому шаблону.
Для единственного фактора ориентироваться как минимум на 15 символов; при возможности выбирать более длинные значения.
Проверять пароли на наличие в известных утечках, не передавая их сторонним сайтам в открытом виде.
Включать MFA, предпочтительно устойчивую к фишингу, либо использовать passkeys.
Менять пароль при компрометации, а не по календарю.
Владельцу информационной системы
Разрешать длинные пароли, пробелы и Unicode; не обрезать введённое значение незаметно для пользователя.
Не требовать искусственного набора классов символов и плановой смены без основания.
Сверять создаваемые пароли с блок-листом распространённых и скомпрометированных значений.
Ограничивать частоту онлайн-попыток, но не считать это заменой безопасному хранению паролей.
Предлагать фишинг-устойчивую MFA и passkeys.
Разработчику
Для новой системы выбирать Argon2id с параметрами, соответствующими актуальным рекомендациям и возможностям сервера.
Если используется bcrypt, подбирать cost по результатам измерений, использовать уникальную случайную соль и учитывать ограничение длины входа.
Предусматривать обновление параметров и перехеширование после успешной аутентификации.
Рассмотреть дополнительный секрет
pepper, хранящийся отдельно от базы паролей.Проектировать защиту так, как будто база хешей однажды может быть похищена.
Вместо вывода
Таблица Hive Systems остаётся хорошей иллюстрацией одного принципа: при случайной генерации каждый дополнительный символ резко увеличивает пространство перебора, а развитие оборудования постепенно сокращает имеющийся запас прочности.
Но цвет ячейки не является оценкой безопасности учётной записи. Случайный восьмисимвольный пароль из полного набора символов действительно потребует до 132 лет полного перебора в модели Hive Systems. Внешне похожий пароль, придуманный человеком, может раскрыться за секунды. А уникальный длинный пароль не защитит от фишинга или кражи активной сессии.
Поэтому практическая формула 2026 года выглядит не как «добавьте цифру и специальный символ», а так:
длинный случайный уникальный пароль + менеджер паролей + фишинг-устойчивая MFA или passkey + корректное хранение на стороне сервиса.
Источники
Corey Neskey. Are Your Passwords in the Green?. Hive Systems, 2026.
NIST. SP 800-63B-4: Authentication and Authenticator Management.
OWASP. Password Storage Cheat Sheet.
Provos N., Mazières D. A Future-Adaptable Password Scheme. USENIX, 1999.
Иван Земцов. Калькулятор времени полного перебора паролей. Секьюритика.
Комментарии (19)
Oieth
22.07.2026 11:05И разъясните, пожалуйста, вот эту мысль:
NIST SP 800-63B-4 устанавливает:отсутствие периодической смены пароля без признаков его компрометации.
То есть, выполнив проверку компрометации и не найдя признаков компроментации - становится не нужно периодически менять пароль? Чем периодическая смена пароля плоха, если не было компроментации?
mosinnik
22.07.2026 11:05очевидно же что "новые" пароли это старые плюс какойто другой символ (как правило цифра, что упрощает подбор) или замена последнего из набора, а если доступна ротация через 3-4 пароля, то они крутят по кругу. И имея историю и учитывая что там скорее всего одинаковый префикс вломать становится еще легче. А вообще эта процедура лишь задалбывает юзера и он выдумывает пароли еще проще или начинает их зааписывать на бумажки, чтоб вместо привычного ему одного сложного пароля не запоминать еще какойто набор.
Oieth
22.07.2026 11:05нет, не очевидно. новый пароль это новый пароль, только и всего.
Если пользователь использует старый пароль + инкремент - это не означает, что так делают все. Так поступают только ленивые и неосмотрительные. Пароль не обязан включать предыдущий. Если пользователь не понимает, что этим он упрощает подбор - это другой разговор. Он по сути пренебрегает принципом создания пароля.
Другими словами - вы могли бы и в первом пароле пренебречь чем нибудь. Давайте из-за этого откажемся еще от какой-нибудь практики.Почему если неосмотрительные пользователи чем-то пренебрегают - это повод вовсе отказаться от практики смены пароля? Спрашиваю, потому что искренне интересен этот вопрос. Есть что почитать по теме отказа от периодической смены пароля?
В моем понимании, если не обновлять пароль - нарушается другой принцип, что скорость грубого подбора пароля ограничена и если менять пароль, например, раз в 3 месяца, брутфорс пароля испытывает более жесткие временные ограничения. Бонусом идёт то, что при смене пароля - все остальные активные сессии (которые пользователь мог не заметить) - также истекают.
Тем более, в самой статье говорится о том, что проверка на компрометацию базируется на публичных наборах данных. А существуют еще свежие или не публичные наборы.
mosinnik
22.07.2026 11:05это для вас новый пароль в достаточной степени отличается от старого, для рядового юзера новый пароль это просто "не такой же как старый"
Так поступают только ленивые и неосмотрительные.
да так оно и есть, вы просто видимо не в курсе на сколько люди в своем большинстве ленивы и неосмотрительны))
Другими словами - вы могли бы и в первом пароле пренебречь чем нибудь. Давайте из-за этого откажемся еще от какой-нибудь практики.
Да давайте так и сделаем! Например откажемся сначала от требования к сложности и длине пароля если есть OTP/смс/другой код как второй фактор, если это вход в рабочую учетку где есть только экселька с номерами контрагентов)
В моем понимании, если не обновлять пароль - нарушается другой принцип, что скорость грубого подбора пароля ограничена и если менять пароль, например, раз в 3 месяца, брутфорс пароля испытывает более жесткие временные ограничения. Бонусом идёт то, что при смене пароля - все остальные активные сессии (которые пользователь мог не заметить) - также истекают.
Это видимо идет из заблуждения, что проблема в пароле. Но проблема не в пароле, а что у вас/у когото свиснули бд с шифрами паролей. Или может быть даже логи с открытыми паролями. И это как раз теперь называется компрометацией, если нашли что по юзеру (связку с его телефоном, фио, почтой) появился пароль в открытом доступе и его хеш совпал с тем что у вас в бд - надо оповестить юзера. Не надо считать, что любой пароль любого пользователя становится скомпрометирвоанным только лишь изза источения трех месяцев с момента создания в ВАШЕЙ системе. Этот пароль сам по себе уже мог существовать десяток лет и использоваться в сотнях сервисов очень сомнительного ИБ уклада и мог быть тыщи раз слит и использоваться сразу после регистрации этого пользователя в вашей системе.
Как у вас проводится процесс проверки на компрометацию во таких вот древних паролей при первом его использовании?
Oieth
22.07.2026 11:05Это видимо идет из заблуждения, что проблема в пароле.
Нет, ну я понимаю, что в статье рассматривается стилинг, а не брутфорс. Просто отказ от практики периодической смены пароля аффектит именно брутфорс. Его ведь никто не отменял.
Не надо считать, что любой пароль любого пользователя становится скомпрометирвоанным только лишь изза источения трех месяцев с момента создания в ВАШЕЙ системе.
Я этого не говорил. Каждые 3 месяца обновлять пароль не потому, что он скомпрометирован. А потому что за 3 месяца мало что успеют набрутфорсить.
Смена раз в 3 месяца - это аргумент на физические ограничения мира, которые трудно преодолеть. Вы не сможете нарастить мощность брутфорса внезапно настолько, что вчера брутили бы пароль мощнейшими средствами 300тыс. лет, а сегодня 1 месяц.
mosinnik
22.07.2026 11:05Не могу нарастить, но могу просто продолжать с того места где остановился. Если у меня конкретная цель для атаки и она поменяла работу и на новом месте взяла свой базовый пароль, то у меня на брутфорс не 3 месяца, а уже 6 месяцев с учетом проделанной работы по предыдущему месту. А если как в моем примере этот же пароль уже используется в тех системах, где нет вашего требования в 3 месяца, то это уже годы, а если их много и можно параллельно бить то вообще тысячелетия, и мне как атакующему достаточно отслеживать факт смены работы или регистрации в новой системе.
Опять же вы зациклены на атаке вашей системы и не берете в расчет, что пароль уже брутфорсят в другом месте и дольше чем вы ему отпустили, на момент когда юзер его укажет у вас в системе он уже может быть скомпрометирован. Вопрос только когда атакующий сделает новый цикл обхода и воспользуется - и у него по вашей же политики теперь есть аж целых три месяца на это)
Поэтому сначала надо исключить факт компрометации пароля пользователя, хотя бы по открытым базам. Потом периодически мониторить появление таких баз и оповещать пользователей о потенциальных проблемах.
Oieth
22.07.2026 11:05Ваша цель для атаки меняет пароль хранилища с деньгами раз в 3 месяца, независимо от места работы.
При этом сама присылает вам все свои старые пароли за последний год:
054а!12a
3536а@37F
#756737F
$7356737FВаши действия? Вы начали брутить. Прошло 3 месяца, пароля вы не подобрали, но уже появился новый пароль. Вы считаете, что можете продолжить со старого места? Почему?
Чтобы взломать пароль, основываясь на подходе, описанном здесь - нужно, помимо прочего, сделать удачное предположение о принципе построения пароля. Угадаете принцип?
Мы точно не расходимся в определениях? Что вы называете брутфорсом?
mosinnik
22.07.2026 11:05точно расходимся, я про людей которые ленивы и они не ибшники-параноики. Буду рад ошибаться, но по всяким отчетами о "самых популярных паролях" склонен считать именно так.
Если мне присылают пароли в открытом виде, ну ок это повод попробовать их в других сервисах по учеткам этого человека, попробовать сузить объем перебора, выявив схему. Ну а в контексте начала топика такой пароль считается скомпрометированным и как минимум вы в своей системе должны его пометить таким, чтобы недопустить его использовании например на ротации или в качестве префикса.
Брутфорс - подбор простым перебором, конечно я понимаю что есть всякие 3 попытки, капчи, таймауты и т.п. - будем считать, что брутфорс в современном мире невозможен)
Oieth
22.07.2026 11:05Вы как-то постоянно влево отвечаете.
Вы пишете:
Не могу нарастить, но могу просто продолжать с того места где остановился.
Что конкретно вы продолжите? Я вам говорил, про брутфорс пароля, который вы не сможете продолжить. Как можно продолжить брутфорс пароля, который сменился?
Вы мне отвечаете про продолжение попыток угадать принцип построения нового пароля, что не является брутфорсом.
Я вам предложил угадать принцип построения пароля. Вы же хотели выявить схему? Вот, пожалуйста. Выявляйте схему. Для этого привел пример черытёх паролей с очень простым принципом. Принцип был: зима, весна, лето, осень, остаток деления года на мой возраст, номер буквы в слове Альфа на латиннице, гласные прописными, согласные заглавными.
Сколько вы будете угадывать такой принцип? Разумеется, это не мой принцип, и никому не рекомендую его использовать (считайте, что когда я это написал - принцип скомпрометирован).
Но помня только этот принцип можно раз в 3 месяца генерить новые пароли, не входящие в предыдущий пароль.
Сольют мой пароль зимний? Ну пускай. Мне система сообщит, что пароль скомпрометирован (я же не спорю, что это тоже нужно делать) и я сменю его на новый, составленный по тому же принципу. Я не забуду пароль никогда, потому что я помню принцип составления и в любой момент времени руководствуясь только им могу восстановить в памяти свой пароль.
Периодическая смена пароля здесь ничем не вредит при таком принципе построения пароля. Периодическая смена вредит только тем, кто ленив.
А принцип составления может быть гораздо сложнее, может иметь более слабую привязку к персоне (вместо возраста использовать любое другое изменяющееся число, которое человек помнит, а постороннему это число ассоциировать трудно). Солнце погаснет раньше, чем вы угадаете остаток от деление чего на что используется в пароле. И ваш единственный путь - брутфорсить такой пароль.
Но тут вы предлагаете отказаться от периодической смены пароля, надеясь на то, что мой пароль сольют и тогда мне система сообщит. А если мой пароль не сольют? Тогда система не сообщит? И получается, однажды очень нескоро, но пароль забрутфорсят, когда выйдет очередная GTX9090, которых объединят в кластер из 256 штук?
Так зачем отказыватсья от периодической смены пароля? Потому что это действует на нервы пользователям? А мыть руки после туалета им не действует на нервы?
mosinnik
22.07.2026 11:05Эка вас задело) Я отвечаю с учетом того, что написал ранее, а не только на ваши ограниченные ситуации. Если берем изолированную ситуацию со сменой паролей по вашему описанию - да атаки лишены смысла, это очевидно и я с этим не спорю. Но в реальности не бывает полной изолированности.
Что конкретно вы продолжите? Я вам говорил, про брутфорс пароля, который вы не сможете продолжить. Как можно продолжить брутфорс пароля, который сменился?
Вы считаете что конкретный пароль использовался только в одной системе, я же считаю что этот пароль может использоваться в любой системе - в моей парадигме если в вашей системе после смены пароля не существует, то в моей с некоторой вероятностью все еще есть системы, где этот пароль используется и там можно продолжать атаки.
Вы мне отвечаете про продолжение попыток угадать принцип построения нового пароля, что не является брутфорсом.
Именно разгадывание принципа не сама цель, но если будут очевидные закономерности то почему нет? Это лишь один из вариантов упрощения, как ограничение алфавита для брутфорса - это тоже хорошее подспорье.
Так зачем отказыватсья от периодической смены пароля? Потому что это действует на нервы пользователям? А мыть руки после туалета им не действует на нервы?
Не хотите не отказывайтесь, продолжайте мучить своих пользователей как тысячи других ИБ-шников)
Но на вопрос как часто вы проводите работы по выявлению наличия скомпрометированных паролей у учеток так и не ответили.
Oieth
22.07.2026 11:05с некоторой вероятностью все еще есть системы, где этот пароль используется и там можно продолжать атаки
какие другие системы? ассоциированные со мной, с моим логином? в них будет другой пароль. Эти четыре пароля были для альфы. В райфе будет другая часть, отвечающая за райф. А может и вовсе другой принцип построения пароля - такой принцип я могу использовать только для мест, хранящих деньги. А места для общения (форумы, мессенжеры) составляю другим принципом. Да даже если и такой же принцип - вам еще надо угадать, как именно пароль для Альфы применяется в Альфе.
Или пароль использовался в других системах не мной, кем-то еще? ну да, наверняка так и есть с большинством паролей. Только тут уже я не понимаю - что это даёт вам в отношении моего аккаунта? Более точный словарь? Ну так это возвращает нас к теме брутфорса. Что возвращает опять же к тому, что было бы неплохо сильно зарезать время на этот самый брутфорс.
Ваша гипотеза о том, что этот же пароль подойдёт в других системах - попадает только в тех людей, которых я считаю ленивыми. Их лень состоит не в том, чтобы помнить 500 разных паролей. А в том, что они ленятся создать 1 универсальный, понятный только им одним, принцип, который откроет 500 разных дверей пятьюстами разными ключами.
Но на вопрос как часто вы проводите работы по выявлению наличия скомпрометированных паролей у учеток так и не ответили.
Тут я должен признаться, я не ИБ-специалист. Просто интересуюсь этой темой. Я продуктовый аналитик. В моей организации проверки проводят, но по поводу регулярности не могу сказать, не знаю. Меняем пароли периодически. Да, поначалу есть раздражающий момент. Но детей тоже раздражают гигиенические привычки. Ничего страшного, со временем понимаешь, как с этим жить и как это сделать удобнее.
mosinnik
22.07.2026 11:05Это реально классно, что вы выработали для себя серьезный подход к паролям и следуете ему. Для людей с такой ответственностью и не требуется делать принудительную смену пароля, т.к. человек сам все поменяет изза подхода.
Но отвечу классическое для такой ситуации - не мерьте по себе, вы удивитесь на сколько люди действуют отлично от вашего и как их много) И именно на них нацелены простые атаки аля перебор по словарю уже утекших паролей и то про что я писал выше с атакой сразу во все сервисы где есть человек.
И вот чтобы такие люди совсем уж херню не творили со своими паролями по типу записывания на стикере под монитором надо их максимально разгружать в части придумывания и запоминания.
Oieth
22.07.2026 11:05Ну, может быть. Просто сильно хотелось ответить, что таких не жалко. Или скорее даже - на таких людей не напасёшься методик. Сначала создаёшь для них золотой ключ, а они его прячут под коврик.
Часть меня верит только в то, что таких только жизнь исправит. И что надо просто прожить как-то этот период, примерно как люди прожили период без антибиотиков и обезболивающих.
Но с другой стороны, конечно, сервис хочет быть удобным и не хочет раздражать людей. Или сделать так, чтобы безопасность не зависела от выбора людей. В этом отношении, стремление понятно.
Как и многое другое в наших профессиях - это какие-то качели, где явного ответа нет, учебник пишется прямо сейчас и придется выстрадать баланс.
mosinnik
22.07.2026 11:05SSO/OID/OAuth и т.п. как раз решают задачу для такого большинства, предоставляя удобный способ один раз заморочиться и потом лишний раз не думать о паролях. И я чтото не видел ни одного глобального SSO, в котором надо было бы менять пароль периодически
Oieth
22.07.2026 11:05глобальные сервисы сейчас (как указывается в мотивировочной части этого исследования) находятся под впечатлением от аругмента "не надо задалбывать пользователей".
Не думаю, что если вы имеете дело с задалбывающимися пользователями - они будут задалбываться только менять пароль. Они еще будут задалбываться помнить его. Будут записывать на бумажку, себе в телегу, будут пользоватся сомнительными менеджерами паролей. Будут задалбываться придумывать разные пароли для разных ресурсов. Будет задалбывать спецсимволы и нажимать шифт для регистра. Их вообще многое будет задалбывать. Сама концепция пароля их может задолбать. Если пользователь вот такой, на расслабоне, то это во всем будет проявляться.
OID и Oauth перекладывает ответственность проверки на другой ресурс. Но это делает утечки более болезненными. Плюс, как мы видим, OID это ведь вопрос доверия. Мы долго доверяли одному G-сервису, а потом вмешалась жизнь и оказалось, что доверять теперь запрещено. Ему на смену появится локальная замена. Мы начнем ей доверять. А надо ли? А как тогда быть с OID, если доверять не получается? Тут уже в другую тему легко уйти. Не будем сейчас.
Мотивировочная часть исследования ставит задалбывание пользователя как основной мотив, но сама методика решает только одну узкую проблему. Пренебрегая чем-то одним, будут пренебрегать и другими аспектами. Вы ничего не сможете противопоставить против бумажного стикера на мониторе с паролем. Это лечится только обучением и цифровой гигиеной.
Но вы правы. Всех так сразу не обучишь. Их обучит жизнь. Цель ведь даже не в том, чтобы таких людей вовсе не было. Достаточно, чтобы их было настолько мало, чтобы воровать таким способом стало не рентабельно. Сейчас, например, мало кто ворует магнитолу. Потому что куда её потом девать. И не стоит оно того. Вы возразите, что и магнитолы стали другими. Да. Но вот компромисс где-то посередине. Люди должны поменяться, системы аутентификации тоже. Но без изменения людей мало что получится.
Zemcoviv Автор
22.07.2026 11:05Одно из первых крупных исследований по теме: Zhang, Monrose, Reiter, 2010 — The Security of Modern Password Expiration
Авторы исследовали историю паролей более чем 7700 университетских учётных записей и моделировали атакующего, знающего старый пароль.
Результаты:
17% новых паролей угадывались в пределах пяти онлайн-попыток;
41% — за несколько секунд офлайн-анализа;
если пользователь уже применял предсказуемые преобразования, последующие пароли удавалось восстановить ещё чаще.
Вывод авторов: эффективность принудительного истечения паролей в достижении заявленной цели невелика.
MonkAlex
Но о ней надо знать? А без этого менять можно 0 раз и считать что всё хорошо?
Zemcoviv Автор
Всё верно, о компрометации надо знать. Но я бы уточнил два момента: компрометация отслеживается проще, чем нарушение конфиденциальности; события компрометации происходят достаточно часто, так что 0 раз поменянный пароль за несколько лет - практически невозможная ситуация для этого подхода.
Что считать компрометацией хорошо описано в приказе ФАПСИ №152 про криптографические ключи: "происшествия, в результате которых криптоключи могут стать доступными несанкционированным лицам и (или) процессам"
Этот принцип смены паролей уже исследуется много лет и его эффективность считается доказанной.
На сегодняшний день Microsoft, Google, Apple, Meta, Cisco отказались от плановой ротации паролей. Стандарты, которые перешли на этот принцип: NIST SP 800-63B (США), ISO/IEC 27002:2022, NCSC Password Guidance (Великобритания)
Статьи на Хабре по теме:
https://habr.com/ru/companies/globalsign/articles/457036/
https://habr.com/ru/companies/crossover/articles/427711/
https://habr.com/ru/companies/varonis/articles/475320/