Dlaczego hasła z AI są niebezpieczne? Wnioski z raportu Irregular i praktyczne rekomendacje dla użytkowników i firm

Dlaczego hasła generowane przez AI stały się problemem bezpieczeństwa

Sztuczna inteligencja w krótkim czasie stała się codziennym narzędziem pracy. Używamy modeli językowych do pisania tekstów, generowania kodu, tworzenia analiz i podsumowań. W naturalny sposób część użytkowników zaczęła traktować te same narzędzia jako wygodny sposób na tworzenie haseł – wystarczy wpisać polecenie typu: „wygeneruj silne hasło z wielkich i małych liter, cyfr i symboli” i skopiować otrzymany ciąg znaków.

Na pierwszy rzut oka brzmi to rozsądnie. Polityki bezpieczeństwa w firmach wymagają coraz bardziej złożonych haseł, użytkownicy nie mają pomysłów na kolejne kombinacje, a presja, aby „wymyślić coś trudnego do złamania”, rośnie. Modele takie jak ChatGPT, Claude czy Gemini wydają się idealnym rozwiązaniem: zwracają ciągi zawierające litery, cyfry i znaki specjalne, które wyglądają na skomplikowane.

Badanie przeprowadzone przez firmę Irregular, specjalizującą się w bezpieczeństwie, pokazuje jednak, że pozorna „siła” takich haseł jest złudna. Zespół badawczy poprosił popularne modele językowe o wygenerowanie krótkich, sześcioznakowych haseł złożonych z liter, cyfr i symboli. Wyniki wizualnie spełniały typowe kryteria bezpieczeństwa, ale szczegółowa analiza ujawniła silną przewidywalność i powtarzalne schematy.

To kluczowa różnica między AI a prawdziwym generatorem losowym. Generator kryptograficzny korzysta z wysokiej jakości źródeł entropii (np. szumów sprzętowych), aby tworzyć nieprzewidywalne ciągi znaków. Model językowy działa zupełnie inaczej – jego celem jest przewidzenie najbardziej prawdopodobnego kolejnego znaku w oparciu o statystykę danych treningowych. Nie jest projektowany jako narzędzie kryptograficzne i nie gwarantuje losowości na poziomie wymaganym w bezpieczeństwie.

Konsekwencje dotyczą zarówno zwykłych użytkowników, jak i administratorów systemów czy osób tworzących polityki bezpieczeństwa w organizacjach. Jeżeli w instrukcjach lub szkoleniach pada zalecenie „skorzystaj z asystenta AI, aby wygenerować silne hasło”, w praktyce wprowadzamy do środowiska IT duże, ale ukryte ryzyko systemowe.

Rosnące wykorzystanie AI w pracy i życiu codziennym dodatkowo zaciera granicę między zadaniami, do których modele się nadają, a tymi, w których ich użycie jest wręcz niebezpieczne. W analizie wpływu automatyzacji na web development, opisanej w artykule „AI and PHP: Can the Old Guard of Web Development Survive the Automation Boom?”, widać wyraźnie, że AI świetnie wspiera twórców kodu, ale nie powinna automatycznie przejmować zadań krytycznych. W obszarze haseł ta zasada jest jeszcze ważniejsza. Podobne wnioski płyną z analizy generatorów grafiki i systemów AI w artykule „Alibaba AI kontra GPT-Image OpenAI: jak nowe narzędzia zmieniają pracę grafików, marketerów i twórców treści”, gdzie szczegółowo omawiane są ryzyka prompt injection oraz znaczenie ochrony danych – także w kontekście haseł.

Co wykazała analiza firmy Irregular: schematy, duplikaty i niska entropia

Analiza przeprowadzona przez badaczy z Irregular ujawniła kilka powtarzających się zjawisk, które z punktu widzenia atakującego są wręcz zaproszeniem do optymalizacji ataków na hasła.

W jednej z serii testów model Claude został poproszony o wygenerowanie 50 haseł. Efekt? Tylko 30 z nich okazało się unikalnych. Dwudziestokrotne pojawienie się tych samych ciągów, w tym 18 razy identycznego hasła, pokazuje, że nawet przy wielu próbach system nie tworzy w pełni nowych kombinacji, lecz chętnie „wraca” do ulubionych wzorców.

Badacze zwrócili uwagę na charakterystyczne schematy. W przypadku Claude każde hasło rozpoczynało się literą, najczęściej dużym „G”, a drugim znakiem niemal zawsze była cyfra „7”. W efekcie powstawała bardzo zawężona grupa ciągów, w których wiele liter alfabetu nie występowało wcale. Podobne regularności ujawniono w innych modelach: ChatGPT często zaczynał hasła od litery „v”, a Gemini preferował „k” – w wersji małej lub wielkiej.

