Hasła są najsłabszym ogniwem ochrony danych. To zdanie powtarzane jest w branży cyberbezpieczeństwa od dekady, lecz wnioski płynące z incydentów z ostatnich dwóch lat każą zadać pytanie, czy narzędzia stworzone, aby ten problem rozwiązać, przypadkiem nie tworzą nowych podatności?  

‍

Menedżery haseł — aplikacje przechowujące i automatycznie wypełniające dane logowania — stały się standardem zarówno w środowiskach korporacyjnych, jak i wśród użytkowników indywidualnych. Wyniki badań zaprezentowanych na konferencji DEF CON 33 w sierpniu 2025 roku oraz seria poprawek bezpieczeństwa wydanych przez czołowych producentów pokazują, że powinniśmy obdarzać je zaufaniem z dużą ostrożnością.

‍

Jak menedżer haseł chroni dane i czego nie widać gołym okiem?

‍

Podstawą bezpieczeństwa nowoczesnych menedżerów haseł jest architektura zerowej wiedzy (zero-knowledge architecture). Zasada ta polega na tym, że dostawca usługi buduje system tak, aby technicznie nie był w stanie zobaczyć niezaszyfrowanych danych użytkownika, nawet gdyby chciał. Szyfrowanie i odszyfrowywanie odbywa się wyłącznie na urządzeniu klienta, a hasło główne nigdy nie wędruje na serwer w formie czytelnej dla człowieka.

Renomowane rozwiązania takie jak Bitwarden, 1Password czy Proton Pass stosują standard szyfrowania AES-256 (Advanced Encryption Standard), uznawany przy obecnych możliwościach obliczeniowych za odporny na ataki metodą siłową (zapewne do czasu uzyskania przez przestępców szerszego dostępu do komputerów kwantowych).  

‍

Sam algorytm szyfrujący to jednak tylko połowa historii. Równie ważne jest to, w jaki sposób hasło główne wpisane przez użytkownika zamieniane jest na klucz kryptograficzny. Odpowiadają za to tak zwane funkcje wyprowadzania klucza – KDF (Key Derivation Functions) – i to właśnie w nich w ostatnich latach zaszły największe zmiany.

‍

Wyścig algorytmów, czyli dlaczego stara funkcja odchodzi w przeszłość?

‍

Przez ostatnie dwie dekady branżowym standardem była funkcja PBKDF2 (Password-Based Key Derivation Function 2), która utrudnia ataki przez wielokrotne, iteracyjne przekształcanie hasła. Problem polega na tym, że rozwój wyspecjalizowanych układów GPU (procesorów graficznych) i ASIC (układów scalonych projektowanych pod konkretne zadanie) sprawił, że koszt obliczeniowy takich ataków drastycznie spadł.  

‍

Współczesny sprzęt potrafi sprawdzać miliardy kombinacji na sekundę, co przy słabszych hasłach głównych czyni ataki offline realnym zagrożeniem nawet przy setkach tysięcy iteracji PBKDF2.

‍

Odpowiedzią branży na te zmiany jest masowe wdrażanie algorytmu Argon2id – zwycięzcy konkursu Password Hashing Competition zorganizowanego przez kryptografów akademickich. Argon2id wprowadza koncepcję pamięciochłonności (memory-hardness), co oznacza, że każda próba wygenerowania klucza wymaga nie tylko czasu procesora, ale też określonej ilości pamięci RAM.

To kluczowa różnica — układy GPU dysponują ograniczoną pamięcią per rdzeń, co znacząco zmniejsza liczbę prób, jakie napastnik może przeprowadzić równolegle. Według opublikowanych analiz porównawczych, Argon2id przy poprawnie dobranych parametrach oferuje o kilka rzędów wielkości wyższą odporność na ataki sprzętowe niż PBKDF2 przy porównywalnym czasie odblokowania sejfu dla użytkownika.

‍

W latach 2024–2025 Argon2id wdrożyły między innymi Bitwarden, Proton Pass i KeePassXC. 1Password utrzymuje PBKDF2 jako domyślny algorytm, kompensując to innym mechanizmem — o którym poniżej.

‍

Secret Key, czyli dodatkowy składnik, którego serwer nie zna

‍

Unikalnym rozwiązaniem w architekturze 1Password jest tak zwany Secret Key – 128-bitowy, losowo wygenerowany ciąg znaków przechowywany wyłącznie na urządzeniach użytkownika. Przy logowaniu na nowym urządzeniu Secret Key jest obowiązkowym elementem uwierzytelnienia. Oznacza to, że nawet w hipotetycznym scenariuszu kradzieży zaszyfrowanej bazy danych z serwerów 1Password i ujawnienia hasła głównego użytkownika, napastnik nie jest w stanie odszyfrować danych bez Secret Key, który nigdy nie opuścił urządzeń właściciela.  

