Generator Losowych Ciągów — jak i dlaczego generować bezpieczne tokeny, hasła i klucze
Generator losowych ciągów to narzędzie do tworzenia sekwencji znaków z danego zestawu (alfabet, cyfry, znaki specjalne) o pożądanej długości. Takie ciągi są używane w tworzeniu oprogramowania, testowaniu, bezpieczeństwie informacji i administracji systemami. Nasz generator działa w oparciu o kryptograficznie bezpieczny algorytm crypto.getRandomValues(), wbudowany w każdą nowoczesną przeglądarkę.
Bezpieczeństwo kryptograficzne: dlaczego to ważne
Nie wszystkie generatory liczb losowych są takie same. Zwykły Math.random() w JavaScript jest pseudolosowy i przewidywalny — nie nadaje się do generowania haseł, tokenów lub kluczy szyfrowania. Metoda crypto.getRandomValues() należy do klasy CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) i wykorzystuje źródło entropii systemu operacyjnego. Ta sama metoda jest używana w TLS/SSL, Web Crypto API, generowaniu tokenów JWT i innych krytycznych systemach. Nasz generator używa wyłącznie crypto API, zapewniając maksymalną wytrzymałość generowanych ciągów.
Generowanie haseł: długość, entropia, wytrzymałość
Bezpieczne hasło ma wystarczającą entropię — miarę nieprzewidywalności. Entropia obliczana jest jako długość ciągu pomnożona przez logarytm rozmiaru alfabetu o podstawie 2. Dla hasła z zestawu a-z, A-Z, 0-9 (62 znaki) każdy znak dodaje ~5,95 bitu entropii. Hasło 12-znakowe ma ~71 bitów, 16-znakowe — ~95 bitów, 20-znakowe — ~119 bitów. Zalecenia NIST (SP 800-63B) przewidują minimum 8 znaków dla usług online, ale współczesna praktyka to 14-20 znaków z mieszanym zestawem.
Tokeny autoryzacji i klucze API
Tokeny (access token, refresh token, klucz API) to tajne ciągi potwierdzające prawa dostępu do zasobu. Dla kluczy API standardowa długość to 32-64 znaki alfanumeryczne, zapewniające 190-380 bitów entropii. Identyfikatory sesji muszą mieć minimum 128 bitów entropii zgodnie z zaleceniami OWASP. Tokeny CSRF, wartości nonce i jednorazowe kody potwierdzające są również generowane przy użyciu CSPRNG.
UUID v4: uniwersalny unikalny identyfikator
UUID v4 (RFC 4122) to 128-bitowy identyfikator, gdzie 122 bity są losowe, a 6 bitów jest zarezerwowanych dla wersji i wariantu. Format: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, gdzie y to jeden ze znaków 8, 9, a, b. UUID v4 zapewnia 2^122 (~5,3 × 10^36) możliwych wartości, czyniąc prawdopodobieństwo kolizji znikomo małym nawet przy generowaniu miliardów identyfikatorów. UUID jest szeroko stosowany jako klucz główny w PostgreSQL, MongoDB, architekturach mikrousług i systemach rozproszonych.
HEX i Base64: formaty kodowania
HEX (kodowanie szesnastkowe) reprezentuje każdy bajt dwoma znakami (0-9, a-f). Używany do haszy (SHA-256 = 64 znaki HEX), adresów MAC, kolorów CSS (#FF5733) i kluczy szyfrowania. Base64 koduje trzy bajty czterema znakami z alfabetu A-Z, a-z, 0-9, +, / (i = do wyrównania). Stosowany do kodowania JWT, osadzania obrazów w HTML (data URI), przesyłania danych binarnych w JSON i XML.
Sól i hashowanie haseł
Sól (salt) to losowy ciąg dodawany do hasła przed hashowaniem w celu ochrony przed tęczowymi tabelami (rainbow tables) i atakami siłowymi. Każdy użytkownik powinien mieć unikalną sól. Zalecana długość soli to minimum 16 bajtów (32 znaki HEX lub 22 znaki Base64). Nowoczesne algorytmy hashowania (bcrypt, Argon2, scrypt) generują sól automatycznie, ale dla innych scenariuszy — na przykład HMAC lub szyfrowanie — sól musi być generowana osobno.
Dane testowe dla rozwoju
Losowe ciągi są niezbędne w testowaniu: wypełnianie pól formularzy, tworzenie danych mock, testowanie obciążenia, weryfikacja walidacji i ograniczeń długości. Generator pozwala szybko utworzyć tysiąc ciągów potrzebnej długości z dowolnym zestawem znaków — i pobrać je jako plik tekstowy do importu do testowej bazy danych lub skryptu.
Porady bezpieczeństwa przy pracy z tajnymi ciągami
Wygenerowane hasła, klucze i tokeny powinny być przechowywane w menedżerze haseł (1Password, Bitwarden, KeePass) lub w bezpiecznym magazynie sekretów (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager). Nigdy nie przechowuj sekretów w postaci jawnej w kodzie, konfiguracjach lub repozytorium (git). Do przekazywania sekretów między członkami zespołu używaj zaszyfrowanych kanałów lub jednorazowych linków (np. OneTimeSecret). Rotacja kluczy i tokenów jest obowiązkową praktyką: zmieniaj klucze API i tokeny usług co najmniej raz na 90 dni.