Co więcej, w zebranych próbkach nie pojawiały się sekwencje z powtarzającymi się znakami (np. „aa” czy „11”). Choć intuicyjnie może się wydawać, że unikanie powtórzeń jest zaletą, z perspektywy bezpieczeństwa jest to kolejny schemat, który ogranicza przestrzeń możliwych kombinacji. LLM dąży do „ładnych”, uśrednionych sekwencji, co skutkuje przewidywalnością.

Tę przewidywalność najlepiej wyjaśnia pojęcie entropii hasła. Entropia to miara losowości i nieprzewidywalności ciągu znaków. Im wyższa entropia, tym większa przestrzeń możliwych haseł i tym trudniej jest je zgadnąć, nawet przy użyciu dużej mocy obliczeniowej. Jeśli jednak w generowanych hasłach występują stałe schematy – powtarzalny pierwszy znak, ograniczony zestaw liter czy brak określonych kombinacji – realna entropia jest niższa, niż sugerowałaby sama długość hasła czy liczba typów znaków.

Z punktu widzenia atakującego takie schematy działają jak skrót. Zamiast przeszukiwać całe pole możliwych haseł o zadanej długości, można skupić się na stosunkowo niewielkiej podprzestrzeni „ulubionych” wzorców modelu. Badacze z Irregular podkreślają, że to właśnie przewidywalność jest głównym problemem haseł generowanych przez LLM – nie brak złożoności wizualnej.

Warto zauważyć, że badanie dotyczyło relatywnie krótkich haseł i konkretnych ustawień. Nie zmienia to jednak fundamentalnego wniosku: modele językowe są projektowane po to, aby tworzyć sekwencje „prawdopodobne”, a nie kryptograficznie losowe. Zwiększanie długości hasła generowanego przez AI może poprawić sytuację, ale nie usuwa źródłowego problemu, jakim jest ograniczona entropia wynikająca z natury modelu.

Jak działają modele językowe i dlaczego nie nadają się do generowania silnych haseł

Duże modele językowe, takie jak GPT, Claude czy Gemini, to zaawansowane systemy statystyczne. W uproszczeniu ich zadanie polega na przewidywaniu kolejnego znaku lub słowa na podstawie poprzedniego kontekstu. Wnętrze takiego modelu to miliardy parametrów, które kodują prawdopodobieństwa występowania określonych sekwencji znaków i słów w różnych kontekstach.

Kiedy prosimy model o „silne hasło z liter, cyfr i symboli”, otrzymujemy nie wynik rzutu wirtualną, perfekcyjnie losową kostką, lecz sekwencję, która jest – w sensie statystycznym – typowa dla przykładów, jakie model „widzi” jako pasujące do opisu „silne hasło”. To fundamentalna różnica wobec kryptograficznych generatorów liczb losowych, których jedynym zadaniem jest dostarczanie nieprzewidywalnych bitów.

Nawet parametry wpływające na różnorodność generowanych treści, takie jak „temperature” czy „top-p”, nie zmieniają tego faktu. Mogą one powodować większą zmienność odpowiedzi, ale nadal operują na rozkładzie prawdopodobieństwa ustalonym przez model. Z perspektywy bezpieczeństwa oznacza to, że wynik wciąż jest zdeterminowany przez preferencje modelu, a nie przez obiektywną losowość.

Ta właściwość może zostać skutecznie wykorzystana przez atakujących. Jeżeli wiadomo, że dany model faworyzuje określone litery na początku hasła, preferuje konkretną cyfrę na drugiej pozycji lub unika pewnych sekwencji, można drastycznie zawęzić obszar poszukiwań przy zgadywaniu haseł. Powstaje w ten sposób koncepcja ataku zorientowanego na model (model-aware password guessing). Podobne pytania o przewidywalne zachowania modeli, alignment i zarządzanie ryzykiem stawia również tekst „Superinteligencja bliżej, niż myślisz: co naprawdę wynika z zapowiedzi Sama Altmana”, który pokazuje, dlaczego kwestie bezpieczeństwa i odpowiedzialności są kluczowe przy powierzaniu modelom wrażliwych zadań, takich jak operowanie na hasłach.

W takim scenariuszu przestępcy budują generator kandydatów haseł, który naśladuje statystyczne preferencje znanego modelu AI. Zamiast testować wszystkie kombinacje liter, cyfr i symboli, generator tworzy przede wszystkim te sekwencje, które najczęściej wypluwa sam model. W efekcie liczba koniecznych prób do złamania realnie używanego hasła znacząco maleje.