‍

Entropia tego klucza (miara nieprzewidywalności i losowości ciągu znaków ) wykracza poza możliwości współczesnych superkomputerów. Jest to architektoniczne zabezpieczenie, które realna historia incydentów w chmurze (włącznie z głośnym naruszeniem bezpieczeństwa LastPass z 2022 roku) czyni szczególnie wartościowym.

‍

Clickjacking, czyli gdy jedno kliknięcie wystarczy do kradzieży danych

‍

W sierpniu 2025 roku badacz bezpieczeństwa Marek Tóth zaprezentował na konferencji DEF CON 33 nową klasę ataków na rozszerzenia przeglądarkowe menedżerów haseł.  

‍

Atak określany jako DOM-based extension clickjacking (przechwytywanie kliknięć w strukturze dokumentu strony) jest skierowany przeciwko popularnemu mechanizmowi automatycznego wypełniania (autofill). Jest to jedna z kluczowych funkcji zwiększających wygodę tych narzędzi.

‍

Mechanizm działania jest elegancki w swojej prostocie. Złośliwa strona internetowa nakłada niewidoczne warstwy HTML nad elementy interfejsu wstrzykiwane przez rozszerzenie do struktury dokumentu strony (DOM – Document Object Model, czyli hierarchiczna reprezentacja elementów strony widziana przez przeglądarkę).  

‍

Użytkownik odwiedzający taką witrynę widzi pozornie niegroźny element – np. baner zgody na pliki cookie, przycisk CAPTCHA, komunikat powitalny – i klika. W rzeczywistości to jedno kliknięcie trafia w ukryty przycisk zatwierdzający automatyczne wypełnienie formularza przez menedżera haseł. Dane logowania, kody jednorazowe TOTP (Time-based One-Time Password — kody generowane przez aplikacje uwierzytelniające) lub numery kart kredytowych lądują bezpośrednio w formularzu kontrolowanym przez napastnika.

‍

Badania Tótha objęły jedenaście najpopularniejszych menedżerów haseł. W domyślnych konfiguracjach niemal wszystkie były podatne na przynajmniej jedną technikę manipulacji interfejsem. W niektórych przypadkach kradzież pełnych danych logowania wymagała zaledwie jednego kliknięcia przez użytkownika, który nie miał żadnych powodów do podejrzeń. Podatność została zarejestrowana w bazie CERT/CC pod numerem VU#516608.

‍

Reakcje producentów od odpowiedzialności a przerzucaniem problemu

‍

Odkrycia Tótha wywołały debatę, która szybko wyszła poza techniczne fora i trafiła na platformy profesjonalne, w tym LinkedIn. Reakcje producentów były zróżnicowane.

‍

Dashlane, Proton Pass, Keeper i Bitwarden wydały poprawki między lipcem a sierpniem 2025 roku. Dashlane w wersji 6.2531.1 wdrożył blokowanie manipulacji oknami dialogowymi kluczy dostępu (passkeys — bezhasłowa metoda logowania omówiona w dalszej części tekstu). Proton Pass w wersji 1.31.6 wzmocnił ochronę przed nakładaniem elementów w strukturze strony. Bitwarden w wersji 2025.8.1 zmienił logikę generowania menu autofill.

‍

1Password sklasyfikował problem jako „informacyjny” i zamiast zmiany mechanizmu autofill zalecił użytkownikom włączenie opcji „Zapytaj przed wypełnieniem”. Firma argumentowała, że radykalna zmiana działania autofill mogłaby skłonić użytkowników do mniej bezpiecznych zachowań – jak kopiowanie haseł do systemowego schowka, który jest znacznie łatwiejszym celem dla złośliwego oprogramowania.  

‍

To argument, który ma merytoryczne podstawy, choć w obliczu dokumentów potwierdzających prostotę wykorzystania podatności autofill, kontrowersje wokół tej decyzji były nieuchronne. LastPass na moment publikacji raportu nie ogłosił planów pełnej naprawy technicznej.

‍

Niezależnie od oceny poszczególnych decyzji producentów, incydent ujawnił systemową słabość. Granica między „problemem przeglądarki” a „problemem rozszerzenia” jest w tym przypadku wystarczająco rozmyta, aby oba obozy mogły mieć rację i żaden nie musiał brać pełnej odpowiedzialności.

