Опубліковано: · Оновлено: · автор: kodewright
10 поширених помилок з паролями, які роблять навіть експерти
Десять помилок з паролями, на яких досі ловляться розробники й досвідчені користувачі: від повторного використання до Math.random(), з цифрами й рішеннями.
Більшість порад про паролі написані для тих, хто досі користується 123456. Ці десять помилок — про інших людей: розробників, адмінів і уважних користувачів, які все знають, але підводить звичка, зручність або хибне уявлення про загрозу. Дві найгірші помилки зі списку я бачив зблизька: одну в інших людей, другу у власних акаунтах.
1. Один пароль для всіх акаунтів
Найгірша звичка, яку я бачив у реальному житті, водночас і найстаріша: один пароль скрізь. Неважливо, наскільки він складний. Щойно зламують будь-який сайт, де він зберігався, у зловмисників опиняється пара «ваш email + цей пароль», а інструменти для credential stuffing (підстановки викрадених облікових даних) автоматично прокручують її на поштових сервісах, у банках, магазинах і соцмережах, ще й через проксі, щоб обходити ліміти запитів.
Have I Been Pwned уже індексує понад 10 мільярдів зламаних акаунтів, тож «мій акаунт нікому не потрібен» не захищає. Ніхто не полює саме на вас: інструменти просто пробують усе підряд.
Рішення — унікальний випадковий пароль для кожного сайту, а на практиці це означає менеджер паролів. Якщо ви пам'ятаєте всі свої паролі напам'ять, частина з них точно повторюється або походить одна від одної.
2. Створити пароль і не зберегти його
Це моя власна помилка. Я поставив новий пароль на акаунт, не заніс його в менеджер паролів, а за кілька тижнів не мав жодного уявлення, яким він був. Нічого не зламали, але довелося проходити відновлення доступу, і воно добре нагадує, хто насправді контролює акаунт: той, хто читає вашу пошту.
Рішення — сталий порядок дій. Згенеруйте пароль, збережіть його в менеджері й лише потім надсилайте форму «змінити пароль». Більшість браузерних менеджерів пропонують зберегти пароль під час надсилання форми; не відкладайте це «на потім». Якщо користуєтеся окремим генератором, наприклад моїм Генератором паролів, який працює повністю у вашому браузері й нікуди не передає створене, спершу скопіюйте результат у менеджер.
3. Рахувати символи замість бітів
Довжина важлива, але лише разом із набором символів і лише якщо пароль випадковий. Ентропія випадкового пароля:
H = L × log₂(R)
H = entropy in bits, L = length, R = size of the character pool
Тут H — ентропія в бітах, L — довжина, R — кількість можливих символів.
| Набір символів | Розмір (R) | 8 символів | 12 символів | 16 символів | 20 символів |
|---|---|---|---|---|---|
| Цифри | 10 | 26,6 | 39,9 | 53,2 | 66,4 |
| Малі літери | 26 | 37,6 | 56,4 | 75,2 | 94,0 |
| Великі й малі літери | 52 | 45,6 | 68,4 | 91,2 | 114,0 |
| Літери + цифри | 62 | 47,6 | 71,5 | 95,3 | 119,1 |
| Друковані символи ASCII | 95 | 52,6 | 78,8 | 105,1 | 131,4 |
Двадцять малих літер (94 біти) все одно слабші за шістнадцять символів з повного ASCII (105 біт). І таблиця працює лише для випадкових рядків. У фрази з 20 символів, яку ви вигадали самі, ентропія значно нижча, ніж підказує довжина: інструменти для злому перебирають слова, фрази й клавіатурні патерни задовго до того, як дійдуть до перебору по символах. Де лежать корисні пороги, я розбирав у статті чому 12 символів — це мінімум.
4. Вважати правила складності метою
«Одна велика літера, одна цифра, один спецсимвол» дає Welcome1! і Password2026!. Обидва паролі проходять правило, і обидва серед перших кандидатів у будь-якій атаці за правилами, бо люди виконують вимогу однаково: велика перша літера, цифри й ! у кінці.
NIST SP 800-63B саме тому відмовився від правил складу. Натомість він вимагає від сервісів дозволяти довгі паролі (щонайменше 64 символи) і відхиляти ті, що є у списках зламаних і поширених паролів. Якщо ви робите сайт, впроваджуйте саме це. Як користувач, не орієнтуйтеся на мінімум із правила, а беріть згенерований пароль, який просто йому відповідає.
Застереження щодо індикаторів надійності, мого теж: Перевірка стійкості пароля рахує ентропію за набором символів і довжиною, тому оцінює Welcome1! набагато вище, ніж оцінила б атака за словником. Використовуйте її, щоб порівнювати випадкові паролі, а не щоб схвалити вигаданий.
5. Змінювати пароль, додаючи одиницю
Summer2025! стає Autumn2025!, Password7 стає Password8. Примусова зміна паролів породжує саме це, і зловмисник, який зламав одну версію вашого пароля, першими пробує очевидні наступні. NIST SP 800-63B каже, що сервіси взагалі не мають вимагати періодичної зміни, лише зміну за ознак компрометації.
Коли все ж змінюєте пароль, ставте новий випадковий. Видозмінений старий пароль не захищає від того, хто бачив старий.
6. Будувати паролі з власного життя
Клички тварин, дні народження дітей, вулиця, де ви виросли, улюблений футбольний клуб. Це здається приватним, але часто лежить у відкритому доступі в соцмережах, а словники для злому містять імена, дати й назви місць у всіх поширених форматах. Навіть без атаки саме на вас ім'я плюс рік — крихітний простір для перебору.
Якщо пароль легко запам'ятати, бо він для вас щось означає, вважайте, що його можна вгадати. Пам'ятати треба лише ті кілька паролів, які ви вводите без менеджера, і це мають бути випадкові парольні фрази (див. помилку 8).
7. Генерувати паролі через Math.random()
Це для розробників, які пишуть швидкий скрипт або ендпоінт «згенерувати тимчасовий пароль». Math.random() — не криптографічний генератор. У V8 він реалізований через xorshift128+, і його внутрішній стан можна відновити за кількома виходами, після чого всі минулі й майбутні значення стають передбачуваними.
Використовуйте CSPRNG (криптографічно стійкий генератор псевдовипадкових чисел) платформи: crypto.getRandomValues() у браузері та Node, secrets у Python, crypto/rand у Go. Стежте й за перетворенням випадкових байтів на символи. byte % charsetLength дає перекіс у бік деяких символів, коли 256 не ділиться націло на розмір набору; rejection sampling цього уникає.
// Unbiased random index in [0, n) using rejection sampling
function randomIndex(n) {
const limit = 256 - (256 % n);
const buf = new Uint8Array(1);
do { crypto.getRandomValues(buf); } while (buf[0] >= limit);
return buf[0] % n;
}
8. Слабкий майстер-пароль або віра в менеджер як у чарівну паличку
Менеджер паролів вирішує проблему повторного використання. Він не рятує від слабкого майстер-пароля, від фішингової сторінки, куди ви цей пароль введете, чи від шкідливої програми на комп'ютері, де сховище відкрите. Що захищають браузерні й окремі менеджери, а що ні, я порівнював у статті чи безпечні менеджери паролів у браузері.
Майстер-пароль — один із небагатьох, які доводиться пам'ятати, тож зробіть його випадковою парольною фразою. З великим словником EFF (7 776 слів) кожне випадково вибране слово додає близько 12,9 біта:
H = W × log₂(7776) ≈ W × 12.92
6 words ≈ 77.5 bits
Шість слів — це приблизно 2,2 × 10²³ можливих фраз. Слова має обирати випадковий процес (кубики або генератор), а не ви, і їх ніколи не можна брати з прикладу в статті. У Генераторі паролів є режим парольних фраз, який показує ентропію, поки ви змінюєте кількість слів.
9. Ігнорувати, як сайт зберігає ваш пароль
Скільки пароль протримається після витоку, залежить від хешу, який використав сайт, не менше, ніж від самого пароля. Онлайн-перебір обмежений: NIST SP 800-63B дозволяє не більше 100 невдалих спроб на акаунт, після чого сервіс має сповільнити або заблокувати вхід. Офлайн, після витоку бази, зловмисник перебирає з тією швидкістю, яку дозволяє хеш.
| Сценарій (одна RTX 4090, hashcat 6.2.6) | Спроб за секунду | 8 випадкових символів ASCII, у середньому |
|---|---|---|
| Онлайн-вхід із блокуванням | ~100 на акаунт загалом | Ніколи |
| Офлайн, MD5 | ~164 млрд | 5,6 години |
| Офлайн, bcrypt cost 10 | ~5 750 | Близько 18 000 років |
Ви не обираєте, як сайт хешує паролі. Але можна припускати найгірше для будь-якого сервісу, який виглядає старим чи дешевим, і давати йому довгий випадковий пароль: якщо його вводить менеджер, це вам нічого не коштує. Якщо ви самі робите системи входу, використовуйте bcrypt, scrypt або Argon2id з актуальними параметрами; Генератор bcrypt показує, як cost factor впливає на час хешування. Повна таблиця для інших довжин — у статті за скільки зламають пароль.
10. Виправити лише той акаунт, що витік
Коли приходить повідомлення про витік, більшість людей змінюють пароль на одному сайті й на цьому зупиняються. Якщо цей пароль або його близький варіант стояв деінде, саме ті акаунти зловмисники спробують наступними.
Після витоку знайдіть у менеджері всі акаунти з тим самим чи схожим паролем і замініть паролі на всіх, починаючи з пошти, бо через пошту відновлюється все інше. Потім увімкніть 2FA там, де її немає. Повний порядок дій я виклав у статті що робити в перші 48 годин після витоку даних.
Якщо сьогодні встигнете зробити лише одне, відкрийте у своєму менеджері паролів звіт про безпеку або «повторювані паролі» й пройдіться ним згори донизу.
FAQ
Яка найпоширеніша помилка з паролями?
Один пароль на кількох акаунтах. Витік з будь-якого сайту дає зловмисникам робочу пару «email + пароль», а інструменти для credential stuffing пробують її скрізь без участі людини.
Чи досі безпечний пароль із 12 символів у 2026 році?
Якщо він випадковий і використовує повний набір друкованих символів ASCII, так: близько 79 біт, і одній RTX 4090 знадобилося б у середньому понад 50 000 років, щоб перебрати їх навіть проти MD5. Якщо це 12 малих літер, виходить 56 біт, і проти MD5 такий пароль падає в середньому приблизно за 3,4 дня. Актуальні рекомендації NIST вимагають щонайменше 15 символів, коли пароль — єдиний фактор.
Чи стає пароль надійнішим, якщо часто його змінювати?
Ні. Зміна за графіком штовхає людей до передбачуваних шаблонів, і NIST SP 800-63B прямо каже сервісам її не вимагати. Змінюйте пароль, коли він витік або є підозра на це.
Що робити, якщо я забув пароль, який ніде не зберіг?
Скиньте його через відновлення доступу на сайті, а потім збережіть новий у менеджері паролів ще до підтвердження зміни. Заодно перевірте, чи актуальні ваші резервні email і телефон: саме вони повернули вам доступ.