Prosty przykład ilustruje skalę problemu. Załóżmy, że w próbce tysiąca haseł wygenerowanych przez konkretną wersję ChatGPT aż 60 procent rozpoczyna się od litery „v”. Atakujący, który dysponuje taką statystyką, najpierw wygeneruje i przetestuje wszystkie kombinacje z „v” na pierwszej pozycji, zamiast równomiernie rozkładać próby na cały alfabet. W skali setek tysięcy kont oznacza to ogromną oszczędność czasu i mocy obliczeniowej.

Warto zauważyć, że podobną logiką rządzą się generatywne algorytmy w wyszukiwarkach. W przewodniku „GEO zamiast SEO: praktyczny przewodnik po optymalizacji pod Google SGE i odpowiedzi generatywne” opisano, jak systemy generatywne Google budują odpowiedzi w oparciu o statystykę i prawdopodobieństwa, co zmienia sposób myślenia o widoczności w sieci. Ta sama zasada – przewidywalność wyników wynikająca z rozkładów prawdopodobieństwa – ma konsekwencje również w bezpieczeństwie, bo ułatwia modelowanie zachowania AI przez atakujących.

Dlaczego LLM-y mają problem z prawdziwą losowością: techniczne tło

Z perspektywy kryptografii kluczowe jest rozróżnienie między prawdziwą losowością a pseudolosowością. Prawdziwie losowe bity pochodzą z fizycznych źródeł entropii (szum termiczny, jitter zegara, sprzętowe generatory losowe) i są w praktyce nieprzewidywalne nawet przy pełnej znajomości algorytmu. LLM-y nie posiadają takiego źródła entropii – działają wyłącznie na deterministycznym rozkładzie prawdopodobieństwa, zapisanym w ich parametrach po treningu.

Podczas generowania model oblicza dla każdego kolejnego tokena wektor prawdopodobieństw („softmax”). Parametr temperature skaluje ten rozkład: niska temperatura „wyostrza” go, faworyzując najbardziej prawdopodobne tokeny (więcej powtórzeń, mniejsza różnorodność), wysoka go „spłaszcza”, dopuszczając rzadsze tokeny. Metody próbkowania, takie jak top-k czy top-p (nucleus sampling), dodatkowo ograniczają wybór do najbardziej prawdopodobnych kandydatów. Ostateczny wybór tokena jest wprawdzie pseudolosowy (korzysta z PRNG po stronie serwera), ale zawsze w obrębie rozkładu wymuszonego przez trening.

To właśnie trening jest drugim źródłem problemu. Modele są uczone na gigantycznych korpusach tekstu i kodu po to, by uśredniać wzorce i przewidywać „typowe” kontynuacje. Ich celem jest maksymalizacja trafności przewidywań, a nie maksymalizacja entropii wyjścia. W rezultacie preferują sekwencje „językowo sensowne” lub zgodne z tym, jak ludzie zwykle piszą hasła oznaczone jako „silne” – a więc zawierające łatwe do rozpoznania schematy (mieszanka liter, cyfr, kilku symboli, brak długich powtórzeń itp.).

Znaczenie ma też to, że generacja jest stanowa: raz wybrany token wpływa na rozkład dla kolejnych pozycji. Jeśli model „lubi” zaczynać od konkretnej litery i cyfry, cały dalszy ciąg będzie się rozwijał w przewidywalnym poddrzewie przestrzeni haseł. Podbicie temperatury nie rozwiązuje tego problemu – zwiększa chaos w obrębie tego samego, uprzednio zawężonego rozkładu, ale nie zamienia modelu w kryptograficzny generator liczb losowych.

Stąd ograniczenia prompt engineeringu. Możemy prosić o „absolutnie losowe”, „nieprzewidywalne” czy „kryptograficznie silne” hasła, ale model nie ma dostępu ani do hardware’owego RNG, ani do mechanizmu weryfikacji entropii. Zawsze pozostanie ograniczony do wzorców zakodowanych w wagach i do swojej funkcji celu: produkowania prawdopodobnych, spójnych sekwencji. Dlatego nawet najbardziej wyrafinowany prompt nie jest w stanie przekształcić LLM-a w narzędzie spełniające wymagania kryptografii.

Scenariusze ataków na hasła tworzone przez AI: od teorii do praktyki

Model-aware password guessing nie jest wyłącznie teoretyczną koncepcją. Dla zorganizowanych grup cyberprzestępczych, dysponujących znaczną mocą obliczeniową i umiejętnościami analitycznymi, to realistyczny, a przy tym opłacalny scenariusz ataku.

Proces może wyglądać następująco. W pierwszym etapie atakujący masowo zbierają próbki. Za pomocą zautomatyzowanych skryptów wysyłają do wybranego modelu AI setki tysięcy zapytań w stylu: „wygeneruj silne 10-znakowe hasło z literami, cyframi i symbolami”. Zmieniane są drobne elementy promptów, aby uniknąć prostych ograniczeń, ale sens polecenia pozostaje podobny. Celem jest zbudowanie dużej bazy haseł odzwierciedlającej typowe zachowanie modelu.