‍

Audyty i certyfikacje: papierowe gwarancje i rzeczywiste weryfikacje

‍

W branży cyberbezpieczeństwa deklaracje producentów mają mniejszą wagę niż niezależne audyty zewnętrzne. Analiza dostępnych raportów z lat 2024 – 2025 pokazuje, że czołowi gracze przykładają do tego obszaru coraz większą wagę, choć z różnym skutkiem.

‍

1Password poddaje swoje produkty regularnym testom penetracyjnym (próby włamania przeprowadzane przez specjalistów w kontrolowanych warunkach) przez firmy Cure53, Bishop Fox oraz Independent Security Evaluators. Wcześniejsze audyty ujawniały podatności takie jak logowanie haseł w tekście jawnym w komunikatach błędów systemu iOS i wszystkie zostały naprawione. Firma posiada certyfikacje ISO 27001, 27017, 27018 i 27701, potwierdzające zgodność procesów z międzynarodowymi standardami zarządzania bezpieczeństwem informacji.

‍

Bitwarden opiera swoją strategię na transparentności – kod źródłowy jest publicznie dostępny, co umożliwia ciągły audyt społeczności. Uzupełniają go formalne audyty Cure53 i Bishop Fox oraz certyfikacja SOC 2 Type 2 (niezależna weryfikacja, że kontrole bezpieczeństwa są konsekwentnie stosowane). Według raportu Bitwarden State of Password Security 2025, agencje rządowe CISA i NSA uznały to rozwiązanie za wzorcowe dla sektora publicznego.

‍

Proton Pass, mimo stosunkowo krótkiej historii, w lipcu 2025 roku pomyślnie przeszedł pierwszy audyt SOC 2 Type II przeprowadzony przez firmę Schellman, uzupełniając wcześniejszą certyfikację ISO 27001 i audyty kodu wykonane przez Cure53.

‍

Przełomowe znaczenie miało przyznanie w listopadzie 2025 roku certyfikatu bezpieczeństwa pierwszego stopnia (Visa de Sécurité CSP) projektu KeePassXC przez ANSSI – francuską agencję cyberbezpieczeństwa. Certyfikacja ta, honorowana również przez władze niemieckie, potwierdza, że implementacja kryptograficzna KeePassXC spełnia wymogi stawiane oprogramowaniu używanemu w administracji państwowej. Dla bezpłatnego narzędzia klasy open-source jest to wynik wyjątkowy.

‍

Klucze dostępu, czyli technologia, która niebawem zastąpi hasła

‍

Najważniejszą zmianą w architekturze bezpieczeństwa, która zdominowała ostatni rok, jest adopcja kluczy dostępu – passkeys – opartych na standardach FIDO2 i WebAuthn (Web Authentication — otwarty standard uwierzytelniania w przeglądarkach, opracowany przez konsorcjum W3C i sojusz FIDO Alliance).

‍

Passkeys zastępują współdzielone sekrety, czyli hasła, asymetryczną kryptografią klucza publicznego. Podczas rejestracji konta urządzenie użytkownika generuje unikalną parę kluczy: prywatny (pozostaje na urządzeniu lub w menedżerze haseł) i publiczny (trafia na serwer serwisu). Logowanie polega na tym, że serwer wysyła wyzwanie matematyczne, które może rozwiązać tylko właściciel klucza prywatnego, a potwierdzenie odbywa się przez biometrię (odcisk palca, rozpoznanie twarzy) lub PIN urządzenia, bez wpisywania hasła.

‍

Z perspektywy ryzyka operacyjnego passkeys eliminują dwa najgroźniejsze wektory ataków jednocześnie. Po pierwsze, są powiązane z konkretną domeną internetową, czyli nawet jeśli użytkownik zostanie przekierowany na fałszywą stronę, przeglądarka nie zaproponuje użycia klucza wygenerowanego dla prawdziwej domeny, co uniemożliwia phishing. Po drugie, serwer przechowuje jedynie klucze publiczne – bezużyteczne dla napastnika bez odpowiadających im kluczy prywatnych. Wyciek bazy danych serwisu nie daje dostępu do kont użytkowników.

‍

Wszystkie wiodące menedżery haseł w 2026 roku oferują pełną synchronizację passkeys między różnymi systemami operacyjnymi i urządzeniami, co rozwiązuje problem uzależnienia od infrastruktury jednego producenta, typowy dla natywnych rozwiązań Apple czy Google.

‍

Co dla organizacji i ich systemów oznacza wdrożenie menedżera haseł?

