Опубліковано: · Оновлено: · автор: kodewright
Безпека паролів: найкращі практики 2026 року
Найкращі практики безпеки паролів у тому порядку, в якому я їх налаштовую: унікальні паролі, менеджер, 2FA, стійка до фішингу, і правила, які розробникам час прибрати.
Найкращі практики безпеки паролів вміщаються в один рядок: випадковий унікальний пароль для кожного облікового запису, менеджер паролів, у якому вони зберігаються, і другий фактор, стійкий до фішингу, на важливих акаунтах. Решта сторінки пояснює, як це налаштувати, а окремий розділ для розробників розповідає про правила для паролів, які я сам колись впроваджував, і чому сьогодні написав би їх інакше.
Порядок має значення. Кожен крок закриває прогалину, яку лишає попередній, тож якщо у вас є лише двадцять хвилин, зробіть перші три кроки і на цьому зупиніться.
Чотири атаки і чотири способи захисту
Більшість захоплень акаунтів починається з однієї з чотирьох атак, і кожну зупиняє інша звичка:
| Атака | Як працює | Що її зупиняє |
|---|---|---|
| Повний перебір | Перебір усіх комбінацій для викраденого хешу | Довжина і випадковість |
| Атака за словником і правилами | Перебір реальних паролів та їхніх варіацій (Summer2026!) | Паролі, які ніхто не вигадував вручну |
| Credential stuffing | Пару «пошта + пароль», злиту з одного сайту, пробують на сотнях інших | Окремий пароль для кожного сервісу |
| Фішинг | Фальшива сторінка входу збирає все, що ви вводите | Менеджер, який там не підставить пароль, і passkey або апаратний ключ |
Звіт Verizon Data Breach Investigations Report 2025 року назвав викрадені облікові дані найпоширенішим способом проникнення (22% витоків), фішинг дав 16%. У виданні 2026 року на перше місце вийшла експлуатація вразливостей у програмах, але облікові дані й фішинг досі серед лідерів, і жодному з них не потрібна потужна відеокарта. Тому унікальність і стійкість до фішингу важать більше, ніж кілька зайвих бітів ентропії.
Крок 1: нехай паролі обирає генератор
Пароль, який ви вигадуєте, повторює ваші звички: улюблене слово, велика літера на початку, рік і знак оклику в кінці. Інструменти для зламу побудовані саме на цих звичках, тому «складний» людський пароль падає значно швидше, ніж обіцяє його довжина.
Для всього, що зберігається в менеджері, беріть 16 або більше випадкових символів. Генератор паролів створює їх за допомогою криптографічного джерела випадковості браузера, і пароль створюється у вашій вкладці, нікуди не надсилаючись. Для тих кількох речей, які доводиться вводити з пам'яті (сам менеджер, вхід у ноутбук), краще підходить парольна фраза з 5–6 випадкових слів; розрахунки є у статті парольна фраза чи пароль.
Для PIN-коду телефона чи SIM-картки забудьте про дати народження й комбінації на кшталт 1234 і візьміть випадковий код у Генераторі PIN.
Крок 2: один менеджер паролів для всього
Сотню випадкових паролів не запам'ятати, тож це має робити щось інше. Менеджер паролів зберігає їх у зашифрованому вигляді, підставляє на потрібному сайті й попереджає про повторені або злиті паролі.
Я користуюся двома: вбудованим менеджером браузера і Psono, менеджером паролів з відкритим кодом, який можна розгорнути на власному сервері. Браузерний варіант кращий, ніж зазвичай думають; де він не дотягує, розбираю в статті чи безпечні менеджери паролів у браузері. Серед окремих менеджерів найчастіше обирають Bitwarden і 1Password.
Менеджер заодно перевіряє на фішинг. Він підставляє пароль лише на тому домені, для якого його збережено, тож якщо на сторінці, схожій на ваш банк, він мовчить, подивіться на адресний рядок, перш ніж щось вводити.
Головний пароль — єдиний секрет, який треба пам'ятати. Зробіть його випадковою парольною фразою щонайменше з 6 слів і більше ніде її не використовуйте.
Крок 3: другий фактор, який фальшива сторінка не вкраде
Другий фактор означає, що самого викраденого пароля замало. Але методи сильно відрізняються тим, від чого захищають:
| Метод | Зупиняє фальшиву сторінку входу? | Зупиняє SIM-swap? | Моя оцінка |
|---|---|---|---|
| Passkey або апаратний ключ (FIDO2) | Так | Так | Вмикайте всюди, де пропонують |
| Застосунок-автентифікатор (TOTP-коди) | Ні, фішингова сторінка може передати код у реальному часі | Так | Розумний варіант за замовчуванням |
| Push-запит на телефоні | Ні, якщо не просить звірити число | Так | Годиться зі звіркою числа |
| Код в SMS | Ні | Ні | Краще, ніж нічого |
Для більшості акаунтів я користуюся застосунком-автентифікатором і підтвердженнями на телефоні. Passkey (ключ доступу) — більший крок уперед: вхід прив'язано до справжнього домену, тож сайту-двійнику нічого перехоплювати. Перевірка Passkey покаже, чи підтримують їх ваші браузер і пристрій, а порівняння методів детальніше є у статті 2FA чи MFA. SIM-swap тут означає перевипуск вашої SIM-картки шахраями, після чого SMS-коди приходять їм.
Вмикайте другий фактор спершу на пошті, потім на менеджері паролів, потім у банкінгу.
Крок 4: захистіть пошту як головний ключ
Кожне посилання «Забули пароль?» приходить на вашу пошту, тож хто контролює пошту, той може скинути майже все інше. Коли я допомагав людям повернути зламаний акаунт, проблема зазвичай була в тому, що вони не знали даних для входу в резервну пошту, а другий фактор ніде не був увімкнений.
Для основної поштової скриньки:
- Поставте унікальний згенерований пароль від 20 символів.
- Додайте passkey або застосунок-автентифікатор і приберіть SMS як спосіб входу, якщо поштовий сервіс це дозволяє.
- Роздрукуйте резервні коди і зберігайте їх у фізичному місці.
- Перевірте резервний номер телефона й резервну адресу зараз, поки доступ ще у вас.
Окрема адреса (або псевдоніми з пересиланням, як Hide My Email від Apple чи SimpleLogin) для покупок і розсилок тримає основну адресу подалі від більшості злитих баз і фішингових списків.
Крок 5: виходьте з того, що витік станеться, і реагуйте швидко
Витоки даних — звична справа, а компанії іноді повідомляють про них місяцями. Перевірте свої адреси на Have I Been Pwned (haveibeenpwned.com) і ввімкніть сповіщення про витоки в менеджері паролів. Якщо сервіс, яким ви користуєтеся, зламали, змініть цей один пароль. Якщо він був унікальним, на цьому все; якщо ви використовували його ще десь, змініть його всюди. Повний порядок дій описано в статті що робити в перші 48 годин після витоку.
Не змінюйте паролі за розкладом. Змінюйте їх, коли є причина.
Крок 6: тримайте пристрій чистим
Кейлогер або шкідливе розширення браузера читає пароль просто під час введення, і тут його стійкість не допоможе. Увімкніть автоматичні оновлення системи й браузера, видаліть розширення, якими не користуєтеся, і встановлюйте програми лише з сайту розробника або з магазину застосунків.
Для розробників: правила для паролів, які я впроваджував, і що я б змінив
У продуктах, які я робив, стояв класичний набір правил: мінімальна довжина плюс щонайменше одна велика літера, одна цифра й один спецсимвол. Нові паролі за базами витоків я ніколи не перевіряв. Саме такі правила досі показують більшість фреймворків і туторіалів, а NIST SP 800-63B Rev. 4 тепер радить від них відмовитися. У розділі про верифікатори сказано, що вони «SHALL NOT impose other composition rules», тобто не мають вимагати суміші типів символів. Мінімум — 15 символів, якщо пароль є єдиним фактором (8, якщо він працює разом із MFA), максимум має бути щонайменше 64, зміна за розкладом заборонена, а нові паролі обов'язково звіряються зі списком поширених, очікуваних і скомпрометованих.
Щоб побачити, що саме пропускають старі правила, я прогнав кілька паролів через два валідатори в Node 22: класичний (8+ символів, велика літера, цифра, спецсимвол) і в дусі NIST (15+ символів, без вимог до складу, пошук усього пароля в чорному списку). Останній стовпець показує результат моєї Перевірки стійкості пароля, порахований за тією самою формулою «набір символів × довжина», що й в інструменті:
const sym = /[!@#$%^&*()\-_=+[\]{}|;:,.<>?]/
const classic = p => p.length >= 8 && /[A-Z]/.test(p) && /[0-9]/.test(p) && sym.test(p)
const nist = (p, blocklist) =>
[...p.normalize('NFC')].length >= 15 && !blocklist.has(p.toLowerCase())
| Пароль | Класичне правило | Правило в дусі NIST | Перевірка стійкості |
|---|---|---|---|
Password1! | Проходить | Не проходить (закороткий, у чорному списку) | 64,9 біта, «Надійний» |
P@ssw0rd | Проходить | Не проходить | 51,9 біта, «Середній» |
Summer2026! | Проходить | Не проходить | 71,4 біта, «Надійний» |
umbrella-oyster-tundra-lamp | Не проходить (немає великої літери й цифри) | Проходить | 155,4 біта, «Дуже надійний» |
kX9#vT2!mQ4$wL7z (згенерований) | Проходить | Проходить | 103,9 біта, «Надійний» |
Класичне правило приймає три паролі, які є просто словом із пришитими обов'язковими символами, і відкидає парольну фразу з чотирьох слів. Рядок із Перевіркою стійкості чесно показує межу мого власного інструмента: він рахує набір символів і довжину, тож не знає, що Password1! побудовано саме так, як кандидатів будує будь-який файл правил для зламу. Тому чорний список — перше з рекомендацій NIST, що я б додав.
Довжина перемагає вимоги до складу навіть для випадкових паролів. Ось середній час пошуку пароля на одній RTX 4090 з hashcat 6.2.6 проти несолоного MD5 (164,1 GH/s), за умови що пароль згенеровано випадково:
| Випадковий пароль | Простір ключів | MD5, одна RTX 4090 | bcrypt cost 10, одна RTX 4090 |
|---|---|---|---|
| 8 символів, увесь друкований ASCII (95) | 6,6 × 10¹⁵ | ~5,6 години | ~18 000 років |
| 15 символів, лише малі літери (26) | 1,7 × 10²¹ | ~162 роки | ~4,6 млрд років |
П'ятнадцять малих літер дають у 250 000 разів більший простір ключів, ніж вісім символів з усього ASCII. Паролі, які обирають люди, до цих чисел і близько не дотягують, бо атаки за словником і правилами пропускають більшу частину простору. Стовпець bcrypt (близько 5 750 спроб на секунду, виведено з бенчмарку для cost 5) показує другу половину роботи: зберігати паролі через повільний хеш із сіллю. Про зберігання детальніше в статті хешування паролів із сіллю, а Конструктор політики паролів експортує набір правил, де головне — довжина, у JSON або як регулярний вираз.
Якби я писав перевірку під час реєстрації сьогодні:
- Вимагати 15 символів (або 8, якщо MFA обов'язкова), дозволяти щонайменше 64, приймати пробіли й Unicode і рахувати кодові точки після нормалізації NFC.
- Прибрати вимоги до великих літер, цифр і спецсимволів.
- Відхиляти паролі, які є в базах витоків. API Pwned Passwords робить це через k-анонімність: ви надсилаєте перші 5 hex-символів SHA-1-хешу, отримуєте всі суфікси з цим префіксом і лічильником і порівнюєте локально, тож сам пароль ніколи не залишає ваш сервер.
- Ніколи не вимагати зміну за таймером; вимагати її, коли є ознаки, що пароль злили.
З чого почати сьогодні
Якщо робити щось одне, відкрийте налаштування поштової скриньки, замініть пароль на згенерований і додайте passkey або застосунок-автентифікатор. Потім переносьте кожен інший вхід у менеджер паролів під час наступного логіну, і повторені паролі зникнуть за кілька тижнів без великого прибирання.
FAQ
Як часто треба змінювати паролі?
Лише коли є причина: сайт зламали, ви використовували цей пароль ще десь або ввели його на сторінці, якій більше не довіряєте. NIST SP 800-63B Rev. 4 забороняє вимагати зміну за розкладом, бо люди відповідають на це паролями Password1, Password2, Password3.
Довга парольна фраза краща за короткий складний пароль?
Так, якщо слова обрано випадково. Шість слів зі списку EFF дають близько 77,5 біта, більше, ніж випадковий 10-символьний пароль зі спецсимволами (близько 65,7 біта). Фраза, яку ви вигадали самі, наприклад рядок із пісні, значно слабша, ніж здається з її довжини.