W kolejnym kroku przeprowadzana jest analiza statystyczna. Wyszukiwane są wzorce: dominujące pierwsze znaki, najczęściej występujące sekwencje, preferowane długości, brak określonych znaków czy charakterystyczne zależności między pozycjami w haśle. Ten etap przypomina analizę danych w klasycznej analityce biznesowej, z tą różnicą, że celem jest zoptymalizowanie procesu łamania zabezpieczeń.

Na tej podstawie powstaje „profil modelu” – opis jego preferencji w generowaniu haseł. Buduje się własny generator kandydatów, który faworyzuje najbardziej prawdopodobne kombinacje zgodne z tym profilem. W istocie jest to zewnętrzna „miniatura” danego LLM, skoncentrowana wyłącznie na jednym zadaniu: szybkim zgadywaniu haseł użytkowników, którzy korzystali z AI do ich tworzenia.

Dopiero wtedy rozpoczyna się właściwy atak – próby logowania lub brute force w serwisach, gdzie istnieje wysokie prawdopodobieństwo wykorzystania haseł generowanych przez AI. Może to być na przykład platforma, która prowadziła kampanię edukacyjną zachęcającą do „wygodnego generowania bezpiecznych haseł z pomocą asystenta AI”. Atakujący nie muszą od razu łamać wszystkich kont – wystarczy, że znacząco zwiększą skuteczność w porównaniu z klasycznym, ślepym brute force.

Ryzyko szczególnie rośnie, gdy organizacje nieświadomie centralizują schematy. Jeśli dział IT publikuje instrukcję typu: „prosimy użyć modelu X do wygenerowania silnego hasła i wkleić je do naszego systemu”, w całej firmie powstaje homogenny, przewidywalny profil haseł. Jedna analiza modelu X daje przestępcom punkt zaczepienia do ataku na dziesiątki lub setki kont w tej sameej organizacji.

Sytuację dodatkowo komplikuje szybki wzrost dostępnej mocy obliczeniowej. Te same układy GPU, które służą do trenowania i uruchamiania modeli AI, wykorzystywane są również do łamania haseł. Nowa generacja kart graficznych, omawiana m.in. w tekście „GeForce RTX 5090 Performance: AI Supercomputing Meets 4K Gaming”, pokazuje, jak blisko są dziś światy gamingu, superkomputerów AI i obliczeń kryptograficznych. Z perspektywy bezpieczeństwa oznacza to, że każde uproszczenie przestrzeni haseł – w tym przewidywalność wynikająca z użycia AI – bezpośrednio przekłada się na krótszy czas potrzebny do ich złamania.

W świetle tych zagrożeń kluczowe staje się pytanie, jak zbudować proces generowania i przechowywania haseł, który nie opiera się wyłącznie na modelach językowych, a jednocześnie pozostaje przyjazny dla użytkownika i wykonalny w realiach biznesowych.

Najczęstsze błędy użytkowników i firm przy korzystaniu z AI do haseł

Jednym z najpoważniejszych błędów jest ocenianie siły hasła wyłącznie po jego wyglądzie. Jeżeli ciąg zawiera wielkie i małe litery, cyfry oraz symbole, użytkownicy automatycznie zakładają, że jest bezpieczny. Hasło wygenerowane przez AI spełnia często wszystkie te kryteria, więc budzi zaufanie. Problem w tym, że atakującego nie interesuje wizualna „ładność”, lecz statystyczna przewidywalność. Dwa z pozoru równie skomplikowane ciągi mogą mieć zupełnie inną entropię.

Coraz częściej spotykanym zjawiskiem jest kopiowanie z internetu gotowych promptów typu „wygeneruj superbezpieczne, nie do złamania hasło”. Użytkownicy nie zastanawiają się, jaki model stoi po drugiej stronie, w jakiej konfiguracji został uruchomiony i jak ograniczony jest zakres losowości. Z perspektywy bezpieczeństwa takie podejście przypomina kopiowanie z forum „idealnego PIN-u do bankomatu”, bo ktoś napisał, że jest „nie do odgadnięcia”.

Inny groźny nawyk to generowanie jednego „ładnego” hasła w AI i używanie go w wielu serwisach. Łączenie przewidywalności modelu z ponownym wykorzystaniem tego samego hasła tworzy efekt domina. Wystarczy wyciek z jednego serwisu, aby przestępcy mogli spróbować tego samego hasła w kolejnych usługach: poczcie, chmurze, komunikatorach czy panelu administracyjnym.