Menedżer haseł jest tylko tak bezpieczny, jak jego konfiguracja i otoczenie, w którym pracuje. Dla organizacji zarządzających dostępem pracowników lub obsługujących uwierzytelnianie klientów wynikają z tego konkretne priorytety.

‍

Po stronie zarządzania wewnętrznego kluczowe jest wymuszenie silnych haseł głównych w formie tzw. fraz hasłowych (passphrase) — zestawów czterech do siedmiu losowych słów, które są znacznie trudniejsze do złamania niż skomplikowane ciągi znaków, a łatwiejsze do zapamiętania.  

‍

Równie ważne jest bezwzględne wymaganie uwierzytelniania dwuskładnikowego (2FA — Two-Factor Authentication) dla kont menedżera haseł, najlepiej w formie sprzętowych kluczy bezpieczeństwa (np. YubiKey), a nie kodów SMS podatnych na atak SIM-swap (przejęcie numeru telefonu przez napastnika poprzez manipulację operatorem).  

‍

Aby zredukować ryzyko opisanego wyżej clickjackingu, warto wyłączyć automatyczne wypełnianie formularzy przy załadowaniu strony na rzecz interakcji inicjowanej ręcznie przez użytkownika.

‍

Po stronie systemów i serwisów internetowych priorytetem powinna być implementacja logowania bezhasłowego zgodnego z WebAuthn – standard FIDO2 eliminuje phishing, który nadal pozostaje głównym wektorem przejęcia kont.  

‍

W systemach, gdzie hasła są nadal wymagane, jedynym dopuszczalnym standardem jest Argon2id lub bcrypt do ich przechowywania po stronie serwera. Stosowanie przestarzałych algorytmów MD5, SHA-1 czy czystego SHA-256 jest uznawane przez środowisko za błąd w sztuce.  

‍

Uzupełnieniem powinna być integracja z bazami znanych wycieków, takimi jak API serwisu Have I Been Pwned, blokująca rejestrację haseł, które trafiły już do rąk napastników.

‍

Bezpieczeństwo jako ciągły proces

‍

Analiza stanu menedżerów haseł w latach 2024 – 2025 prowadzi do wniosku niewygodnego dla tych, którzy szukają prostych odpowiedzi – nie istnieje narzędzie, które raz wdrożone zapewnia trwałą ochronę. Podatność clickjacking, choć poważna, nie dyskwalifikuje menedżerów haseł – korzystanie z nich nadal jest wielokrotnie bezpieczniejsze niż powielanie haseł lub ich ręczne wymyślanie. Jednak jej odkrycie ujawnia, że granica ataku przesuwa się z infrastruktury (baz danych w chmurze) w stronę interfejsu użytkownika i codziennych zachowań.

‍

Przejście z PBKDF2 na Argon2id, architektura Secret Key w 1Password, certyfikacja KeePassXC przez ANSSI – są to sygnały, że sektor potrafi skutecznie wzmacniać kryptograficzne zabezpieczenia. Masowa adopcja passkeys zapowiada zaś erę, w której kradzież hasła rzeczywiście stanie się pojęciem historycznym.  

‍

Do tego momentu jednak, dla zarządzających ryzykiem organizacyjnym, kluczowym pytaniem pozostaje nie „czy używać menedżera haseł”, lecz „jak go skonfigurować i jakie procesy wokół niego zbudować?”.

‍

Aby zweryfikować, które z tych priorytetów dotyczą Twojej organizacji, przygotowaliśmy kartę samooceny – 12 pytań, które pokażą, czy i gdzie znajdują się luki. Karta będzie dostępna w pierwszej kolejności dla naszych subskrybentów w newsleterze.

‍

Źródła:

• Bitwarden, The State of Password Security 2025 Report
• CERT/CC, Vulnerability Note VU#516608 — Multiple Password Managers Vulnerable to Clickjacking Attacks
• Dashlane, Security Advisory: Passkey Dialog Clickjacking Issue (2025)
  Gupta D., The Complete Guide to Password Hashing: Argon2 vs Bcrypt vs Scrypt vs PBKDF2 (2026)
• Privacy Guides, KeePassXC Awarded ANSSI Security Visa (listopad 2025)
• Proton, SOC 2 Type II Audit Completion (lipiec 2025)
• SecurityWeek, Password Managers Vulnerable to Data Theft via Clickjacking (sierpień 2025)
• 1Password, Security Audits Documentation
• W3C / FIDO Alliance, Web Authentication (WebAuthn) Specification Level 3

‍