Требования к паролям в 2026 году: что изменилось и как теперь защищать свои аккаунты

Придумать пароль из восьми символов, обязательно добавить заглавную букву, цифру и специальный знак, а через три месяца повторить процедуру. Еще недавно подобные требования считались нормой корпоративной безопасности. Сегодня от многих из них рекомендуют отказаться.

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

В результате требования к безопасности учетных записей заметно изменились. Разберемся, что рекомендуют современные стандарты, насколько опасен ИИ-перебор и почему даже очень длинного пароля иногда недостаточно.

В АБП2Б мы хорошо знакомы с вопросами защиты учетных данных: наша команда разработала ОдинКлюч — российский менеджер паролей для безопасного хранения и управления доступами, которым уже пользуются, в том числе, крупнейшие компании страны и федеральные органы власти. Этот опыт помогает нам оценивать рекомендации по парольной безопасности с учетом реальных задач пользователей и компаний.

Почему сложный пароль больше не гарантирует безопасность

Представим, что пользователь придумал пароль из двадцати случайных символов. Подобрать такую комбинацию методом перебора крайне сложно, если пароль действительно создан случайным образом. Но даже такой надежный пароль не защитит аккаунт, если пользователь попадет на поддельный сайт и сам передаст его злоумышленникам.

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

Есть и менее очевидный сценарий — кража активной сессии. После успешной авторизации сайт обычно выдает браузеру специальный токен или cookie, позволяющий пользователю оставаться в аккаунте без повторного ввода пароля. Если злоумышленник получит действующий токен и сервис позволит его использовать, знание пароля может вообще не потребоваться.

Подобные атаки уже описывались Microsoft на примере фишинговых посредников, перехватывавших аутентифицированные сессии. Пользователь проходил вход, в том числе дополнительную проверку, но атакующий получал возможность продолжить работу от его имени.

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

Что изменилось в требованиях к паролям

В июле 2025 года Национальный институт стандартов и технологий США (NIST) опубликовал окончательную редакцию рекомендаций SP 800-63B-4. Документ пересматривает несколько привычных правил, которые до сих пор встречаются на сайтах и в корпоративных системах.

Главное изменение касается длины пароля. Если он используется как единственный фактор аутентификации, минимальная длина должна составлять 15 символов. Для пароля, который применяется исключительно вместе с многофакторной аутентификацией, стандарт допускает минимум восемь символов.

При этом NIST больше не поддерживает обязательное сочетание строчных и заглавных букв, цифр и специальных знаков. Вместо формального разнообразия символов предлагается уделять внимание длине и проверке паролей по спискам известных слабых и скомпрометированных комбинаций.

Причина вполне понятна. Требование добавить заглавную букву и цифру не мешает пользователю создать предсказуемый пароль вроде Company2026!. Формально правило выполнено, но сама комбинация остается достаточно очевидной.

Не менее существенно изменился подход к регулярной смене паролей. Стандарт не рекомендует заставлять пользователей менять их каждые 30, 60 или 90 дней без признаков компрометации.

Еще в исследовании Zhang, Monrose и Reiter, представленном на конференции CCS 2010, ученые изучили истории изменения паролей университетских аккаунтов. Для 7752 учетных записей с известными предыдущими паролями алгоритм смог угадать около 13% следующих комбинаций за пять попыток и 18% — за десять.

Исследование основано на старых данных и не доказывает, что регулярная смена всегда ухудшает безопасность. Однако оно хорошо показывает, насколько предсказуемыми могут быть действия пользователей. Вместо действительно нового пароля человек часто меняет год, цифру или один символ.

По современным рекомендациям менять пароль необходимо прежде всего при подозрении на его компрометацию. Например, после ввода на фишинговой странице или обнаружения соответствующей утечки.

Действительно ли ИИ научился взламывать пароли за минуты?

Заголовки о том, что нейросети способны взломать половину паролей менее чем за минуту, звучат впечатляюще. Однако за такими цифрами часто скрываются существенные ограничения исследований.

Важно понимать, что нейросеть не обязательно ускоряет саму проверку пароля. Ее основная задача — предложить наиболее вероятные комбинации, используя закономерности, которые встречаются в паролях реальных людей.

Традиционные инструменты перебора тоже умеют работать со словарями и правилами преобразования. Например, добавлять к распространенному слову год рождения, менять регистр букв или подставлять популярные окончания. Нейросети развивают этот подход и позволяют находить более сложные закономерности.

Один из известных примеров — PassGPT, представленный в 2023 году. Исследователи обучили модель на паролях из утечек и проверили ее способность генерировать новые комбинации. При миллиарде сгенерированных кандидатов она воспроизвела 41,86% паролей тестовой части RockYou.

Результат заслуживает внимания, но у него есть важное условие: в основном эксперименте использовались пароли длиной не более десяти символов. Поэтому переносить полученный процент на все современные пароли было бы неправильно.

Еще интереснее исследование PassLLM, представленное на USENIX Security 2025. В нем ученые рассмотрели ситуации, когда злоумышленнику известны некоторые сведения о владельце аккаунта.

