Czy Bitwarden jest bezpieczny? Jak naprawdę działa sejf

Krótka odpowiedź

Tak, Bitwarden jest bezpieczny w tym sensie, który ma znaczenie: hasło główne nigdy nie opuszcza urządzenia, a każdy wpis w sejfie jest szyfrowany na komputerze lub telefonie, zanim trafi na serwer. Serwer, obojętnie czy należy do Bitwarden, czy stoi na własnym VPS, przechowuje wyłącznie szyfrogram. Bez hasła głównego ten szyfrogram jest bezużyteczny, także dla samego Bitwarden.

Ten model ma jednak wyraźne granice. Nie chroni przed słabym hasłem głównym, przed zainfekowaną przeglądarką ani przed phishingiem strony logowania. Nie ma też trybu awaryjnego: zapomniane hasło główne oznacza utracony sejf. Poniżej mechanizm jest rozłożony na części, a na końcu pada odpowiedź na pytanie, które zadaje sobie każdy, kto rozważa self-hosting: co własny serwer zmienia w tym rachunku, a czego nie.

Jak działa sejf Bitwarden: hasło główne nie opuszcza urządzenia

Bitwarden opiera się na architekturze zerowej wiedzy (ang. zero-knowledge). W praktyce znaczy to jedno: każdy klucz potrzebny do odszyfrowania sejfu powstaje z hasła głównego na urządzeniu użytkownika i tylko tam. Biała księga bezpieczeństwa Bitwarden (sprawdzona we wrześniu 2026) ujmuje to wprost: klucz główny jest "never stored on or transmitted to Bitwarden servers".

Proces wygląda tak. Klient (aplikacja, rozszerzenie przeglądarki, wersja webowa) bierze hasło główne oraz adres e-mail jako sól, po czym przepuszcza je przez funkcję wyprowadzania klucza, KDF (ang. key derivation function). Wynikiem jest 256-bitowy klucz główny (Master Key). Ten klucz jest następnie rozciągany funkcją HKDF do 512 bitów. Dopiero tym rozciągniętym kluczem odszyfrowywany jest właściwy klucz sejfu.

Klucz sejfu (User Symmetric Key) to losowe 512 bitów wygenerowane przy zakładaniu konta. Nigdy nie wynika z hasła. Jest tylko zaszyfrowany kluczem głównym i w tej zaszyfrowanej postaci (Protected Symmetric Key) leży na serwerze. Ten podział ma jedną praktyczną konsekwencję: zmiana hasła głównego nie wymaga ponownego szyfrowania każdego wpisu. Zmienia się tylko opakowanie klucza sejfu.

Do logowania serwer potrzebuje czegoś, co potwierdzi tożsamość, ale nie może dostać hasła. Klient wylicza więc osobny skrót uwierzytelniający: PBKDF2-SHA256 z kluczem głównym jako danymi wejściowymi i hasłem jako solą. Tylko ten skrót wędruje do serwera. Serwer haszuje go ponownie, z losową solą i 600 000 iteracji, i dopiero taki wynik zapisuje. Z tego skrótu nie da się odtworzyć ani hasła, ani klucza głównego.

Co to jest KDF i dlaczego liczba iteracji ma znaczenie

KDF to element, który zamienia hasło zapamiętane przez człowieka w klucz odporny na zgadywanie. Hasło z 12 znaków ma ograniczoną entropię. Atakujący, który zdobył zaszyfrowany sejf, może próbować miliony haseł na sekundę. KDF spowalnia każdą próbę, bo każde sprawdzenie wymaga powtórzenia całej, celowo kosztownej operacji.

Bitwarden oferuje dwa algorytmy. Domyślnym jest PBKDF2-SHA256, a domyślna liczba iteracji to 600 000. Według strony pomocy o algorytmach KDF (sprawdzonej we wrześniu 2026) od wydania 2026.2.1 jest to również wartość minimalna, zgodna z zaleceniami OWASP. Drugi algorytm to Argon2id z domyślnymi parametrami 32 MiB pamięci, 6 iteracji i 4 wątki równoległości. Argon2id jest odporniejszy na ataki z użyciem GPU i układów ASIC, ponieważ wymaga pamięci, a nie tylko mocy obliczeniowej.

