przechowywanie haseł w czystym tekście

Przechowywanie haseł w czystym tekście to poważny błąd bezpieczeństwa — powinny być zapisywane jako skróty z solą.

Na czym polega przechowywanie hasła w czystym tekście

Przechowywanie haseł w czystym tekście oznacza zapisanie ich dokładnie w takiej postaci, w jakiej zostały podane przez użytkownika. W bazie danych może wtedy znajdować się na przykład ciąg Haslo123!, który można odczytać bez dodatkowych obliczeń, klucza kryptograficznego ani specjalnego programu. Taki sposób przechowywania nie zapewnia poufności. Osoba mająca dostęp do tabeli, kopii zapasowej, eksportu danych albo logów aplikacji może poznać rzeczywiste hasła użytkowników.

Hasło nie powinno być traktowane jak zwykła informacja konfiguracyjna. Jego wartość może być używana także w innych serwisach, szczególnie gdy użytkownik stosuje podobne hasła w wielu miejscach. Ujawnienie jednej tabeli może więc prowadzić do prób logowania do poczty, paneli zakupowych, usług chmurowych lub systemu operacyjnego. Problem dotyczy nie tylko włamania do serwera. Hasła zapisane jawnie mogą zostać ujawnione przez administratora, programistę, nieprawidłowo zabezpieczoną kopię zapasową, narzędzie diagnostyczne albo przypadkowo dołączony plik z danymi.

Dlaczego skrót hasła nie wystarcza bez soli

Właściwym rozwiązaniem jest przechowywanie wyniku funkcji przeznaczonej do ochrony haseł, a nie samego hasła. Przy sprawdzaniu logowania aplikacja pobiera hasło wpisane przez użytkownika, oblicza wynik przy użyciu tego samego mechanizmu i porównuje go z wartością zapisaną w bazie. Nie musi odzyskiwać pierwotnego hasła. Do takich zastosowań stosuje się funkcje adaptacyjne, między innymi Argon2id, scrypt, bcrypt lub PBKDF2, skonfigurowane z odpowiednimi parametrami kosztu obliczeniowego.

Samo użycie popularnego skrótu kryptograficznego, takiego jak SHA-256, nie jest wystarczającym zabezpieczeniem haseł. Funkcje ogólnego przeznaczenia są projektowane tak, aby działały bardzo szybko. To ułatwia atakującemu masowe sprawdzanie odgadniętych haseł, zwłaszcza przy wykorzystaniu kart graficznych lub wyspecjalizowanego sprzętu. Funkcja do przechowywania haseł powinna być celowo kosztowna obliczeniowo i umożliwiać dostosowanie czasu obliczeń oraz zużycia pamięci do możliwości używanego systemu.

Sól jest losową wartością dodawaną do każdego hasła przed obliczeniem skrótu. Powinna być unikatowa dla każdego konta i może być przechowywana obok wyniku w bazie danych, ponieważ nie jest tajnym kluczem. Jej zadaniem jest między innymi uniemożliwienie użycia jednej gotowej tablicy predefiniowanych skrótów dla wielu kont oraz sprawienie, że dwa identyczne hasła nie będą miały identycznych zapisów w bazie. Sól nie zastępuje odpowiedniej funkcji do ochrony haseł, lecz uzupełnia jej działanie.

Jak rozpoznać problem w aplikacji i konfiguracji

Oznaką przechowywania haseł w czystym tekście może być możliwość wyświetlenia pierwotnego hasła w panelu administracyjnym, wiadomości e-mail, raporcie lub logu. Nie jest to jednak jedyny sygnał. Podejrzane są również kolumny o nazwach takich jak password, user_password albo plain_password, których wartości mają czytelną postać, a także kod zawierający bezpośrednie porównanie hasła z wartością pobraną z bazy. W bezpiecznym projekcie dane uwierzytelniające nie powinny być zapisywane w logach ani przekazywane do modułów, które nie uczestniczą w procesie logowania.

Weryfikacja wymaga sprawdzenia całego przepływu danych: formularza logowania, warstwy aplikacji, zapytań do bazy, mechanizmu resetowania hasła, kopii zapasowych i komunikatów diagnostycznych. Nie wolno zakładać, że system jest bezpieczny tylko dlatego, że hasła nie są widoczne w głównej tabeli użytkowników. Mogą znajdować się w tabeli tymczasowej, historii zmian, pliku importu, zmiennej środowiskowej, pamięci podręcznej albo załączniku tworzonym podczas obsługi zgłoszeń. Szczególnie niebezpieczne jest logowanie pełnych obiektów żądania HTTP, ponieważ mogą one zawierać pola formularza z hasłem.

Postępowanie po wykryciu jawnych haseł

Po potwierdzeniu problemu należy usunąć możliwość dalszego zapisywania haseł w jawnej postaci, wdrożyć mechanizm przechowywania oparty na funkcji przeznaczonej do haseł i wygenerować nową sól dla każdego przetwarzanego hasła. Istniejących wartości zapisanych jako czysty tekst nie należy próbować „ukrywać” przez zwykłe szyfrowanie bez zaplanowania zarządzania kluczem. Jeżeli aplikacja musi znać pierwotną wartość, można ją odszyfrować, dlatego szyfrowanie ma inne właściwości niż jednokierunkowe przechowywanie hasła.

Gdy jawne hasła mogły zostać odczytane przez osoby nieuprawnione, potrzebna jest zmiana haseł użytkowników oraz unieważnienie aktywnych sesji, tokenów i innych danych służących do logowania, jeśli były powiązane z tym samym mechanizmem. Warto również sprawdzić, czy użytkownicy nie otrzymywali haseł w wiadomościach lub czy kopie zapasowe nie zawierają starej, niezabezpieczonej wersji bazy. Na komputerze użytkownika należy dodatkowo zweryfikować, czy problem nie wynika z programu zapisującego dane logowania w niechronionym pliku lub z rozszerzenia przeglądarki przechwytującego formularze.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów, w tym diagnostykę problemów związanych z oprogramowaniem użytkowanym na komputerze. Przy analizie takiego przypadku należy przekazywać wyłącznie niezbędne informacje techniczne, bez udostępniania rzeczywistych haseł ani pełnych baz danych zawierających dane logowania.