Правила паролів NIST 800-63B: практичний гід 2026

NIST Special Publication 800-63B є частиною Рекомендацій з цифрової ідентичності, виданих Національним інститутом стандартів і технологій — федеральним агентством США. Хоча стандарти NIST є обов'язковими для державних установ США, вони стали фактичним глобальним еталоном безпеки паролів. Організації від фінансових установ до технологічних стартапів посилаються на NIST 800-63B при проектуванні своїх систем аутентифікації.

Найновіша редакція фундаментально змінила погляд спільноти безпеки на паролі. Вона відкинула десятиліття загальноприйнятої мудрості — обов'язкові правила складності, періодичну зміну паролів та контрольні запитання — на користь заснованих на доказах практик, які дійсно покращують безпеку без погіршення зручності використання.

Розуміння цих рекомендацій є критичним незалежно від того, чи ви розробник, що будує систему аутентифікації, IT-адміністратор, що управляє корпоративною політикою, чи індивідуальний користувач, що намагається приймати обґрунтовані рішення щодо безпеки. Цей гід перетворює технічний документ на практичні рекомендації.

Скасування обов'язкових правил складності. NIST явно рекомендує не вимагати великих літер, цифр або спеціальних символів. Дослідження показують, що примусова складність веде до передбачуваних шаблонів: користувачі пишуть першу літеру з великої, додають "1!" в кінці або використовують поширені підстановки. Ці шаблони добре відомі зловмисникам і дають мінімальне покращення безпеки. Натомість NIST зосереджується на довжині пароля як основному індикаторі надійності.

Відмова від періодичної зміни паролів. Примус користувачів змінювати паролі кожні 60 або 90 днів змушує їх робити мінімальні поступові зміни (Password1 → Password2 → Password3) або обирати простіші паролі, які вони можуть запам'ятати попри часті зміни. NIST тепер рекомендує змінювати паролі лише за наявності доказів компрометації — повідомлення про витік, підозрілої активності або виявлення шкідливого ПЗ.

Перевірка за списками скомпрометованих паролів. Коли користувач створює або змінює пароль, його потрібно перевірити за списком відомих скомпрометованих паролів. API Have I Been Pwned Passwords надає безкоштовний, конфіденційний спосіб перевірки понад 900 мільйонів скомпрометованих паролів за допомогою k-анонімності. Якщо пароль з'являється у витоку, відхиліть його та поясніть чому.

Дозвіл довгих паролів. Системи повинні приймати паролі довжиною до щонайменше 64 символів. Це підтримує парольні фрази та облікові дані, згенеровані менеджерами паролів. Тихе обрізання паролів — як роблять деякі застарілі системи — є серйозною вадою безпеки, яку NIST явно забороняє.

NIST встановлює абсолютний мінімум у 8 символів для паролів, обраних користувачем, та 6 символів для випадково згенерованих PIN-кодів. Однак дослідники безпеки широко рекомендують 12 символів як практичний мінімум і 15+ як ідеал. Обґрунтування просте: сучасні інструменти злому з прискоренням на GPU можуть перебрати всі 8-символьні паролі з набору 95 символів за години або дні, залежно від алгоритму хешування.

Для паролів, що захищають високоцінні активи (основні акаунти пошти, криптогаманці, root-доступ до серверів), настійно рекомендується 16+ символів або парольна фраза з 5+ слів. При такій довжині, навіть якщо зловмисник отримає хеш пароля, brute-force злом стає обчислювально неможливим з поточними технологіями.

Системи не повинні встановлювати максимальну довжину пароля менше 64 символів. Багато користувачів використовують менеджери паролів, що генерують 20-40 символьні паролі, а парольні фрази з роздільниками легко досягають 30+ символів. Довільні обмеження довжини активно шкодять безпеці, не дозволяючи користувачам використовувати свої бажані методи генерації.