Dla organizacji szczególnie niebezpieczne jest promowanie jednego, konkretnego modelu AI jako zalecanego generatora haseł. W ten sposób ryzyko skupia się na jednym profilu modelu. Jeżeli przestępcy zainwestują czas w dokładne poznanie jego zachowania, otrzymają „matrycę” dla całej firmy lub nawet sektora, jeżeli wiele organizacji powieli ten sam błąd. W tym kontekście warto znać szerszy krajobraz dostawców i modeli – opisany m.in. w artykule „Anthropic w Indiach: co oznacza nowe biuro Claude.ai w Bengaluru dla rynku AI” – bo decyzja o wyborze konkretnego narzędzia AI ma bezpośrednie przełożenie na profil ryzyka w organizacji.

Odrębnym, ale równie istotnym problemem jest przechowywanie haseł. Niezależnie od tego, czy hasło powstało w głowie użytkownika, w menedżerze czy w AI, zapisywanie go w czystym tekście – w notatniku, dokumencie współdzielonym, czacie służbowym czy e-mailu – dramatycznie obniża poziom bezpieczeństwa. Wystarczy incydent polegający na nieautoryzowanym dostępie do takiego zasobu, aby całe wysiłki włożone w złożoność hasła stały się bez znaczenia.

Wnioski z badania Irregular są jednoznaczne: problemu nie da się rozwiązać wyłącznie „lepszym promptem”. Ograniczenia wynikają z samej architektury modeli językowych. Bez względu na to, jak bardzo będziemy precyzować polecenia, LLM pozostanie narzędziem statystycznym, a nie kryptograficznym generatorem losowym.

Perspektywa organizacyjna jest równie ważna, jak techniczna. Polityki haseł, szkolenia z bezpieczeństwa, wymogi RODO i innych regulacji wymagają od działów IT i bezpieczeństwa nie tylko mówienia pracownikom, czego „nie wolno”, ale przede wszystkim wskazywania bezpiecznych alternatyw. Zakaz korzystania z AI do generowania haseł musi iść w parze z jasną instrukcją, jak robić to właściwie.

Practical Alternatives to AI for Password Generation

Skoro hasła generowane przez AI cierpią na opisane wyżej problemy z przewidywalnością i niską entropią, kluczowe jest zastąpienie ich narzędziami i metodami zaprojektowanymi z myślą o kryptografii, a nie statystyce językowej. Poniżej przedstawiamy praktyczne alternatywy, które można wdrożyć zarówno indywidualnie, jak i na poziomie organizacji.

1. Offline’owe menedżery haseł (np. KeePass, KeePassXC)

Offline’owe menedżery haseł przechowują zaszyfrowaną bazę lokalnie na urządzeniu użytkownika, bez synchronizacji przez chmurę. Przykłady to rodzina KeePass (KeePass, KeePassXC) czy Password Safe.

• Jak działają: bazują na kryptograficznie silnych generatorach liczb losowych, tworząc hasła o bardzo wysokiej entropii. Użytkownik zarządza jedną główną „kasetką” zabezpieczoną hasłem głównym i ewentualnie plikiem klucza.
• Zalety względem AI: losowość nie wynika z „prawdopodobnych” sekwencji językowych, ale z szumu kryptograficznego, więc nie występują powtarzalne wzorce jak w badaniu Irregular. Atakujący nie może zbudować „profilu modelu” i zoptymalizować zgadywania haseł, bo generator nie ma statystycznych preferencji typu ulubionych pierwszych liter.
• Zastosowanie w organizacjach: dobra podstawa do centralnych polityk haseł – dział IT może dystrybuować ustandaryzowane konfiguracje (długość, zakres znaków) i procedury tworzenia backupów bazy.

2. Chmurowe menedżery haseł z wbudowanym generatorem (np. 1Password, Bitwarden)

Rozwiązania takie jak 1Password, Bitwarden, Dashlane czy Enpass oferują synchronizację między urządzeniami i integrację z przeglądarkami oraz aplikacjami mobilnymi.

• Jak działają: każde konto ma zaszyfrowany sejf z danymi logowania, a wbudowany generator haseł wykorzystuje kryptograficzne RNG po stronie klienta. Użytkownik otrzymuje automatycznie generowane, długie, unikalne hasła dla każdej usługi.
• Zalety względem AI: brak „model-aware password guessing” – generator nie jest trenowany na danych tekstowych i nie posiada preferencji typu „częściej wybieram literę v na początku”. Każde hasło jest niezależne, co minimalizuje ryzyko powstania powtarzalnych schematów na poziomie całej organizacji.
• Korzyść praktyczna: łatwa dystrybucja w firmie (kontrola centralna, polityki zespołowe, audyty), możliwość wymuszania długości i złożoności haseł bez odwoływania się do AI.

3. Wbudowane w przeglądarki generatory haseł (Chrome, Edge, Firefox, Safari)

