Какие должны быть пароли в 2026 году: новая таблица Hive Systems и её ограничения

В 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

Сравнивать официальные таблицы разных лет напрямую нельзя. В 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 года.

Проверка нескольких других ячеек даёт следующие значения:

Эти расчёты одновременно показывают пользу и опасность таблицы. Она хорошо демонстрирует экспоненциальный рост пространства вариантов, но результат зависит не только от длины, а сразу от трёх независимых обстоятельств:

1. как сформирован пароль;

2. как он хранится на стороне сервиса;

3. какими ресурсами располагает нарушитель.

Пользователь контролирует главным образом первый пункт. Функцию хэширования и её параметры выбирает владелец информационной системы.

Интерактивный калькулятор

По мотивам исследований 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

Перед использованием инфографики в обучении или парольной политике стоит явно проговорить её ограничения.

1. Рассматривается только офлайн-атака на уже похищенный хеш. Таблица ничего не говорит о фишинге, вредоносном ПО, перехвате сессии, восстановлении доступа или атаке на MFA.

2. Пароль считается случайным. Для строк, придуманных человеком, цвет ячейки может создавать ложное чувство защищённости.

3. Показано максимальное время полного перебора. Это не среднее и тем более не гарантированное время раскрытия.

4. Результат относится только к bcrypt cost 10. Для MD5, NTLM, PBKDF2, Argon2id и даже bcrypt с другим cost цифры будут другими.

5. Выбор bcrypt основан на публично известных утечках. Такие данные подвержены смещению выборки: неизвестные или не опубликованные инциденты в статистику не попадают.

6. Набор символов искусственно ограничен. В правом столбце учтены только восемь специальных символов, а Unicode, включая кириллицу, исключён.

7. Не учитывается парольная политика конкретного сервиса. Пользователь часто не знает ни алгоритма хранения, ни его параметров, ни качества реализации.

8. Модель стоимости ориентирована на одну выбранную облачную площадку и конкретный момент времени. Доступность оборудования и тарифы меняются.

Практические выводы

Пользователю

• Использовать уникальный пароль для каждого сервиса.

• Генерировать случайные пароли менеджером паролей, а не составлять их по запоминаемому шаблону.

• Для единственного фактора ориентироваться как минимум на 15 символов; при возможности выбирать более длинные значения.

• Проверять пароли на наличие в известных утечках, не передавая их сторонним сайтам в открытом виде.

• Включать MFA, предпочтительно устойчивую к фишингу, либо использовать passkeys.

• Менять пароль при компрометации, а не по календарю.

Владельцу информационной системы

• Разрешать длинные пароли, пробелы и Unicode; не обрезать введённое значение незаметно для пользователя.

• Не требовать искусственного набора классов символов и плановой смены без основания.

• Сверять создаваемые пароли с блок-листом распространённых и скомпрометированных значений.

• Ограничивать частоту онлайн-попыток, но не считать это заменой безопасному хранению паролей.

• Предлагать фишинг-устойчивую MFA и passkeys.

Разработчику

• Для новой системы выбирать Argon2id с параметрами, соответствующими актуальным рекомендациям и возможностям сервера.

• Если используется bcrypt, подбирать cost по результатам измерений, использовать уникальную случайную соль и учитывать ограничение длины входа.

• Предусматривать обновление параметров и перехеширование после успешной аутентификации.

• Рассмотреть дополнительный секрет pepper, хранящийся отдельно от базы паролей.

• Проектировать защиту так, как будто база хешей однажды может быть похищена.

Вместо вывода

Таблица Hive Systems остаётся хорошей иллюстрацией одного принципа: при случайной генерации каждый дополнительный символ резко увеличивает пространство перебора, а развитие оборудования постепенно сокращает имеющийся запас прочности.

Но цвет ячейки не является оценкой безопасности учётной записи. Случайный восьмисимвольный пароль из полного набора символов действительно потребует до 132 лет полного перебора в модели Hive Systems. Внешне похожий пароль, придуманный человеком, может раскрыться за секунды. А уникальный длинный пароль не защитит от фишинга или кражи активной сессии.

Поэтому практическая формула 2026 года выглядит не как «добавьте цифру и специальный символ», а так:

длинный случайный уникальный пароль + менеджер паролей + фишинг-устойчивая MFA или passkey + корректное хранение на стороне сервиса.

Источники

1. Corey Neskey. Are Your Passwords in the Green?. Hive Systems, 2026.

2. NIST. SP 800-63B-4: Authentication and Authenticator Management.

3. OWASP. Password Storage Cheat Sheet.

4. NIST. Post-Quantum Cryptography Standards.

5. Provos N., Mazières D. A Future-Adaptable Password Scheme. USENIX, 1999.

6. Иван Земцов. Калькулятор времени полного перебора паролей. Секьюритика.