В отдельных сценариях модель PassLLM-I угадывала от 12,54 до 31,63% тестовых паролей за 100 попыток на пользователя. Для экспериментов использовались выборки из утечек, содержащие персональные данные.

Это хорошо объясняет, почему нежелательно использовать в пароле имена родственников, даты рождения, названия компаний и другие знакомые комбинации. Чем больше сведений о человеке доступно атакующему, тем проще построить список вероятных вариантов.

Но ни одно из этих исследований не доказывает, что ИИ способен за минуту подобрать любой длинный случайный пароль. Скорость реальной атаки зависит от того, как сервис хранит проверочные данные, какое оборудование использует злоумышленник и сколько попыток ему доступно.

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

Какой пароль действительно стоит использовать

Придумывать сложный пароль для каждого сайта и пытаться удержать все комбинации в голове — затея сомнительная. Особенно когда у человека десятки учетных записей, а некоторые сервисы еще и предъявляют собственные требования к символам и длине.

Гораздо проще доверить эту задачу менеджеру паролей. Он сам создаст случайные комбинации и сохранит их, чтобы при следующем входе не пришлось вспоминать, какую букву мы сделали заглавной и где поставили восклицательный знак.

Для компаний это еще и способ навести порядок с доступами. Когда несколько сотрудников пользуются одними учетными данными, пароли нередко оказываются в переписках, таблицах и других не самых подходящих для хранения местах. Например, российский менеджер паролей ОдинКлюч позволяет хранить пароли в зашифрованном виде, предоставлять сотрудникам доступ к нужным учетным данным и управлять этими правами централизованно. При необходимости решение можно развернуть в собственной инфраструктуре.

Что касается самих паролей, для автоматической генерации можно выбирать комбинации из 20–24 случайных символов, если сервис поддерживает такую длину. Запоминать их не придется, поэтому нет особого смысла ограничиваться короткими вариантами.

А вот мастер-пароль, который открывает само хранилище, лучше выбирать так, чтобы его можно было запомнить. Здесь пригодятся парольные фразы — несколько случайно выбранных слов. Например, метод EFF Dice-Generated Passphrases предлагает использовать специальный словарь и выбирать слова случайным образом. Шесть или семь таких слов могут обеспечить высокую стойкость, оставаясь удобнее для запоминания, чем длинная строка символов.

При этом цитата из любимой книги или самостоятельно придуманное предложение — не совсем то же самое. Люди склонны выбирать знакомые слова и сочетания, а значит, такие комбинации могут оказаться предсказуемыми.

И главное — не стоит использовать один пароль для нескольких сайтов, каким бы надежным он ни казался. Если данные одного сервиса попадут в утечку, злоумышленники смогут проверить ту же комбинацию на других площадках.

Генерировать пароли тоже лучше специальными инструментами, а не просить об этом нейросеть. Языковая модель вполне способна придумать строку, которая выглядит случайной, но гарантировать ее криптографическую стойкость она не может.

Один аккаунт для всех сервисов: удобно, но безопасно ли?

Вместо десятков отдельных паролей многие пользователи предпочитают входить через Яндекс ID, VK ID, Сбер ID или другие системы единой авторизации.

При правильной реализации такой вход действительно имеет преимущества. Стороннему приложению не нужно знать пароль от основного аккаунта. Пользователь проходит аутентификацию у провайдера, а приложение получает результат проверки и предусмотренные разрешениями данные.

Но здесь возникает другая зависимость. Если злоумышленник получит контроль над основным аккаунтом, он потенциально сможет использовать связанные с ним способы входа или восстановления доступа.

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

В компаниях похожий принцип используется в SSO — системе единого входа. Сотрудник проходит авторизацию у корпоративного провайдера идентификации и получает доступ к подключенным приложениям.

Преимущество такой схемы заключается не только в удобстве. Организация может централизованно управлять доступами, применять единые требования к аутентификации и отключать учетные записи уволенных сотрудников.

Однако SSO требует правильной настройки. Блокировка сотрудника в центральной системе не обязательно мгновенно завершает все уже открытые сессии в остальных приложениях.

Кроме того, необходимо учитывать доступность самого провайдера идентификации и последствия его компрометации. Чем больше сервисов от него зависит, тем важнее защита и резервирование этой точки входа.

Passkey: можно ли совсем отказаться от паролей?

Одна из наиболее интересных альтернатив привычным паролям — passkey, или ключ доступа.

Вместо секретной строки, которую пользователь должен помнить и вводить, применяется пара криптографических ключей. Открытый ключ хранится у сервиса, а закрытым распоряжается устройство или другой аутентификатор пользователя.

При входе сервис отправляет запрос, который необходимо криптографически подтвердить. Для разрешения операции пользователь может разблокировать устройство с помощью отпечатка пальца, распознавания лица или PIN-кода.