Nowoczesne przeglądarki (Chrome, Edge, Firefox, Safari) oferują własne menedżery haseł z funkcją podpowiadania i generowania silnych haseł podczas rejestracji kont.

• Jak działają: przeglądarka, korzystając z mechanizmów kryptograficznych systemu operacyjnego, tworzy losowe, złożone hasła i zapisuje je w swoim sejfie, często synchronizowanym przez konto Google, Apple czy Microsoft.
• Zalety względem AI: brak statystycznego „stylu” modelu – hasła powstają z użyciem generatorów liczb losowych wbudowanych w system (np. CryptGenRandom, /dev/urandom). To usuwa problem powtarzalnych prefiksów („G7…”, „v…”, „k…”) i zauważalnych luk w przestrzeni znaków.
• Gdzie się sprawdza: dla użytkowników indywidualnych i małych firm, które nie chcą wdrażać osobnego menedżera, ale potrzebują prostego, lepszego zamiennika dla haseł z AI i „zapisywania w przeglądarce bez generatora”.

4. Sprzętowe klucze bezpieczeństwa i logowanie bezhasłowe (FIDO2, WebAuthn)

Choć nie jest to klasyczna „metoda generowania hasła”, klucze sprzętowe (YubiKey, SoloKey, Feitian i inne) oraz mechanizmy WebAuthn/FIDO2 redukują rolę haseł jako głównego sekretu.

• Jak działają: zamiast tradycyjnego hasła użytkownik używa sprzętowego tokena, biometrii lub PIN-u lokalnego. Klucz generuje pary kryptograficzne przypisane do konkretnej domeny, co uniemożliwia ich ponowne wykorzystanie w innym serwisie.
• Zalety względem AI: całkowicie eliminuje problem przewidywalności sekwencji znaków, bo „hasło” przestaje być centralnym elementem bezpieczeństwa. Nawet jeśli użytkownik używa słabszego hasła pomocniczego, atakujący musi fizycznie wejść w posiadanie klucza sprzętowego.
• Zastosowanie organizacyjne: szczególnie polecane dla kont administracyjnych i dostępu do systemów krytycznych, gdzie ryzyko związane z hasłami – w tym z ich generowaniem w AI – jest największe.

5. Nielosowe, ale wysokiej entropii metody „zrób to sam” (diceware, frazy hasłowe)

Dla osób, które nie chcą lub nie mogą korzystać z menedżera, alternatywą są metody manualnego tworzenia silnych fraz hasłowych, takie jak diceware czy złożone passphrase’y oparte na wielu słowach.

• Jak działają: użytkownik losuje słowa z listy (np. przy pomocy kostek, stąd „diceware”) lub świadomie łączy kilka zupełnie niezwiązanych słów i znaków (np. „światło-krawat-7!lawina-beton”). Kluczowe jest użycie wystarczającej liczby słów i elementów, by zapewnić wysoką entropię.
• Zalety względem AI: losowość pochodzi z fizycznego procesu (rzuty kostką, prawdziwe wybieranie z listy), a nie z modelu językowego. Frazy nie są „uśrednione” według statystyki korpusów tekstowych, więc atakujący nie może wykorzystać tego typu badań jak raport Irregular do zawężenia przestrzeni poszukiwań.
• Gdzie ma sens: jako metoda tworzenia mocnego hasła głównego do menedżera haseł, które zapamiętuje użytkownik, podczas gdy reszta haseł jest generowana kryptograficznie.

6. Systemowe generatory kryptograficzne w narzędziach IT (OpenSSL, pwgen, narzędzia DevOps)

Administratorzy i zespoły DevOps mogą korzystać z narzędzi wbudowanych w systemy operacyjne i środowiska programistyczne: openssl rand, pwgen, funkcje SecureRandom w Javie, crypto.randomBytes() w Node.js czy równoważne mechanizmy w innych językach.

• Jak działają: wykorzystują źródła entropii systemu operacyjnego (ruch sieciowy, jitter zegara, zdarzenia sprzętowe), aby generować nieprzewidywalne bajty i na ich podstawie tworzyć hasła lub klucze.
• Zalety względem AI: brak „stylu” i powtarzalnych schematów wynikających z trenowania na danych tekstowych. Każde wygenerowane hasło jest niezależnym wynikiem pracy generatora kryptograficznego, co czyni atak zorientowany na model (jak w przypadku LLM) bezprzedmiotowym.
• Zastosowanie: tworzenie haseł serwisowych, kluczy API, sekretów w systemach CI/CD, gdzie szczególnie ważne jest wyeliminowanie jakichkolwiek regularności wykorzystywalnych przez atakujących.

