Bezpieczeństwo
Dowód, że Pańska przeglądarka nie jest sejfem.
Chrome i Firefox zapiszą Państwa hasła — a następnie przekażą je każdemu programowi działającemu na Państwa koncie. To nie jest błąd. To założenie projektowe. Oto dowód: raz w prostym języku, raz w kodzie.
Wersja w prostym języku
„Menedżer haseł" Państwa przeglądarki jest chroniony tylko jednym zamkiem: logowaniem do komputera. Gdy są Państwo zalogowani do laptopa, przeglądarka może natychmiast odczytać każde zapisane hasło — więc wszystko inne działające na Państwa koncie również może.
Złośliwe pobieranie. Podejrzana gra przeglądarkowa. Jedna zainfekowana paczka w projekcie, który Państwo sklonowali. W momencie uruchomienia — gdy są Państwo zalogowani, jak zawsze — odczytuje każde hasło zapisane przez Państwa przeglądarkę, w czasie potrzebnym na otwarcie pliku. Nie ma hasła głównego do złamania, ponieważ nie ma nic do złamania: przeglądarka została zaprojektowana tak, aby odblokowywać się automatycznie, a złośliwe oprogramowanie po prostu podszywa się pod Państwa.
To nie jest teoria. Jest to najczęstszy sposób, w jaki zwykli użytkownicy tracą swoje konta. Złośliwe oprogramowanie ma nawet nudną nazwę branżową — „info-stealers" — ponieważ jest to tak rutynowe. Hasła, zapisane karty, pliki cookie sesji: skopiowane i utracone, zanim Państwo się zorientują.
Rozwiązanie jest proste do sformułowania: hasła powinny być zablokowane czymś, czego reszta komputera nie posiada — i nie powinny w ogóle znajdować się na maszynie.
Wersja z dowodami
Nie trzeba nam wierzyć na słowo. Chromium i Firefox są otwartym oprogramowaniem, a ścieżka odczytu jest udokumentowana, standardowa i krótka. Oto dokładnie, gdzie znajdują się hasła i jak są pobierane.
Chrome (i każda przeglądarka Chromium)
Chrome przechowuje loginy w bazie danych SQLite — Login Data, tabela logins, kolumna password_value — zaszyfrowane za pomocą AES-256-GCM. Klucz AES znajduje się w Local State, „chroniony” przez system operacyjny: DPAPI w systemie Windows, Keychain logowania w systemie macOS, gnome-keyring/kwallet (lub zwykły tekst) w systemie Linux.
Można to sprawdzić samodzielnie — kod jest otwarty. Należy wyszukać w Chromium stałą, która oznacza opakowany klucz: kDPAPIKeyPrefix w os_crypt. Klucz jest opakowany przez DPAPI, oznaczony i przechowywany — a następnie rozpakowywany za pomocą jednego wywołania, które niczego przed Państwem nie chroni:
const char kDPAPIKeyPrefix[] = "DPAPI";
CryptUnprotectData(&intermediate, /*ppszDataDescr=*/nullptr,
/*pOptionalEntropy=*/nullptr, nullptr, nullptr, 0, &output);Brak drugiego sekretu, brak hasła, brak monitu. CryptUnprotectData zwraca klucz każdemu procesowi działającemu w danej sesji — co jest dokładnie modelem zagrożeń udokumentowanym przez DPAPI: jeśli działa na Państwa koncie, to jest Państwem. Cała praca atakującego sprowadza się do trzech kroków: odczytanie klucza z Local State, rozpakowanie go, odszyfrowanie AES-GCM każdego wiersza w Login Data. Złośliwe oprogramowanie typu info-stealer robi to od lat.
„Szyfrowanie na urządzeniu” również Cię nie ratuje
Odpowiedź Google to 6-cyfrowy PIN, który szyfruje zsynchronizowany sejf. W maju 2026 roku badacze z Phishu pokazali, jak cienka jest ta ochrona. Przekonujący fałszywy formularz logowania Google — phishing typu „adversary-in-the-middle" — przechwytuje sesję i ten PIN, a PIN jest kluczem głównym do każdego hasła i klucza dostępu w zsynchronizowanym koncie. Dzięki niemu atakujący dołącza własne urządzenie do „domeny bezpieczeństwa" Google, a cały sejf synchronizuje się bezpośrednio do niego — pełne przejęcie w jednym kroku.
Wada projektowa: Google pozwala na dołączenie urządzenia na podstawie samego 6-cyfrowego PIN-u, bez zatwierdzenia przez urządzenie, które już Państwo posiadają.
Firefox
Firefox przechowuje loginy w logins.json, a klucz w key4.db, odszyfrowywany przez „Secret Decoder Ring" NSS — również otwarte oprogramowanie: security/nss/lib/pk11wrap/pk11sdr.c. Jeśli ustawią Państwo Hasło główne, klucz jest nim zabezpieczony.
Domyślnie nie jest ono ustawione — klucz jest więc zabezpieczony pustym ciągiem znaków, a zapisana wartość „password-check" potwierdza, że puste hasło go odszyfrowuje. Wystarczy skopiować dwa pliki z profilu (key4.db + logins.json), wskazać na nie NSS lub otwarte oprogramowanie firepwd.py, a zostaną odszyfrowane. Zamek, którego klucz jest przyklejony do drzwi, nie jest zamkiem.
Każdy magazyn haseł przeglądarki ma ten sam kształt: sekret znajduje się tam, gdzie Państwo pracują, odblokowany przez sesję, w której są Państwo zalogowani. Szyfrowanie, które reszta komputera może cofnąć, nie chroni przed zagrożeniem, które faktycznie opróżnia konta — kodem działającym na Państwa koncie.
Dlaczego Clavitor nie może być odczytany w ten sposób
Clavitor nie przechowuje sejfu na maszynie. Nie ma Login Data, key4.db, ani klucza w Local State — nic na dysku, co proces działający na Państwa koncie mógłby zeskrobać.
Klucz odszyfrowujący nie jest zabezpieczony logowaniem do systemu operacyjnego. Jest on pochodną sprzętowego dotyku — Touch ID, Face ID lub YubiKey — obliczany w przeglądarce, używany do pojedynczego żądania, a następnie odrzucany. Poświadczenie jest pobierane przez ograniczone API dokładnie wtedy, gdy Państwo o nie poproszą, i nigdy nie jest buforowane. Złośliwe oprogramowanie działające na Państwa koncie znajduje pustą szafę.
To jest różnica między „zaszyfrowanym na Państwa urządzeniu" a „w ogóle nie na Państwa urządzeniu".
Przestańcie ufać przeglądarce w kwestii haseł.
Rozszerzenie Clavitor wypełnia dane tak jak przeglądarka — i przechowuje sejf w miejscu, którego laptop nie może odczytać.