Dwa ostrzeżenia z tej samej strony warto znać przed zmianą. Po pierwsze, wyższe iteracje wydłużają każde odblokowanie sejfu na każdym urządzeniu, także na starym telefonie. Bitwarden zaleca podnoszenie wartości o 100 000 i test na wszystkich urządzeniach. Po drugie, ustawienie Argon2id z pamięcią powyżej 64 MiB wywołuje ostrzeżenia przy autouzupełnianiu w iOS i przy tworzeniu Send, bo rozszerzenia systemowe iOS mają twardy limit pamięci. Parametry KDF zmienia się w aplikacji webowej, w ustawieniach bezpieczeństwa konta.

Czym jest szyfrowanie AES-256-CBC z HMAC-SHA256 po stronie klienta

Każdy element sejfu (login, notatka, karta, tożsamość, pole niestandardowe, załącznik) jest szyfrowany osobno, na urządzeniu, zanim opuści aplikację. Bitwarden używa do tego AES w trybie CBC (ang. cipher block chaining) z kluczem 256 bitów, a integralność zabezpiecza kodem HMAC-SHA256. Strona pomocy o używanym szyfrowaniu nazywa ten schemat "AES256-CBC-HMAC-SHA256".

HMAC jest tu równie ważny jak AES. Sam AES-CBC nie wykrywa manipulacji: zmieniony bajt szyfrogramu odszyfruje się w losowe śmieci bez żadnego błędu. HMAC (ang. hash-based message authentication code) liczony jest osobnym kluczem, drugą połową tych 512 bitów klucza sejfu. Klient najpierw sprawdza HMAC, a dopiero potem odszyfrowuje. Szyfrogram podmieniony na serwerze, przez atakującego albo przez uszkodzony dysk, zostaje odrzucony, zamiast po cichu zastąpić hasło innym.

Wymiana danych między użytkownikami w organizacji używa dodatkowo RSA z dopełnieniem OAEP: klucz organizacji jest szyfrowany kluczem publicznym każdego członka. Dla pojedynczego konta ten mechanizm nie ma znaczenia, ale dobrze wiedzieć, że udostępnianie też odbywa się bez odsłonięcia klucza serwerowi.

Przegląd kryptografii Bitwarden wykonany w 2025 roku przez Applied Cryptography Group na ETH Zurich zakładał, jak podaje strona audytów, "a fully malicious server". To właściwy model zagrożenia dla tego pytania: czy sejf pozostaje bezpieczny, gdy serwer jest w pełni wrogi. Odpowiedź w tym modelu brzmi tak, dopóki hasło główne jest mocne i urządzenie czyste.

Co serwer Bitwarden naprawdę przechowuje

Serwer przechowuje: adres e-mail, skrót uwierzytelniający (po ponownym haszowaniu), zaszyfrowany klucz sejfu, zaszyfrowane wpisy, parametry KDF w postaci jawnej oraz metadane potrzebne do działania usługi, jak znaczniki czasu modyfikacji i identyfikatory elementów. Parametry KDF muszą być jawne, bo klient musi je znać, zanim policzy klucz główny. Ich odsłonięcie nie osłabia ochrony: atakujący i tak musi wykonać całą pracę KDF dla każdej próby hasła.

Wniosek dla osoby porównującej chmurę z własnym serwerem jest prosty. Kopia bazy danych Bitwarden, obojętnie z którego serwera, jest listą zaszyfrowanych bloków. Jej wartość dla złodzieja równa się sile najsłabszego hasła głównego w tej bazie.

Przed czym ten model nie chroni