NIST вимагає, щоб нові паролі перевірялися за списком поширених, очікуваних або скомпрометованих паролів. Цей список повинен включати: паролі з попередніх витоків (доступні через Have I Been Pwned або подібні сервіси); словникові слова; повторювані або послідовні символи (aaaaaa, 123456, abcdef); контекстно-специфічні слова (назва сервісу, ім'я користувача, email).

Коли пароль відхиляється, система повинна надати чітке пояснення: "Цей пароль з'являвся у відомому витоку даних. Будь ласка, оберіть інший пароль." Загальні повідомлення про помилки на кшталт "Пароль не відповідає вимогам" залишають користувачів розгубленими.

API Have I Been Pwned Passwords робить впровадження простим. Він використовує k-анонімність: ваш застосунок надсилає лише перші 5 символів SHA-1 хешу, отримує всі відповідні суфікси хешів та перевіряє локально. Фактичний пароль ніколи не залишає пристрій користувача, і оператор API не може визначити, який пароль було перевірено.

NIST вимагає, щоб паролі зберігалися з використанням пам'ятеємної односторонньої функції виведення ключів. Рекомендовані алгоритми: Argon2id (переможець конкурсу хешування паролів 2015 року), bcrypt з фактором роботи не менше 10 або PBKDF2-HMAC-SHA256 з не менше 600 000 ітераціями (збільшено з попередньої рекомендації 10 000).

Argon2id є кращим вибором для нових впроваджень. Він стійкий як до атак на GPU (завдяки вимогливості до пам'яті), так і до атак побічного каналу. Рекомендовані параметри: щонайменше 19 МіБ пам'яті, 2 ітерації та 1 ступінь паралелізму. Ці параметри слід налаштувати так, щоб хешування займало приблизно 0,5-1 секунди на вашому серверному обладнанні.

Ніколи не використовуйте прості криптографічні хеш-функції (MD5, SHA-1, SHA-256) для зберігання паролів. Вони розроблені для швидкості — прямо протилежне тому, що потрібно для хешування паролів. Зловмисник з сучасним GPU може обчислити мільярди хешів SHA-256 за секунду, але лише кілька тисяч хешів Argon2id.

Завжди використовуйте унікальну випадкову сіль для кожного пароля (не менше 128 біт). Сіль повинна зберігатися поряд з хешем. Це запобігає атакам за допомогою попередньо обчислених веселкових таблиць та гарантує, що однакові паролі дають різні хеш-значення.

NIST настійно рекомендує багатофакторну аутентифікацію для будь-якої системи, що обробляє конфіденційні дані. Три фактори: щось, що ви знаєте (пароль), щось, що ви маєте (телефон, апаратний ключ), і щось, чим ви є (біометрія). MFA повинна поєднувати щонайменше два різних фактори.

NIST класифікує аутентифікатори на три рівні впевненості (AAL1, AAL2, AAL3). AAL1 вимагає однофакторну аутентифікацію. AAL2 вимагає два різних фактори і підходить для більшості бізнес-застосунків. AAL3 вимагає апаратний аутентифікатор і потрібний для застосунків найвищого рівня безпеки.

SMS-коди одноразового доступу класифікуються як "обмежений" аутентифікатор через відомі вразливості (SIM-swapping, перехоплення SS7). Хоча все ще краще, ніж відсутність MFA, організації повинні віддавати перевагу TOTP-застосункам (Google Authenticator, Authy) або FIDO2 апаратним ключам (YubiKey, Titan) для вищого рівня впевненості.

Коли MFA впроваджено, NIST дозволяє послабити деякі вимоги до паролів (такі як мінімальна довжина), оскільки другий фактор забезпечує додатковий захист. Однак слабкі паролі залишаються ризиком навіть з MFA — фішингові атаки можуть одночасно захопити і пароль, і одноразовий код.

Для розробників та IT-адміністраторів, що впроваджують політики паролів відповідно до NIST, ось практичний чеклист. Почніть з видалення будь-яких існуючих вимог складності (обов'язкові великі літери, цифри, символи). Встановіть мінімальну довжину 12 символів та максимальну щонайменше 64. Впровадьте перевірку скомпрометованих паролів через API Have I Been Pwned Passwords.

Оновіть зберігання паролів до використання Argon2id (краще), bcrypt (мінімальний фактор роботи 10) або PBKDF2-HMAC-SHA256 (мінімум 600 000 ітерацій). Якщо мігруєте з слабшого хешу, перехешуйте паролі прозоро, коли користувачі наступного разу увійдуть. Забезпечте унікальні 128-бітні випадкові солі для кожного пароля.

Видаліть вимоги періодичної зміни паролів. Натомість впровадьте виявлення витоків: моніторте витоки облікових даних, що стосуються ваших користувачів, і примушуйте зміну паролів лише при виявленні компрометації. Додайте обмеження частоти на точки входу (блокування акаунтів після 10-20 невдалих спроб у короткому вікні).

Увімкніть та заохочуйте MFA, надаючи пріоритет FIDO2/WebAuthn апаратним ключам або TOTP-застосункам. Надайте чіткі інструкції з реєстрації та процедури відновлення. Зберігайте резервні коди MFA надійно та нагадуйте користувачам зберегти їх.