brak wymuszania złożoności haseł

Brak wymuszania złożoności haseł to alternatywne, powtórzone określenie tej samej luki bezpieczeństwa dotyczącej siły haseł.

Na czym polega brak wymuszania złożoności haseł

Brak wymuszania złożoności haseł oznacza, że system, aplikacja albo panel konfiguracyjny pozwala ustawić hasło bez sprawdzenia minimalnej siły. Nie musi to oznaczać pojedynczego błędu technicznego w kodzie. Częściej jest to nieprawidłowo ustawiona polityka uwierzytelniania, w której nie określono wymagań dotyczących długości, różnorodności znaków albo odporności na hasła powszechnie używane. Określenie „brak wymuszania złożoności haseł” może być więc powtórzonym opisem tej samej luki, która w innych miejscach jest nazywana zbyt słabą polityką haseł lub brakiem kontroli siły hasła.

W praktyce system może akceptować hasła takie jak „123456”, „password”, nazwa użytkownika, nazwa firmy albo prosty ciąg znaków powtarzanych. Jeżeli dodatkowo nie ma ograniczenia liczby prób logowania, takie hasło może zostać szybko odgadnięte metodą słownikową lub przez automatyczne testowanie wielu kombinacji. Sama obecność wielkiej litery i cyfry nie gwarantuje bezpieczeństwa, jeśli hasło jest krótkie albo znajduje się w znanym zestawie haseł. Długie, unikalne hasło składające się z kilku niepowiązanych słów może być trudniejsze do odgadnięcia niż krótki ciąg spełniający formalny wymóg kilku typów znaków.

Jak słaba polityka wpływa na logowanie

Siła hasła zależy przede wszystkim od liczby możliwych kombinacji oraz od tego, czy sposób jego utworzenia można przewidzieć. Dla losowego hasła o długości n wybranego z alfabetu mającego R znaków liczba kombinacji wynosi Rⁿ. Wzrost długości zwiększa przestrzeń poszukiwań wykładniczo, ale obliczenia te zakładają losowy wybór. Hasło utworzone według schematu „NazwaFirmy2026!” nie jest losowe, ponieważ napastnik może przewidzieć nazwę, rok i popularny znak końcowy.

Brak kontroli złożoności zwiększa ryzyko ataku brute force, czyli systematycznego sprawdzania kolejnych kombinacji, oraz ataku słownikowego, w którym testowane są gotowe listy słów, wyciekłych haseł i ich typowych modyfikacji. Hasła mogą być również sprawdzane w ramach credential stuffing, czyli prób logowania przy użyciu par login–hasło ujawnionych wcześniej w innym serwisie. Dlatego wymaganie unikalności jest równie ważne jak długość. Jeżeli aplikacja przechowuje hasła nieprawidłowo, na przykład bez bezpiecznego haszowania z użyciem indywidualnej soli, skutki przejęcia bazy mogą być jeszcze poważniejsze, ale jest to odrębny problem od samego braku wymuszania złożoności.

Rozpoznanie problemu w ustawieniach i zachowaniu programu

Sprawdzenie tej luki zaczyna się od ustalenia, jakie hasła system rzeczywiście przyjmuje. W kontrolowanym środowisku testowym można utworzyć konto z hasłem krótkim, popularnym, równym nazwie użytkownika oraz z hasłem zawierającym przewidywalny schemat. Jeżeli wszystkie takie wartości są akceptowane, polityka prawdopodobnie nie wymusza odpowiednich ograniczeń. Należy także sprawdzić, czy komunikat o wymaganiach jest zgodny z rzeczywistym zachowaniem formularza. Sam tekst wyświetlany użytkownikowi nie stanowi dowodu, że walidacja działa po stronie serwera.

Walidacja wyłącznie w interfejsie może zostać pominięta przez bezpośrednie wysłanie żądania do aplikacji. Z tego powodu reguły powinny być stosowane również po stronie serwera lub lokalnego mechanizmu uwierzytelniania, a zmiana hasła powinna podlegać tym samym zasadom co tworzenie konta. Warto zweryfikować minimalną długość, odrzucanie haseł znajdujących się na liście znanych wycieków, blokowanie haseł zawierających login oraz reakcję na wielokrotne nieudane logowania. Dodatkową kontrolę stanowią dzienniki zdarzeń: powtarzające się próby logowania z wielu adresów, nagły wzrost odrzuconych haseł albo logowania pochodzące z nietypowych miejsc mogą wskazywać na automatyczne testowanie poświadczeń.

Przywrócenie bezpiecznych zasad wyboru hasła

Usunięcie problemu wymaga włączenia rzeczywistej polityki haseł, a nie tylko dodania ostrzeżenia przy polu formularza. Reguły powinny wymagać odpowiedniej długości, odrzucać hasła powszechne i wcześniej ujawnione oraz zabraniać ponownego używania tego samego hasła w kilku usługach. W wielu przypadkach korzystniejsze jest zaakceptowanie długiego hasła lub frazy hasłowej niż wymuszanie krótkiego hasła z określoną liczbą symboli. Hasła nie powinny być przesyłane w logach ani wyświetlane w komunikatach diagnostycznych.

Po zmianie ustawień trzeba wykonać test tworzenia konta, zmiany hasła, odzyskiwania dostępu i logowania z istniejącymi poświadczeniami. Należy również sprawdzić, czy polityka obejmuje wszystkie konta lokalne używane przez system oraz aplikacje z własnym mechanizmem logowania. Dodatkową warstwę ochrony może zapewnić uwierzytelnianie wieloskładnikowe, ponieważ samo hasło nie jest wtedy jedynym warunkiem dostępu. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC, w tym diagnostyką problemów z oprogramowaniem, konfiguracją systemu oraz działaniem mechanizmów logowania.