Słabe lub ponownie użyte hasło główne. Cała konstrukcja sprowadza się do jednego sekretu. KDF spowalnia zgadywanie, ale nie unieważnia go. Hasło główne użyte wcześniej w innym serwisie, który wyciekł, jest hasłem znanym. 600 000 iteracji PBKDF2 nic wtedy nie daje, bo atakujący próbuje jedno hasło, nie miliard. Hasło główne powinno być długie (cztery lub więcej losowych słów) i nigdzie indziej nieużywane.

Zainfekowane urządzenie lub przeglądarka. Biała księga mówi to otwarcie: jeśli urządzenie jest przejęte, "an attacker may be able to install malware such as a keylogger which would capture all information entered". Odblokowany sejf trzyma klucz w pamięci, bo inaczej nie mógłby niczego odszyfrować. Złośliwe rozszerzenie przeglądarki, keylogger lub zrzut pamięci procesu omijają całą kryptografię, bo działają po stronie jawnej. Szyfrowanie po stronie klienta zakłada, że klient jest uczciwy. Zablokowany sejf (Lock) usuwa klucze z pamięci; wylogowany (Log out) usuwa również lokalną kopię danych. Na współdzielonym komputerze ta różnica ma znaczenie.

Phishing strony logowania. Hasło główne nie opuszcza urządzenia, ale użytkownik może je wpisać na stronie, która tylko wygląda jak vault.bitwarden.eu. Rozszerzenie przeglądarki jest tu najlepszą obroną: autouzupełnianie działa wyłącznie na domenie zapisanej przy wpisie, więc brak podpowiedzi na rzekomej stronie logowania jest sygnałem alarmowym. Logowanie do samego Bitwarden warto dodatkowo zabezpieczyć kluczem FIDO2, którego phishing nie przechwyci, bo klucz podpisuje nazwę domeny, a nie tylko kod.

Utrata hasła głównego. Skoro Bitwarden nie zna hasła, nie może go zresetować. Ta sytuacja ma osobną sekcję niżej, bo jest najczęstszą przyczyną utraty sejfu w praktyce.

Utrata danych. Szyfrowanie nie chroni przed brakiem kopii zapasowej. Skasowane konto, zgubione hasło lub, w przypadku własnego serwera, dysk bez backupu kończą się tak samo. Przy self-hostingu ta odpowiedzialność przechodzi w całości na administratora, dlatego kopia zapasowa i odtwarzanie sejfu Vaultwarden to lektura obowiązkowa przed pierwszym prawdziwym hasłem w bazie.

Bezpieczeństwo logowania: 2FA i weryfikacja nowego urządzenia

Kryptografia sejfu i uwierzytelnienie na serwerze to dwie oddzielne warstwy. Logowanie dwuetapowe (2FA) chroni tę drugą: nawet jeśli atakujący zna hasło główne, bez drugiego składnika serwer nie wyda mu zaszyfrowanego sejfu. Nie chroni natomiast kopii sejfu, która już jest na urządzeniu, bo przy odblokowaniu 2FA nie jest sprawdzane.

Według strony pomocy o logowaniu dwuetapowym (sprawdzonej we wrześniu 2026) w planie darmowym dostępne są: aplikacja uwierzytelniająca (TOTP, na przykład Bitwarden Authenticator lub Aegis), poświadczenia FIDO2 WebAuthn (klucze sprzętowe jak YubiKey lub Google Titan, także passkeys) oraz kod wysyłany e-mailem. W planie Premium dochodzą YubiKey OTP i Duo. Pod względem odporności na phishing FIDO2 wygrywa wyraźnie, bo klucz podpisuje domenę. Kod e-mail jest najsłabszy, bo skrzynka pocztowa jest sama w sobie celem.

Przy włączeniu 2FA Bitwarden pokazuje kod odzyskiwania. Ten kod trzeba zapisać poza sejfem, na papierze lub w innym miejscu dostępnym bez Bitwarden. Strona pomocy mówi wprost: "If you lose both your recovery code and two-step device (...) you may be locked out of your vault". Kod odzyskiwania wyłącza wszystkie metody 2FA, ale nadal wymaga hasła głównego. Nie jest więc furtką dla kogoś, kto ma tylko kod.

