Скільки живе пароль під перебором на 8× RTX 4090
Скільки часу займає повний перебір випадкового пароля на GPU-комплексі - і чому довжина важить більше за набір символів.
Стійкість пароля зазвичай уявляють як «складність»: додайте цифру, велику літеру, знак оклику. Але математика перебору каже інше. Вирішує не набір символів, а довжина - і різниця тут не в рази, а на порядки.
Нижче - оцінка часу повного перебору випадкового пароля на реальному GPU-комплексі з восьми NVIDIA RTX 4090. Усі числа перевірені незалежним розрахунком.
Що саме рахуємо
Парольний простір - це кількість усіх можливих паролів заданої довжини:
K = N^Lде N - розмір алфавіту, L - довжина. Максимальний час перебору - це
весь простір, поділений на швидкість:
T_max = N^L / RСередній очікуваний час - половина від нього, бо правильний пароль з рівною ймовірністю лежить будь-де. Це верхня межа для випадкового пароля: атакувальник не знає нічого про його структуру і змушений перебирати все.
Важливе застереження одразу: рахуємо офлайн-перебір. Атакувальник уже має копію бази хешів і перевіряє кандидатів на власному залізі. Серверні захисти - блокування після невдалих спроб, CAPTCHA, затримки - тут не діють. Саме тому витік бази хешів такий небезпечний.
Платформа
Базова швидкість береться для алгоритму NTLM на восьми RTX 4090:
R = 2.24 × 10¹² хешів/с (280 GH/s на карту × 8)NTLM обрано навмисно: це один із найшвидших алгоритмів, тобто найгірший сценарій для захисника - максимальна швидкість, яку може мати атакувальник для типового швидкого хешу. Для MD5, SHA-1, SHA-256 швидкість нижча, але того ж порядку; для спеціалізованих алгоритмів захисту паролів - на багато порядків нижча (про це наприкінці).
Головна таблиця
Максимальний час повного перебору випадкового пароля для чотирьох алфавітів. Значення округлено до трьох значущих цифр.
| Довжина | Лише цифри (N=10) | Лише літери (N=52) | Цифри + літери (N=62) | Усі ASCII (N=95) |
|---|---|---|---|---|
| 6 | 0.446 мкс | 8.83 мс | 25.4 мс | 0.328 с |
| 8 | 44.6 мкс | 23.9 с | 1.62 хв | 49.4 хв |
| 10 | 4.46 мс | 17.9 год | 4.34 доби | 309 діб |
| 12 | 0.446 с | 5.53 року | 45.6 року | 7.64 тис. років |
| 14 | 44.6 с | 14.95 тис. років | 175 тис. років | 69.0 млн років |
| 16 | 1.24 год | 40.4 млн років | 674 млн років | 623 млрд років |
| 18 | 5.17 доби | 109 млрд років | 2.59 трлн років | 5.62 × 10¹⁵ років |
Прочитайте таблицю двічі - по стовпцях і по рядках. Це дві різні історії.
Довжина проти набору символів
По рядку видно вплив алфавіту. Візьмемо 12 символів: цифровий пароль падає за пів секунди, а той самий з усього ASCII тримається тисячі років. Різниця величезна - але вона стала.
По стовпцю видно вплив довжини, і саме тут ховається головний висновок. Кожен додатковий символ множить увесь простір на розмір алфавіту:
- цифри - ×10 за символ;
- літери - ×52;
- цифри й літери - ×62;
- увесь ASCII - ×95.
Оскільки крок таблиці - два символи, час між сусідніми рядками зростає у N²
разів: ×100, ×2704, ×3844, ×9025. Це не додавання секунд - це множення
всього попереднього часу на сталий коефіцієнт.
Звідси практичний висновок, який суперечить інтуїції:
Довгий пароль із простішого алфавіту зазвичай стійкіший за короткий пароль із максимально можливим набором символів.
Порівняйте: восьмисимвольний пароль з усього ASCII перебирається за 49 хвилин, а чотирнадцятисимвольний лише з літер - за майже 15 тисяч років. Спецсимволи не рятують коротку довжину.
Чому це справедливо лише для випадкових паролів
Уся таблиця дійсна тільки тоді, коли пароль - випадковий рядок. Пароль
Password2026!має 13 символів і формально належить простору 95¹³. Але його структура
передбачувана: словникове слово, велика перша літера, поточний рік, типовий
знак наприкінці. Атакувальник перевірить таку конструкцію задовго до того,
як торкнеться помітної частки простору - словниками, витоками, правилами
мутації, а за потреби й генеративними моделями на кшталт PassGAN.
Числам таблиці відповідають рядки на кшталт T7vN2cR8pK5m, а не Dubai2026.
Математична довжина не дорівнює ентропії.
Швидкі хеші проти повільних
Усе вище - для NTLM, швидкого хешу. Але сам алгоритм зберігання змінює R на
багато порядків, не чіпаючи N^L:
| Властивість | NTLM | bcrypt | Argon2id |
|---|---|---|---|
| Призначення | швидке хешування | захист паролів | захист паролів |
| Регульована вартість CPU | ні | так (cost factor) | так |
| Регульована пам’ять | ні | ні | так |
| Стійкість до GPU-перебору | низька | значно вища | висока |
bcrypt навмисно дорогий: збільшення cost factor на одиницю приблизно подвоює роботу. Argon2 йде далі - робить кожну перевірку ще й пам’яткомісткою, що прямо б’є по головній перевазі GPU: масовому паралелізму. Якщо одна перевірка вимагає 64 MiB, кількість одночасних задач обмежена обсягом відеопам’яті, поділеним на цей розмір.
Формула часу лишається тією самою, змінюється лише R:
T = N^L / RТому захист двошаровий і обидва шари обов’язкові. Користувач дає довжину й випадковість. Система дає повільний алгоритм (Argon2id за замовчуванням, RFC 9106), унікальну сіль на кожен пароль і достатні параметри вартості. Слабкий пароль під сильним алгоритмом усе одно впаде на словнику - сильний алгоритм не додає ентропії, він лише робить кожну спробу дорожчою.
Які висновки з цього зробити
- Проти офлайн-перебору довжина вирішальна. Кожні два символи - новий порядок складності; ширший алфавіт дає разовий, а не наростаючий виграш.
- 8 символів не рятує навіть повний ASCII - 49 хвилин. Практична межа для випадкового пароля починається з 12 символів і впевнено тримається з 14.
- Числа справедливі лише для випадкових паролів. Передбачувані конструкції падають набагато раніше за будь-яку таблицю.
- Нарощування заліза скорочує час лінійно; кожен доданий символ збільшує простір експоненційно. Ця асиметрія - на боці захисника.
- Зберігати паролі треба спеціалізованим алгоритмом (Argon2id, bcrypt) із сіллю, а не швидким хешем.
Максимальна стійкість - це не одна властивість, а сума: довгий випадковий пароль + унікальна сіль + повільне хешування + правильні параметри.