Wytrzymałość haseł: obliczenia dla deweloperów

Analiza wytrzymałości haseł: obliczenia i rekomendacje dla programistów

Hasła nadal stanowią podstawowy mechanizm uwierzytelniania dzięki prostocie implementacji i zrozumieniu przez użytkowników. Login identyfikuje konto, a hasło potwierdza znane hasło. Mimo istnienia alternatyw takich jak klucze sprzętowe, OTP, biometria czy WebAuthn, hasła dominują w systemach o niskim progu dostępu.

Na przykład WebAuthn wykorzystuje szyfrowanie asymetryczne: klucz prywatny pozostaje na urządzeniu, serwer sprawdza podpis za pomocą klucza publicznego. Biometria przechowywana jest lokalnie, nie przesyłana do serwera, co minimalizuje ryzyko wycieków.

Rzeczywista wytrzymałość: obliczenia matematyczne

Każde hasło można przeanalizować metodą siły wymuszonej — bezpieczeństwo zależy od ekonomicznej nieopłacalności ataku. Obliczmy czas przebicia dla różnych konfiguracji.

Dla 5-cyfrowego PIN-u (10^5 = 100 000 kombinacji) przy 10 próbach/sekundę — kilka sekund. Z botnetem z 10 000 urządzeń (100 000 prób/sekundę) — mniej niż 9 minut dla 36-symbolowego alfabetu (36^5 ≈ 52 miliony).

Rozszerzamy alfabet:

• 62 symbole (duże i małe litery + cyfry): 62^5 ≈ 916 milionów, ~2,5 godziny z botnetem.
• 95 symboli (+znaki specjalne): 95^5 ≈ 7,7 miliarda, ~21 godzin.

Kluczowy czynnik — długość. Dla 8 znaków z 95 symboli: 95^8 ≈ 6,6×10^15, >2000 lat przy 100 000 prób/sekundę. Nawet bez znaków specjalnych (62^8 ≈ 2,2×10^14) — ~70 lat.

| Alfabet | Długość | Kombinacje | Czas (100k/sek) |

|---------|-------|------------|------------------|

| 36 | 5 | 52 miliony | 9 min |

| 62 | 5 | 916 milionów | 2,5 h |

| 95 | 5 | 7,7 miliarda | 21 h |

| 62 | 8 | 218 bilionów | 70 lat |

| 95 | 8 | 6,6 biliarda | 2000+ lat |

Limitowanie liczby prób (throttlingu) jest konieczne: ograniczenie liczby prób/IP zmusza do używania rozproszonych botnetów, co znacznie zwiększa koszty ataku.

Ataki słownikowe i wzory

Pełna siła wymuszonego przebrania nieefektywna przeciwko długim hasłom. Prawdziwym zagrożeniem są ataki słownikowe i credential stuffing.

Przykłady wrażliwych haseł:

• Qwertyuio1 — wzór klawiatury.
• Abcdefghi0 — sekwencja.
• P@ssW0rD36 — wersja leetspeak.
• Ghbdtn — układ klawiatury QWERTY dla "Cześć".

Rekomendacja: passphrase z 4–6 losowych słów (słownik ~20 000: 20 000^4 = 1,6×10^17, dziesiątki tysięcy lat przebrania). Unikaj cytowań, używaj separatorów.

Kody PIN (4 cyfry) są chronione nie wytrzymałością, ale ograniczeniem liczby prób (3–10), zabezpieczeniem sprzętowym hashowania.

Błędy programistów przy przechowywaniu haseł

Na serwerze hasła przechowywane są jako hashe (bcrypt, Argon2, scrypt). Typowe błędy:

• Przechowywanie w postaci jawnej lub słabego MD5/SHA-1.
• Brak soli — tabele rainbow.
• Słabe hasze bez iteracji (szybkie przebranie GPU).
• Brak throttlingu lub CAPTCHA.
• Credential stuffing bez sprawdzania unikalności login-hasło w bazach wycieków (Have I Been Pwned?)

Poprawny stos: Argon2id z parametrami memory-hard, unikalna sól na użytkownika, limitowanie częstotliwości (np. 5 prób/min/IP).

Praktyczne rekomendacje

Dla użytkowników:

• Unikalne hasło na każdy serwis.
• Długość ≥12 znaków lub passphrase (4+ słowa).
• Menadżery haseł:

* Lokalne (KeePassXC): pełna kontrola, ręczna synchronizacja.

* Chmurowe (Bitwarden): automatyczna synchronizacja, hasło główne.

• Włącz 2FA (TOTP, nie SMS).

Dla programistów:

• Wymagaj passphrase lub ≥16 znaków.
• Hashuj z Argon2 (p=2, m=64MB, t=3).
• Limitowanie częstotliwości: eksponencjalny backoff.
• Passkey/WebAuthn dla nowych systemów.
• Monitorowanie wycieków.

Co jest ważne

• Długość hasła ma większy wpływ niż różnorodność znaków: 95^8 >> 62^12 pod względem wytrzymałości.
• Throttling + botnety = wykładniczy wzrost kosztów ataku.
• Passphrase z losowych słów zapewnia ponad 10^17 kombinacji.
• Przechowuj tylko hashe z solą i Argon2; plaintext = natychmiastowy kompromis.
• Unikalność haseł zapobiega credential stuffing.

— Editorial Team