Najlepsze praktyki bezpieczeństwa losowych ciągów znaków

Najkrytyczniejszą decyzją bezpieczeństwa podczas generowania losowych ciągów znaków jest użycie kryptograficznie bezpiecznego generatora liczb losowych (CSPRNG). Nie można tego wystarczająco podkreślić: niekryptograficzne generatory jak Math.random() doprowadziły do rzeczywistych naruszeń bezpieczeństwa w systemach produkcyjnych.

CSPRNG są specjalnie zaprojektowane, aby opierać się przewidywaniu i analizie. Używają entropii ze źródeł, których atakujący nie mogą obserwować ani kontrolować: timing systemowy, zdarzenia sprzętowe, czujniki środowiskowe. Ta entropia seeduje algorytmy zaprojektowane tak, aby być obliczeniowo nieprzewidywalne lub nieodwracalne. Nawet jeśli atakujący obserwuje miliony wartości losowych, nie może przewidzieć przyszłych wartości ani określić przeszłych wartości.

Web Crypto API zapewnia crypto.getRandomValues() dla środowisk przeglądarkowych. W Node.js użyj crypto.randomBytes(). W Pythonie użyj modułu secrets (nie modułu random). W Javie użyj SecureRandom. W C# użyj RNGCryptoServiceProvider. Każda większa platforma zapewnia funkcje CSPRNG - używaj ich.

Math.random() i podobne niekryptograficzne generatory to deterministyczne algorytmy, które produkują sekwencje wyglądające na losowe, ale całkowicie przewidywalne. Są seedowane pojedynczą wartością, a cała sekwencja jest określona przez ten seed. Atakujący, którzy odkryją lub zgadną seed, mogą odtworzyć całą sekwencję, przewidując wszystkie "losowe" wartości. Te generatory są w porządku do symulacji, gier lub efektów wizualnych, ale katastrofalne dla bezpieczeństwa.

Rzeczywiste naruszenia wynikały z używania słabych generatorów liczb losowych. Tokeny sesji generowane przewidywalnymi RNG były wykorzystywane do przejmowania sesji użytkowników. Tokeny uwierzytelniające z niewystarczającą losowością umożliwiły nieautoryzowany dostęp. Jeden godny uwagi przypadek dotyczył podpisów ECDSA z przewidywalną losowością, co pozwoliło atakującym odzyskać klucze prywatne. Lekcja jest jasna: operacje kryptograficzne wymagają kryptograficznej losowości.

Weryfikacja, że Twój generator jest bezpieczny, wymaga sprawdzenia dokumentacji i kodu źródłowego. Upewnij się, że używasz kryptograficznych funkcji losowych, nie funkcji wygodnych, które mogą używać słabszych generatorów. W przeglądach kodu oznaczaj każde wrażliwe na bezpieczeństwo generowanie losowości, które nie używa jawnych funkcji CSPRNG. To nisko wiszący owoc, który zapobiega podatnościom o wysokiej wadze.

Generowanie bezpiecznych losowych ciągów znaków to tylko połowa sukcesu. Sposób ich przechowywania i transmisji określa, czy pozostaną bezpieczne, czy staną się podatnościami.

Nigdy nie przechowuj tokenów uwierzytelniających jako czysty tekst w swojej bazie danych. Jeśli Twoja baza danych zostanie naruszona, atakujący natychmiast mają wszystkie ważne tokeny. Zamiast tego haszuj tokeny przed zapisaniem za pomocą kryptograficznego hasha jak SHA-256. Podczas weryfikacji tokenu haszuj podany token i porównuj hasze. W ten sposób naruszenie bazy danych nie ujawnia użytecznych tokenów.

Dla tokenów sesji rozważ zaszyfrowane ciasteczka zamiast przechowywania po stronie serwera. Zaszyfrowane ciasteczka sesji przechowują dane sesji po stronie klienta, zaszyfrowane kluczem tajnym znanym tylko serwerowi. To eliminuje przechowywanie po stronie serwera i związane zapytania do bazy danych. Wymaga jednak starannej implementacji: używaj uwierzytelnionego szyfrowania (jak AES-GCM), starannie chroń klucze szyfrowania i ogranicz rozmiar ciasteczka.

Zawsze przesyłaj tokeny przez HTTPS, nigdy przez zwykłe HTTP. HTTP przesyła dane jako czysty tekst, pozwalając atakującym sieciowym przechwytywać tokeny przez ataki man-in-the-middle lub pasywne podsłuchiwanie. HTTPS szyfruje komunikację, chroniąc tokeny podczas transmisji. To nie jest negocjowalne dla żadnego tokenu używanego do uwierzytelniania lub autoryzacji.

Umieszczaj tokeny w nagłówkach autoryzacji zamiast parametrów URL, jeśli to możliwe. URL-e są logowane przez serwery webowe, serwery proxy i przeglądarki. Pojawiają się w historii przeglądarki i zakładkach. Są często udostępniane, gdy użytkownicy kopiują i wklejają URL-e. Umieszczenie tokenów w nagłówkach autoryzacji utrzymuje je poza logami i zapobiega przypadkowemu ujawnieniu przez udostępnione URL-e.

Klucze API w szczególności nie powinny nigdy pojawiać się w URL-ach ani kontroli wersji. Używaj zmiennych środowiskowych lub bezpiecznych systemów zarządzania konfiguracją. Regularnie rotuj klucze API i natychmiast, gdy mogą być skompromitowane. Wiele naruszeń bezpieczeństwa występuje, ponieważ deweloperzy commitują klucze API do publicznych repozytoriów GitHub, gdzie automatyczne skanery znajdują i wykorzystują je w ciągu minut.

Implementuj rotację tokenów dla długotrwałych sesji. Wydawaj krótkoterminowe tokeny dostępu (godziny) i dłuższe tokeny odświeżania (dni/tygodnie). Klienty używają tokenów odświeżania do uzyskania nowych tokenów dostępu bez ponownego uwierzytelniania. Jeśli token dostępu zostanie skompromitowany, wkrótce wygasa. Tokeny odświeżania mogą być jednorazowego użytku i unieważniają się, gdy są używane do uzyskania nowego tokenu dostępu. To ogranicza okno czasowe dla atakujących.

Monitoruj podejrzane użycie tokenów. Loguj, kiedy tokeny są używane, z jakich adresów IP, do jakich zasobów. Alarmuj o anomaliach: tokeny używane z wielu IP, nietypowe wzorce dostępu lub nieudane próby weryfikacji. Szybkie wykrycie i reakcja mogą ograniczyć szkody spowodowane przez skompromitowane tokeny.