Od 4 marca 2025 roku Bitwarden wymaga dodatkowo weryfikacji nowego urządzenia. Jeśli konto nie ma włączonego 2FA, logowanie z urządzenia, na którym nigdy wcześniej nie było sesji, wymaga jednorazowego kodu wysłanego na e-mail konta. To zabezpieczenie dla osób, które 2FA nie włączyły, i celowo ma wyjątki: użytkownicy z 2FA, logujący się przez SSO, używający klucza API oraz konta na serwerach self-hosted są z niego wyłączeni. Praktyczny wniosek: skrzynka e-mail przypisana do konta Bitwarden jest częścią jego bezpieczeństwa i sama powinna mieć 2FA.

Weryfikacja uruchamia się też po wyczyszczeniu ciasteczek przeglądarki i po ponownej instalacji aplikacji, bo z punktu widzenia serwera to nowe urządzenie. Nie jest to błąd.

Zapomniane hasło główne oznacza utracony sejf

Strona pomocy o zapomnianym haśle głównym formułuje to bez wyjątków: "Bitwarden has no way to access, retrieve, or reset your master password". To nie jest polityka, tylko konsekwencja architektury. Reset hasła przez serwer wymagałby, żeby serwer mógł odszyfrować klucz sejfu, a wtedy cały model zerowej wiedzy nie miałby sensu.

Drogi wyjścia istnieją, ale każdą trzeba przygotować wcześniej:

• Podpowiedź hasła (hint), wysyłana na e-mail, jeśli została ustawiona przy rejestracji. Podpowiedź to nie hasło; jeśli zdradza hasło, jest błędem.
• Dostęp awaryjny (Emergency Access, funkcja Premium): zaufana osoba może po okresie oczekiwania przejąć konto. Działa, bo klucz sejfu jest dla niej zaszyfrowany jej kluczem publicznym z wyprzedzeniem.
• Logowanie urządzeniem (Log in with device) lub passkey z obsługą szyfrowania, jeśli zostały skonfigurowane na urządzeniu, które nadal jest odblokowane.
• Odzyskiwanie konta przez administratora, tylko dla członków organizacji, która włączyła tę politykę.

Bez żadnej z tych opcji pozostaje, cytując tę samą stronę, "delete your account and create a new one". Wszystkie prywatne wpisy giną. Osoba, która ceni brak dostawcy z kluczem uniwersalnym, płaci za to własną odpowiedzialnością za hasło główne. Warto to powiedzieć wprost rodzinie lub zespołowi, zanim ktoś zapisze tam wszystko.

Audyty i certyfikaty: co udowadniają, a czego nie

Bitwarden publikuje listę zewnętrznych audytów na stronie pomocy o audytach (stan sprawdzony we wrześniu 2026). Najważniejsze pozycje:

• Cure53: audyty w latach 2018, 2021, 2022, 2023 (aplikacja webowa, desktop, rdzeń i biblioteki, rozszerzenie przeglądarki, sieć) oraz 2024 (aplikacje mobilne i SDK).
• IOActive, 2024: dedykowany audyt aplikacji klienckich i SDK.
• Mandiant, 2024: aplikacje mobilne i Bitwarden Authenticator.
• Unit 42 (Palo Alto Networks), 2025: aplikacje mobilne i Authenticator.
• Fracture Labs, 2024 i 2025: aplikacja webowa i bezpieczeństwo sieci.
• Applied Cryptography Group, ETH Zurich, 2025: przegląd rdzenia kryptograficznego w modelu w pełni złośliwego serwera.

Do tego certyfikaty: ISO 27001, SOC 2 Type 2 i SOC 3, zgodność z HIPAA oraz z RODO (GDPR), w tym standardowe klauzule umowne UE.

Co to udowadnia. Audyt kodu i test penetracyjny pokazują, że w badanym zakresie i w badanym momencie niezależny zespół nie znalazł błędów, których nie naprawiono. Certyfikat ISO 27001 czy raport SOC 2 mówią o procesach organizacji: kontroli dostępu, zarządzaniu incydentami, przeglądach. To ważne, gdy dane trzyma ktoś inny.

