Чому пароль залишається слабкою ланкою
Можна закрити сервер за всіма правилами, налаштувати безпеку сайту і все одно втратити акаунт через один слабкий пароль. Причина проста: люди повторюють паролі. Один і той самий пароль стоїть на пошті, у магазині й на форумі — і коли форум зливають, тим самим паролем відкривають пошту, а через пошту — все інше.
Атака називається credential stuffing: зловмисник бере мільйони пар «логін-пароль» зі старих витоків і автоматично підставляє їх на інших сайтах. Йому не потрібно вас зламувати — за нього це вже зробили. Тому надійність пароля — це не про складність запам'ятовування, а про два правила: він має бути довгим і унікальним для кожного сайту.
Як витікають паролі
Пароль рідко «вгадують». Значно частіше він витікає цілими базами:
- Злам сервісу — база користувачів із паролями потрапляє в мережу. Якщо паролі зберігалися погано, їх швидко розшифровують.
- Фішинг — ви самі вводите пароль на підробленій сторінці, невідрізнній від справжньої.
- Шкідливе ПЗ — стилери збирають збережені в браузері паролі просто із зараженого пристрою.
- Повторне використання — витік на одному сайті автоматично компрометує всі інші, де стоїть той самий пароль.
Підсумок завжди один: пароль опиняється в публічних базах, яких уже сотні мільйонів записів. Добра новина — за цими самими базами можна перевірити, чи засвітився ваш пароль, і зробити це безпечно.
Що робить пароль надійним
Надійність вимірюється не наявністю «спецсимволу», а ентропією — кількістю варіантів, які довелося б перебрати. Довжина впливає на неї сильніше, ніж екзотичні символи: пароль із чотирьох випадкових слів надійніший за короткий «P@ss1!».
- Довжина — щонайменше 12–16 символів, для важливих акаунтів більше.
- Випадковість — не ім'я, дата чи слово зі словника, а справді випадковий набір.
- Унікальність — свій пароль для кожного сайту, щоб один витік не відкривав решту.
Вигадувати таке в голові немає сенсу. Простіше згенерувати: наш генератор паролів створює довгий випадковий пароль прямо в браузері, криптостійко і не надсилаючи його нікуди.
Як перевірити пароль на витік
Перевірити, чи є пароль у відомих витоках, можна, не розкриваючи сам пароль. Працює це за моделлю k-анонімності: пароль хешується прямо в браузері, на сервер ідуть лише перші п'ять символів хеша, у відповідь приходить список відповідних під цей префікс — і збіг шукається вже локально. Сервер ніколи не бачить ні пароля, ні його повного хеша.
Саме так влаштована наша перевірка пароля на витік: вона звіряє пароль із базою Have I Been Pwned, нічого не зберігаючи. Якщо пароль знайшовся у витоках — вважайте його скомпрометованим і змініть скрізь, де використовували. Таку саму перевірку корисно вбудовувати у форму реєстрації та зміни пароля, щоб попереджати користувача про ненадійний пароль ще до того, як він його встановить.
Менеджери паролів і двофакторна автентифікація
Довгі унікальні паролі неможливо тримати в голові — і не потрібно. Менеджер паролів генерує, зберігає і підставляє їх за вас; ви пам'ятаєте лише один майстер-пароль. Це єдиний практичний спосіб мати різний надійний пароль на кожному сайті.
Другий шар — двофакторна автентифікація (2FA). Навіть якщо пароль витік, без другого фактора увійти не вийде. Порядок надійності: апаратний ключ або застосунок-автентифікатор надійніші за коди по SMS, які перехоплюють через підміну SIM. Увімкніть 2FA хоча б на пошті та в банку — це ті акаунти, через які відновлюють усі інші.
Як зберігати паролі на бекенді (для розробників)
Якщо ви робите сервіс із реєстрацією, відповідальність за паролі користувачів на вас. Базові правила не обговорюються:
- Ніколи не зберігайте паролі у відкритому вигляді і не шифруйте їх оборотно — лише незворотний хеш.
- Використовуйте повільні адаптивні функції — bcrypt, scrypt або argon2 — із сіллю для кожного пароля. Звичайний SHA-256 для цього не годиться: він надто швидкий і підбирається на GPU.
- Перевіряйте нові паролі на витік під час реєстрації та зміни — за тією самою k-анонімністю, не надсилаючи пароль назовні.
- Обмежуйте спроби входу і додавайте 2FA, щоб витік бази не означав миттєвий доступ.
Ми закладаємо це в архітектуру, коли робимо вебзастосунки та SaaS: автентифікація і зберігання секретів проєктуються з самого початку, а не прикручуються потім.
Чек-лист безпеки паролів
- Довгий (12+), випадковий і унікальний пароль для кожного сайту.
- Менеджер паролів замість запам'ятовування і повторів.
- Двофакторна автентифікація скрізь, де є, — хоча б на пошті та в банку.
- Перевірка важливих паролів на витік; за збігу — негайна зміна.
- Для розробників: argon2/bcrypt із сіллю, ліміт спроб, перевірка на витік під час реєстрації.
Часті запитання
Чи безпечно перевіряти пароль на чужому сайті?
Залежить від того, як влаштована перевірка. Правильна перевірка використовує k-анонімність: пароль хешується у вашому браузері й назовні йдуть лише перші п'ять символів хеша, тому сам пароль сервер не бачить. Ніколи не вводьте пароль у форму, яка надсилає його цілком.
Який пароль вважається надійним у 2026 році?
Довгий, випадковий і унікальний. Практичний мінімум — 12–16 символів без словникових слів і особистих даних, свій для кожного сайту. Довжина важливіша за «спецсимволи»: фраза з кількох випадкових слів надійніша за короткий набір знаків.
Чи потрібен менеджер паролів?
Так, це найпрактичніший спосіб мати різний надійний пароль скрізь. Ви запам'ятовуєте один майстер-пароль, а менеджер створює і підставляє решту. Ризик компрометації самого менеджера значно нижчий за ризик повторного використання паролів.
SMS-коди — це надійна двофакторна автентифікація?
Краще, ніж нічого, але слабше за інші варіанти: коди по SMS перехоплюють через підміну SIM. Застосунок-автентифікатор або апаратний ключ надійніші. Але будь-яка 2FA значно краща за її відсутність.
Як правильно зберігати паролі користувачів на сервері?
Лише незворотним хешем через argon2, scrypt або bcrypt з унікальною сіллю для кожного пароля — ніколи у відкритому вигляді і не оборотним шифруванням. Звичайний SHA надто швидкий і не підходить. Додатково обмежуйте спроби входу і пропонуйте 2FA.
