Коротко
- По NIST SP 800-63B пароль как единственный фактор должен быть не короче 15 символов, как часть многофакторной аутентификации — не короче 8, система должна принимать не менее 64 символов; обязательные правила состава и плановая смена паролей запрещены, смена нужна при признаках компрометации, новые пароли сверяют со списками утёкших. OWASP согласен. Рекомендации Роскачества по пересказам СМИ называют 16–17 символов; страницу напрямую открыть не удалось.
- Практика: длинный (от 16 символов), случайный и уникальный пароль в менеджере; для главного пароля — парольная фраза из 5–6 случайных слов; многофакторная защита везде. Для полностью случайного пароля стойкость ≈ длина × log2(набор): 16 символов из 94 дают около 105 бит, 6 слов из списка в 7 776 слов — около 78 бит. Придуманные человеком пароли намного слабее.
- Генератор должен работать в браузере через crypto.getRandomValues (Math.random для секретов не подходит). Для сайта магазина защищайте почту домена, регистратор, хостинг, админку и кабинеты, делайте отдельные учётные записи и отзывайте доступы. Форму входа реализуйте по NIST и OWASP с помощью проверенных библиотек.
- В статье — сравнение рекомендаций, арифметика стойкости, создание пароля, безопасный генератор, доступы сайта, форма входа, десять ошибок и PDF-чек-лист на 29 пунктов.
Коротко: какой пароль считается надёжным в 2026 году
Совет «пароль из 8 символов с заглавной буквой, цифрой и спецзнаком, менять раз в три месяца» знаком каждому. Но он давно устарел. Современные рекомендации, которые я нашёл в первоисточниках, говорят почти противоположное: длина важнее сложности, обязательные правила состава вредны, плановая смена паролей не нужна, а главное — уникальность, менеджер паролей и двухфакторная защита. При этом отечественные рекомендации (Роскачество) в разных публикациях называют «16–17 символов со спецсимволами», что тоже ближе к длине. Разберём, где что.
- Длина. По документу NIST SP 800-63B (редакция 4): пароль как единственный фактор — не менее 15 символов; пароль как часть многофакторной аутентификации — не менее 8; система должна принимать не менее 64 символов.
- Правила состава запрещены. Тот же документ: обязательные правила вроде «смешивать заглавные, строчные, цифры и спецсимволы» запрещены; единственное обязательное ограничение — сверка со списками запрещённых паролей (из утечек, словарные, контекстные слова).
- Плановая смена запрещена. Смена обязательна только при признаках компрометации. OWASP согласен: регулярная принудительная смена не рекомендуется, лучше поощрять стойкие пароли и включать MFA.
- Менеджеры паролей и вставка из буфера разрешены. NIST требует разрешать менеджеры и автозаполнение и рекомендует разрешать вставку.
- Пароль не защищает от фишинга. Поэтому нужна многофакторная аутентификация, лучше с устойчивым к фишингу вариантом.
В статье: что говорят NIST, OWASP и Роскачество, как оценивать надёжность, как создавать пароль и парольную фразу (в том числе случайным генератором), как работает безопасный генератор в браузере, что делать владельцу сайта (админка CMS, хостинг, почта, рекламные кабинеты), как настроить правила паролей на своём сайте, десять ошибок и PDF-чек-лист на 29 пунктов. Генератор: генератор паролей на tools.cetto.ru (создаёт пароль в вашем браузере).
Основа статьи — требования NIST SP 800-63B (я прочитал первые ~100 тыс. знаков страницы, остальное не открывал), шпаргалка OWASP по аутентификации, документация MDN о криптографически стойких случайных числах, страница Pwned Passwords и публикации с рекомендациями Роскачества. Страницу Роскачества напрямую открыть не удалось, поэтому его рекомендации даны по пересказам в СМИ разных лет (2019–2025), и цифры в них расходятся. Расчёты стойкости ниже — моя арифметика для пароля, выбранного полностью случайно; для паролей, придуманных человеком, они не применимы.
Почему старые правила не работают
Раньше требовали сложный пароль и частую смену. Результат известен: люди выбирают предсказуемые схемы («Пароль1!», «Пароль2!»), записывают на бумажках и повторяют один пароль на разных сайтах. NIST сделал выводы: правила состава и плановая смена запрещены; вместо этого длина и сверка со списками скомпрометированных паролей. OWASP отмечает: оценки энтропии условны, поэтому лучше опираться на длину и проверку по чёрным спискам, а не на правила состава или расчёты энтропии.
Реальные угрозы: словарные атаки и подбор распространённых паролей, credential stuffing (использование утёкших пар «логин-пароль» на других сайтах) и фишинг. Против первых двух помогают длина, уникальность и проверка на утечки. Против фишинга пароль бессилен (NIST: пароли не устойчивы к фишингу), здесь нужна многофакторная защита.
Рекомендации: что и кто говорит
| Вопрос | NIST SP 800-63B | OWASP | Роскачество (по пересказам) |
|---|---|---|---|
| Минимальная длина | 15 (единственный фактор), 8 (с MFA) | Задаётся приложением; ссылается на NIST | Разные публикации: 8, 16, 17 символов; ориентир 16–17 |
| Максимальная длина | Принимать не менее 64 | Не менее 64, чтобы можно было использовать фразы | — |
| Правила состава | Обязательные правила запрещены | Не требовать заглавных, цифр и спецсимволов | Советует разные регистры, цифры, спецсимволы |
| Смена пароля | Только при признаках компрометации | При подозрении на утечку; плановая смена не рекомендуется | Менять, если пароль содержит личные данные или прост |
| Менеджер паролей | Разрешать использование и автозаполнение | Разрешать вставку, длинные пароли | Сохранить длинный пароль в менеджере; есть риск потери доступа к нему |
| Проверка на утечки | Сверять со списками | Сверять с базами вроде Pwned Passwords | — |
| Уникальность | — | — | Разные пароли для разных сервисов |
| Двухфакторная защита | Рекомендует предлагать MFA, один вариант должен быть устойчив к фишингу | Включать MFA | Привязывать входы к телефону, включить двухфакторную защиту, особенно для Госуслуг |
Видно, что отечественные советы (спецсимволы, разные регистры) отчасти отстали от NIST по составу, но сходятся с ним по главному: длина, уникальность, менеджер и вторая защита. Практически вы не ошибётесь, если сделаете пароль длинным (не меньше 16 символов), уникальным и случайным, а состав оставите на усмотрение сайта: если он требует спецсимвол, добавьте.
Как оценивать стойкость (простая арифметика)
Для пароля, выбранного полностью случайно из набора, число вариантов равно размеру набора в степени длины. Стойкость в битах: длина × log₂(размер набора). Расчёты:
| Пароль | Набор | Стойкость (примерно) |
|---|---|---|
| 8 случайных символов | 62 (буквы и цифры) | около 48 бит |
| 12 случайных символов | 94 (все печатные ASCII) | около 79 бит |
| 16 случайных символов | 62 | около 95 бит |
| 16 случайных символов | 94 | около 105 бит |
| 5 случайных слов из списка в 7 776 слов (diceware) | 7 776 | около 65 бит |
| 6 случайных слов из списка в 7 776 слов | 7 776 | около 78 бит |
Важные оговорки. Эти числа верны только при полностью случайном выборе: «придуманные» человеком пароли намного слабее (имена, даты, замена букв на цифры). Каждый дополнительный символ увеличивает число вариантов в разы. Парольная фраза из случайных слов проще запоминается, чем набор символов, и при достаточном количестве слов остаётся стойкой, а OWASP отмечает, что длинные фразы эффективны, поскольку увеличивают объём перебора для словарной атаки. Но слова должны быть выбраны случайно (кубиком или генератором), а не из любимой цитаты.
Как создать пароль
- Для большинства аккаунтов — менеджер паролей и случайный пароль. Длина 16 символов и больше, все символы, которые разрешает сайт. Запоминать не нужно.
- Для главного пароля (менеджер паролей, почта, устройство) — парольная фраза. Несколько случайных слов (от 5–6), которые вы запомните. Выбирайте слова генератором или кубиком, не из пословиц.
- Не используйте личные данные: имена, даты, номера, клички, названия сайта и логин (NIST относит контекстные слова к запрещаемым).
- Не повторяйте пароль. Один пароль на все сервисы — главная причина взлома аккаунтов после утечек.
- Не меняйте пароль «по календарю», меняйте при подозрении на утечку или если пароль простой.
- Проверьте, не скомпрометирован ли пароль. Сервис Pwned Passwords проверяет по принципу k-anonymity: пароль хешируется в вашем браузере, наружу уходят только первые 5 символов хеша, итоговое сравнение происходит у вас. Результат «не найден» не означает, что пароль хороший; «pwned» означает, что пароль уже был в утечке и его нельзя использовать. Всё равно не вводите действующие пароли в непроверенные сервисы.
- Включите многофакторную защиту везде, где можно: приложение-аутентификатор или физический ключ надёжнее кода из SMS (NIST требует предлагать хотя бы один фишингоустойчивый вариант; конкретный ранжир методов в моих источниках не приводился).
Как работает безопасный генератор паролей
Не доверяйте онлайн-генератору, если он создаёт пароль на сервере и передаёт его вам: пароль уже виден третьей стороне. Правильный генератор работает в вашем браузере и использует криптографически стойкий источник случайности. В браузере это crypto.getRandomValues(): по документации MDN метод заполняет массив криптографически стойкими случайными числами (псевдослучайный генератор, засеянный значением с достаточной энтропией), а Math.random() MDN прямо называет некриптографическим, непригодным для секретов. Ещё один тонкий момент — смещение по модулю (modulo bias): при простом остатке от деления некоторые символы получаются вероятнее других, и качественный генератор отбрасывает «лишние» значения. Максимальный объём одного запроса к getRandomValues — 65 536 байт.
Как проверить генератор: откройте вкладку Network в инструментах разработчика (F12) и нажмите «Сгенерировать»: если запросов к серверу не идёт, пароль создан локально. Генератор на tools.cetto.ru создаёт пароль прямо в браузере; всё равно копируйте пароль сразу в менеджер, не храните в заметках и мессенджерах.
Пароли и доступы сайта магазина
Для владельца сайта пароли — это защита трафика и клиентов. Взлом админки означает подмену контента, скрытые ссылки, вредоносный код, санкции и потерю позиций (в обзорах нет точных цифр, но механизм очевиден; см. «Аудит перед запуском»). Что защитить:
- Админка CMS и FTP/SSH-доступ: длинные уникальные пароли, отдельные учётные записи на каждого сотрудника, права по минимуму, двухфакторная защита.
- Хостинг, домен и DNS: потеря доступа к регистратору — потеря сайта. Включите двухфакторную защиту и проверяйте срок оплаты: Whois, «Возраст сайта и история домена».
- Вебмастера и аналитика: Яндекс Вебмастер, Search Console, Метрика, рекламные кабинеты — доступы только нужным людям, при увольнении отзывайте.
- Почта домена: на неё приходят сбросы паролей ко всему остальному; защитите её сильнее всего.
- Не передавайте пароли в чатах и письмах; используйте менеджер с общим хранилищем или временные доступы.
- Подрядчики: отдельные доступы, срок действия, журнал; после работы закрывайте.
- Данные клиентов: защита и хранение — часть требований о персональных данных: «152-ФЗ для интернет-магазина».
Если вы разрабатываете форму входа на своём сайте
По NIST и OWASP:
- минимум 8 символов при многофакторной аутентификации и 15 при однофакторной; принимать не менее 64 символов, любые печатные символы, пробелы и Unicode;
- не требовать обязательных сочетаний регистров, цифр и спецсимволов;
- не заставлять менять пароль по расписанию; менять при компрометации;
- сверять новые пароли со списками утёкших, словарных и контекстных слов (Pwned Passwords через API или локальная копия); объяснять причину отказа;
- разрешать менеджеры паролей, автозаполнение и вставку; предлагать кнопку «показать пароль»;
- ограничивать число неудачных попыток (NIST: верхняя граница не более 100, после чего отключать аутентификатор; можно строже);
- хранить пароли в солёном виде подходящей функцией хеширования (соль не менее 32 бит), передавать только по защищённому каналу;
- предлагать многофакторную защиту, один из вариантов — устойчивый к фишингу.
Это краткая выжимка рекомендаций, а не проект безопасности: реализацию лучше доверить проверенным библиотекам и специалисту по безопасности.
Десять частых ошибок
- Один пароль на все сервисы.
- Короткий «сложный» пароль вместо длинного и случайного.
- Личные данные в пароле (имя, дата, кличка, название сайта).
- Схемы «Пароль1!, Пароль2!» при плановой смене.
- Хранение паролей в заметках, таблицах и мессенджерах.
- Генератор паролей, создающий пароль на чужом сервере, или использование
Math.random()для секретов. - Нет многофакторной защиты на почте, регистраторе, хостинге и админке.
- Общие учётные записи сотрудников и подрядчиков без возможности отозвать доступ.
- Вставка в формы запрещена, ограничение длины 12–16 символов на своём сайте.
- Не реагируют на утечку: не меняют скомпрометированный пароль.
Что проверяю в аудите я
Безопасность доступов — не SEO в чистом виде, но взлом сайта убивает трафик. В рамках SEO-аудита я проверяю признаки взлома и нарушений (скрытые ссылки, подмену контента, уведомления вебмастеров), защиту HTTPS, настройки доступа к служебным разделам, robots.txt и noindex на служебных страницах, а также привожу рекомендации по доступам, которые стоит проверить с администратором. Результат: PDF-отчёт на 30–50 страниц, технические задания для программистов, прогноз по трафику и заявкам и созвон, на котором я лично расскажу о найденных ошибках и отвечу на вопросы. Стоимость от 30 000 ₽, срок 3–5 рабочих дней для небольшого сайта и 7–10 для крупного магазина.
Итоговый чек-лист (короткая версия, полная в PDF)
- Пароли длинные (от 16 символов), случайные и уникальные; хранятся в менеджере.
- Главный пароль — парольная фраза из случайных слов.
- Многофакторная защита включена на почте, хостинге, регистраторе, админке и кабинетах.
- Плановая смена убрана; смена — при подозрении на утечку.
- Генератор работает в браузере и использует криптографически стойкий источник.
- Доступы сотрудников и подрядчиков раздельные, по минимуму, отзываются при уходе.
Частые вопросы
Какой пароль считается надёжным?
Длинный, случайный и уникальный. По NIST SP 800-63B, пароль как единственный фактор должен быть не короче 15 символов, как часть MFA — не короче 8, а система должна принимать не менее 64 символов. Роскачество в публикациях называет 16–17 символов.
Нужны ли заглавные буквы, цифры и спецсимволы?
NIST запрещает обязательные правила состава, а OWASP не рекомендует их требовать. Длина и сверка со списками утёкших паролей важнее. Но если сайт требует спецсимвол, добавьте его.
Надо ли менять пароль каждые три месяца?
Нет. NIST запрещает плановую смену: меняйте при признаках компрометации. OWASP тоже не рекомендует принудительную смену по расписанию.
Безопасны ли онлайн-генераторы паролей?
Если пароль создаётся в вашем браузере через crypto.getRandomValues и не отправляется на сервер, да. Проверьте вкладку Network: запросов быть не должно. Math.random для паролей не подходит.
Что такое парольная фраза?
Несколько случайно выбранных слов (лучше пять-шесть и больше). Её проще запомнить, чем набор символов; шесть слов из списка в 7 776 слов дают около 78 бит при полностью случайном выборе.
Нужен ли менеджер паролей?
Он позволяет иметь уникальные длинные пароли для каждого сервиса. NIST требует разрешать менеджеры и автозаполнение. Риск: потеря доступа к самому менеджеру, поэтому главный пароль нужно запомнить и защитить многофакторной защитой.
Как проверить, не утёк ли мой пароль?
Сервис Pwned Passwords использует принцип k-anonymity: пароль хешируется в браузере, отправляются первые 5 символов хеша. Результат «не найден» не означает хороший пароль, а «pwned» означает, что пароль нельзя использовать.
Какой пароль ставить на админку сайта?
Длинный (16+ символов), уникальный и случайный, в менеджере паролей, с двухфакторной защитой и отдельными учётными записями на каждого сотрудника и подрядчика.
Где скачать чек-лист?
PDF-чек-лист на 29 пунктов с приоритетами P1–P3, подсказками «как проверить» и подсчётом результата можно скачать по ссылке в статье. Он бесплатный; при цитировании укажите источник.
Интернет-маркетолог, частный SEO-специалист cetto.ru. 10+ лет в IT, 200+ реализованных проектов, сертификация Яндекса и Google.