Czego nie udowadnia. Żaden audyt nie dowodzi braku błędów w kodzie napisanym po audycie, a klienci Bitwarden są aktualizowani regularnie. Certyfikat organizacji nie mówi nic o haśle głównym użytkownika ani o stanie jego laptopa. Przegląd z ETH Zurich potwierdza, że projekt jest poprawny przy założeniu wrogiego serwera; nie ocenia przeglądarki, w której ten projekt działa. Lista audytów jest argumentem za tym, że firma traktuje bezpieczeństwo poważnie. Nie jest gwarancją.

Region EU i RODO: co wybrać przy rejestracji

Bitwarden prowadzi dwa niezależne środowiska chmurowe: US z sejfem pod vault.bitwarden.com i EU pod vault.bitwarden.eu, z usługami identity.bitwarden.eu, api.bitwarden.eu i push.bitwarden.eu. Oba działają w Microsoft Azure, odpowiednio w USA i w Unii Europejskiej. Region wybiera się na ekranie rejestracji lub logowania z listy rozwijanej "Logging in on" (lub "Server"), w każdej aplikacji, także w rozszerzeniu i na telefonie.

Najważniejsze zdanie na stronie o regionach brzmi: "Bitwarden cannot migrate accounts from one region to another for customers". Konto założone w US zostaje w US. Przeniesienie polega na założeniu nowego konta w EU, eksporcie sejfu (najlepiej w zaszyfrowanym formacie JSON), imporcie i skasowaniu starego konta. Członek organizacji z innego regionu nie zobaczy tej organizacji wcale. Subskrypcję Bitwarden potrafi przenieść na prośbę, ale danych nie.

Dla czytelnika w Polsce wybór jest prosty: EU. Dane są wtedy przetwarzane i przechowywane w Unii, więc pytanie o transfer poza EOG w ogóle nie powstaje, a rejestr czynności przetwarzania w firmie zyskuje prostszy wpis. Region nie zmienia tego, że dostawca jest firmą amerykańską; dla większości firm w Polsce wystarczają wtedy standardowe klauzule umowne, które Bitwarden deklaruje na stronie zgodności. Kryptografia jest w obu regionach identyczna, bo klienci są te same. Różnica jest prawna i geograficzna, nie techniczna, a osoba prywatna nie traci na wyborze EU niczego.

Jeśli sejf ma kiedyś trafić na własny serwer, region ma mniejsze znaczenie, bo do własnej instancji i tak trzeba przenieść dane eksportem. Ale nawet wtedy warto, żeby konto chmurowe, które istnieje w międzyczasie, było w EU.

W kliencie CLI region ustawia i sprawdza to samo polecenie:

bw config server https://vault.bitwarden.eu
bw config server

Drugie wywołanie, bez argumentu, wypisuje aktualnie ustawiony adres. Konto założone w US nie zaloguje się przez api.bitwarden.eu, bo w tym środowisku po prostu nie istnieje.

Co zmienia self-hosting, a czego nie zmienia

Self-hosting nie zmienia kryptografii. Aplikacje, rozszerzenia i klienci mobilni są dokładnie te same, niezależnie od tego, czy adres serwera to vault.bitwarden.eu, czy własna domena. Hasło główne nadal nie opuszcza urządzenia, KDF liczy się lokalnie, wpisy są szyfrowane AES-256-CBC z HMAC-SHA256 przed wysłaniem. Serwer, także własny, widzi tylko szyfrogram. Dotyczy to zarówno oficjalnego serwera Bitwarden, jak i Vaultwarden, alternatywnej implementacji serwera zgodnej z tymi samymi klientami.