Главное преимущество passkey заключается в устойчивости к фишингу. Ключ привязан к конкретному сервису, поэтому поддельная страница с похожим адресом не сможет получить пригодное для настоящего сайта подтверждение входа при корректной реализации протокола.

В России такой способ уже используется, например, в Яндекс ID. Сервис позволяет создавать ключи доступа на устройствах и использовать поддерживаемые внешние аутентификаторы.

При этом passkey бывают разными. Одни синхронизируются между устройствами через защищенное хранилище, другие привязаны к конкретному аппаратному ключу. Первый вариант удобнее для повседневного использования, второй позволяет строже контролировать хранение ключевого материала.

Но даже passkey не решает абсолютно все проблемы.

Если злоумышленник уже получил доступ к активной сессии, сам по себе переход на новый метод входа не обязательно завершит эту сессию. Кроме того, при временном доступе к чужому аккаунту атакующий может попытаться зарегистрировать дополнительный аутентификатор.

Показательный пример есть в исследовании Adversarial Passkeys, представленном на USENIX Security 2026. В лабораторном эксперименте участники пытались восстановить контроль над подготовленными аккаунтами, в которых злоумышленник ранее добавил собственный ключ. Ни один из 31 участника самостоятельно не выполнил весь необходимый набор действий.

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

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

Почему двухфакторная аутентификация тоже бывает разной

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

Например, SMS-коды зависят от безопасности телефонного номера и могут быть перехвачены при определенных сценариях. Приложения-аутентификаторы, генерирующие временные коды TOTP, не зависят от доставки SMS, однако злоумышленник может попытаться выманить действующий код и немедленно использовать его на настоящем сайте.

Push-подтверждения удобны, но здесь существует риск случайного одобрения чужого запроса. Подтверждение дополнительного числа уменьшает вероятность ошибки, хотя само по себе не делает способ входа устойчивым к любому фишингу.

Для наиболее важных аккаунтов предпочтительнее использовать методы, которые криптографически привязаны к настоящему сервису. К ним относятся корректно реализованные passkey и поддерживаемые аппаратные FIDO-аутентификаторы.

В первую очередь это актуально для основной электронной почты, корпоративных администраторов и систем, через которые можно восстановить доступ к другим учетным записям.

На что стоит обратить внимание разработчикам и компаниям

Даже правильные пользовательские пароли не помогут, если сервис допускает ошибки в их обработке или хранении.

Для новых систем OWASP рекомендует использовать Argon2id — алгоритм, специально предназначенный в том числе для защиты паролей от быстрого массового перебора. При этом параметры необходимо подбирать с учетом возможностей сервера и нагрузки.

Пароли пользователей не должны храниться в открытом виде. Аутентификационная система должна сохранять необходимые проверочные данные, применять индивидуальные случайные соли и обеспечивать безопасную процедуру восстановления.

Есть и менее очевидная проблема — некорректная обработка специальных символов.

В документации Astra Linux и ALD Pro встречаются конкретные случаи ошибок, связанных с паролями. Например, для одной из версий механизма присоединения к Active Directory описана ошибка разбора командной оболочки при обработке пароля. В некоторых версиях ALD Pro отмечались проблемы подготовки конфигурации при наличии специальных символов.

Это не означает, что Astra Linux в целом не поддерживает сложные пароли. Проблема связана с определенными компонентами и этапами обработки данных.

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

Отдельного внимания заслуживает восстановление доступа. Если сервис позволяет обойти надежную аутентификацию через слабо защищенную почту, телефон или службу поддержки, общая безопасность будет зависеть именно от этого механизма.

Поэтому организациям недостаточно просто обновить требования к длине пароля. Необходимо контролировать выдачу и отзыв прав, применять многофакторную аутентификацию, защищать критичные аккаунты и проверять, что происходит с сессиями после смены пароля или увольнения сотрудника.

Как защитить свои аккаунты в 2026 году

Полностью отказываться от паролей пока рано. Они остаются распространенным и универсальным способом входа, особенно в системах, где новые методы аутентификации еще не поддерживаются.

Но изменить подход к их использованию определенно стоит.

Для обычных сервисов разумно применять уникальные случайные пароли и хранить их в менеджере. Если доступен passkey, можно рассмотреть его как более устойчивый к фишингу вариант. Основную почту, менеджер паролей и учетную запись, отвечающую за синхронизацию устройств, следует защищать особенно тщательно, поскольку через них нередко восстанавливается доступ к другим сервисам.

Не менее важно периодически проверять, какие устройства и ключи привязаны к аккаунтам, а также какие сессии остаются активными. При подозрении на компрометацию одной смены пароля может быть недостаточно.

Для компаний приоритеты шире: управление доступами сотрудников, надежная аутентификация администраторов, безопасное хранение секретов и контроль процедур восстановления.

Самое заметное изменение последних лет заключается в том, что безопасность аккаунта перестала измеряться количеством специальных символов в пароле. Длинный уникальный пароль по-прежнему полезен, но надежная защита строится вокруг всего процесса аутентификации — от первого входа до восстановления и окончательного отзыва доступа.