Wdrożenie któregokolwiek z powyższych podejść – a najlepiej ich kombinacji (menedżer haseł + klucz sprzętowy + silne hasło główne typu diceware) – sprawia, że opisane wcześniej wektor ataku oparty na przewidywalności LLM przestaje mieć zastosowanie. Z perspektywy bezpieczeństwa kluczowe jest, aby źródłem losowości była kryptografia, a nie statystyczne preferencje modelu językowego.

Bezpieczna praktyka: jak łączyć AI z menedżerami haseł zamiast na niej polegać

Podstawowym narzędziem do bezpiecznego tworzenia i przechowywania haseł pozostają menedżery haseł – zarówno lokalne, jak i chmurowe. Ich siła polega na wykorzystaniu kryptograficznie silnych generatorów liczb losowych. Zwykle pozwalają one generować hasła o długości przekraczającej 16 znaków, bez uprzywilejowywania konkretnych liter czy cyfr. Entropia takiego hasła jest znacznie wyższa niż w przypadku sekwencji wygenerowanej przez AI, nawet jeśli wizualnie obie wyglądają podobnie.

Z tego powodu to menedżer haseł, a nie model językowy, powinien być domyślnym generatorem haseł zarówno dla użytkowników indywidualnych, jak i w organizacjach. AI może natomiast wspierać proces wokół haseł – tam, gdzie potrzebna jest elastyczność i umiejętność przetwarzania języka naturalnego, a nie kryptografia. Szczególnie ostrożnie należy podchodzić do autonomicznych agentów, takich jak opisywany w tekście „Auto-GPT: Revolutionizing AI with Autonomous Task Completion” Auto-GPT – ich zdolność do samodzielnego wykonywania zadań i dostępu do danych czyni je potencjalnie niebezpiecznymi, jeśli powierzylibyśmy im operowanie na hasłach czy kontach użytkowników.

Dla działów bezpieczeństwa i compliance AI może być wartościowym asystentem przy tworzeniu i uspójnianiu polityk haseł. Modele językowe dobrze radzą sobie z przekształcaniem technicznych wytycznych w zrozumiały język, przygotowywaniem wersji dokumentów dla różnych grup odbiorców czy proponowaniem przykładów dobrych i złych praktyk. Takie treści muszą oczywiście zostać zweryfikowane przez specjalistów, ale pozwalają znacząco przyspieszyć prace koncepcyjne.

AI sprawdza się również jako narzędzie edukacyjne. Może tłumaczyć użytkownikom, czym jest silne hasło, dlaczego nie wolno go ponownie używać, jak działają menedżery haseł czy na czym polega uwierzytelnianie wieloskładnikowe. Może też generować scenariusze szkoleń, quizy czy materiały komunikacyjne dostosowane do kultury organizacyjnej. Dobrym uzupełnieniem wiedzy o ryzykach korzystania z publicznych modeli do zadań takich jak generowanie haseł jest przegląd otwartoźródłowego chatbota HuggingChat w artykule „HuggingChat: The Open Source Alternative to ChatGPT”, który pokazuje, jak szerokie – i potencjalnie wrażliwe – mogą być zastosowania takich systemów.

Na poziomie operacyjnym modele językowe mogą pomagać w automatyzacji inwentaryzacji dostępu do systemów – na przykład poprzez generowanie checklist i procedur na podstawie istniejącej dokumentacji. Mogą również wspierać projektowanie doświadczenia użytkownika wokół logowania: proponować klarowne komunikaty błędów, przypomnienia o zmianie hasła czy teksty edukacyjne wyświetlane w interfejsie.

Dla użytkownika indywidualnego bezpieczny, a zarazem wygodny workflow może wyglądać następująco: zainstalowany menedżer haseł odpowiada za generowanie i przechowywanie unikalnych, długich haseł dla każdego serwisu. W ważnych kontach – jak e-mail, bankowość czy główne konto w menedżerze haseł – aktywowane jest dwuskładnikowe uwierzytelnianie (2FA). AI nie jest wykorzystywana do generowania samych haseł, ale może służyć np. do wyjaśniania kroków konfiguracji 2FA czy pomocy w zrozumieniu komunikatów bezpieczeństwa.

Administratorzy IT powinni z kolei wdrożyć rekomendacje procesowe: formalny zakaz używania AI do generowania haseł, audyt istniejących kont pod kątem potencjalnie słabych schematów, a także stopniowe promowanie logowania bezhasłowego (np. FIDO2, klucze sprzętowe, rozwiązania oparte na WebAuthn) tam, gdzie to możliwe. Wiele z tych wyzwań przypomina bieżącą debatę o roli AI w tworzeniu oprogramowania – opisywaną szczegółowo we wspomnianym już artykule „AI and PHP: Can the Old Guard of Web Development Survive the Automation Boom?”. Podobnie jak w developmentcie nie powinniśmy bezrefleksyjnie oddawać krytycznych zadań AI, tak w bezpieczeństwie hasła muszą pozostać domeną narzędzi zaprojektowanych specjalnie do tego celu.