Self-hosting zmienia to, kto odpowiada za serwer. Ryzyka, które w chmurze pokrywa ISO 27001, SOC 2 i zespół Bitwarden, przechodzą na administratora: aktualizacje systemu i kontenera, TLS, kopie zapasowe, dostęp do panelu administracyjnego, logi, dostępność. Znika też weryfikacja nowego urządzenia, bo strona pomocy wyraźnie wyłącza z niej serwery self-hosted. 2FA i kod odzyskiwania działają tak samo, ale ich egzekwowanie zależy od konfiguracji własnej instancji.

Zyskiem jest kontrola. Baza sejfów nie leży na współdzielonej infrastrukturze, nie podlega obcej jurysdykcji, a jej lokalizacja to jedno konkretne miejsce, które można wskazać w rejestrze RODO. Kosztem jest fakt, że ten jeden VPS staje się celem i punktem awarii jednocześnie.

Osoba, która waha się między chmurą a własnym serwerem, powinna więc zadać sobie pytanie nie o kryptografię, bo ta jest identyczna, lecz o to, czy chce być administratorem. Porównanie obu opcji pod tym kątem znajduje się w zestawieniu Vaultwarden z oficjalnym self-hostowanym Bitwarden. Instrukcja uruchomienia własnej instancji na VPS jest w przewodniku Vaultwarden jako menedżer haseł na VPS. A wszystko, co dotyczy zabezpieczenia samego serwera, od panelu administracyjnego po TLS i firewall, opisuje analiza bezpieczeństwa Vaultwarden, która zaczyna dokładnie tam, gdzie kończy się pytanie o kryptografię.

FAQ

Czy Bitwarden widzi moje hasła?

Nie. Każdy wpis jest szyfrowany na urządzeniu kluczem, który wynika z hasła głównego, a hasło główne nigdy nie jest wysyłane na serwer. Do serwera trafia tylko skrót uwierzytelniający, wyliczony z klucza głównego, oraz zaszyfrowane dane. Bez hasła głównego Bitwarden, tak samo jak włamywacz z kopią bazy, ma tylko szyfrogram.

PBKDF2 czy Argon2id: co wybrać w ustawieniach KDF?

Oba są bezpieczne przy domyślnych parametrach (PBKDF2 600 000 iteracji lub Argon2id 32 MiB, 6 iteracji, 4 wątki, według strony pomocy Bitwarden ze września 2026). Argon2id lepiej opiera się atakom na GPU, bo wymaga pamięci. Przed zmianą sprawdź najstarsze urządzenie, na którym odblokowujesz sejf, bo wyższy koszt KDF wydłuża każde odblokowanie. Nie ustawiaj pamięci Argon2id powyżej 64 MiB, jeśli używasz autouzupełniania w iOS.

Co się stanie, jeśli zapomnę hasła głównego do Bitwarden?

Bitwarden nie może go zresetować, bo go nie zna. Pozostają metody przygotowane wcześniej: podpowiedź hasła, dostęp awaryjny (Premium), logowanie zaufanym urządzeniem, passkey albo odzyskiwanie konta przez administratora organizacji. Bez żadnej z nich jedynym wyjściem jest usunięcie konta i założenie nowego, ze stratą wszystkich prywatnych wpisów.

Czy wybrać region EU czy US przy rejestracji w Bitwarden?

Z Polski wybierz EU (vault.bitwarden.eu). Dane są wtedy przetwarzane w Unii Europejskiej, co upraszcza zgodność z RODO, a kryptografia i funkcje są takie same jak w US. Decyzja jest trwała: Bitwarden nie przenosi kont między regionami, a zmiana regionu oznacza nowe konto oraz ręczny eksport i import sejfu.

Czy self-hosting Bitwarden lub Vaultwarden jest bezpieczniejszy niż chmura?

Kryptografia jest identyczna, bo klienci są te same, więc sejf jest tak samo chroniony przed serwerem w obu wariantach. Różnica leży w tym, kto zabezpiecza serwer. W chmurze robi to Bitwarden, z audytami i certyfikatami na koncie. Na własnym VPS robi to administrator: aktualizacje, TLS, backupy i dostęp do panelu. Self-hosting jest bezpieczniejszy tylko wtedy, gdy ta praca jest naprawdę wykonywana.