Rekomendacje na przyszłość: jak budować politykę haseł w erze generatywnej AI

W nadchodzących latach rola AI w procesach bezpieczeństwa będzie rosła. Modele językowe już dziś wspierają analizę logów, korelację zdarzeń i wykrywanie anomalii, a wyspecjalizowane narzędzia oparte na AI będą coraz częściej pojawiać się w centrach operacji bezpieczeństwa (SOC). Nie zmienia to jednak podstawowego faktu: AI nie zastąpi kryptografii ani sprawdzonych praktyk w zakresie haseł.

Organizacje powinny wprost ująć w swoich politykach bezpieczeństwa zasady korzystania z AI w kontekście haseł. Warto jasno wskazać, że generowanie haseł w LLM jest niedopuszczalne w przypadku kont krytycznych (administracyjnych, finansowych, dostępów do systemów produkcyjnych), a w zastosowaniach mniej wrażliwych jest co najmniej odradzane. Jednocześnie należy zdefiniować, w jakich obszarach AI może być używana: edukacja, dokumentacja, analiza trendów, wsparcie procesów, ale nie generowanie samych tajnych danych.

Równolegle sensowne jest inwestowanie w alternatywy dla klasycznych haseł. Logowanie bezhasłowe, klucze sprzętowe, uwierzytelnianie biometryczne – przy odpowiednim poziomie ochrony danych biometrycznych – mogą znacząco ograniczyć powierzchnię ataku związaną z wykradaniem i łamaniem haseł. W praktyce wiele organizacji będzie przez lata funkcjonować w modelu hybrydowym, gdzie hasła współistnieją z nowszymi metodami, dlatego tym ważniejsze jest, aby same hasła były generowane i przechowywane we właściwy sposób.

W perspektywie kilku lat na rynku z pewnością pojawią się wyspecjalizowane narzędzia AI projektowane stricte pod bezpieczeństwo, w tym pod wsparcie zarządzania tożsamością i dostępem. Nawet one nie powinny jednak zastępować kryptograficznych generatorów haseł, lecz raczej je uzupełniać – na przykład poprzez analizę ryzyka, monitorowanie zachowań użytkowników czy wykrywanie nietypowych logowań.

Z praktycznego punktu widzenia warto już dziś wdrożyć zestaw prostych, ale skutecznych działań. Po pierwsze, przeprowadzić audyt obecnych polityk haseł i faktycznego sposobu, w jaki pracownicy tworzą i przechowują hasła. Po drugie, zweryfikować używane menedżery haseł – zarówno pod kątem bezpieczeństwa, jak i wygody. Po trzecie, zaktualizować szkolenia z bezpieczeństwa o wnioski z badań takich jak te przeprowadzone przez Irregular, podkreślając przewidywalność haseł z AI i wynikające z tego zagrożenia.

Warto również sprawdzić, czy oficjalne procedury, poradniki intranetowe lub materiały marketingowe nie promują mimowolnie generowania haseł przez AI, np. w ramach szerzej rozumianej „transformacji cyfrowej”. Zrozumienie działania systemów generatywnych, o którym pisaliśmy szerzej w przewodniku „GEO zamiast SEO: praktyczny przewodnik po optymalizacji pod Google SGE i odpowiedzi generatywne”, jest kluczowe nie tylko w marketingu czy SEO, ale również w bezpieczeństwie. Tylko wtedy, gdy rozumiemy, że modele językowe działają na statystyce i prawdopodobieństwie, możemy świadomie ocenić ich przydatność w poszczególnych zadaniach.

W ostatecznym rozrachunku przesłanie jest proste: AI to niezwykle użyteczne narzędzie, ale w obszarze haseł powinniśmy zaufać kryptografii, a nie statystycznym preferencjom modeli językowych. Silne, losowe hasła generowane przez menedżery, wsparte uwierzytelnianiem wieloskładnikowym i nowoczesnymi metodami logowania, pozostają fundamentem bezpieczeństwa w dobie generatywnej sztucznej inteligencji.

Zobacz również

• Alibaba AI kontra GPT-Image OpenAI: jak nowe narzędzia zmieniają pracę grafików, marketerów i twórców treści
• Superinteligencja bliżej, niż myślisz: co naprawdę wynika z zapowiedzi Sama Altmana
• Anthropic w Indiach: co oznacza nowe biuro Claude.ai w Bengaluru dla rynku AI
• Auto-GPT: Revolutionizing AI with Autonomous Task Completion
• HuggingChat: The Open Source Alternative to ChatGPT