Czy menedżery haseł są bezpieczne? Czego uczą wycieki, podatności i audyty

Dobrze wybrany i prawidłowo używany menedżer haseł pomaga zwiększyć bezpieczeństwo kont, ponieważ pozwala stosować inne, trudne do odgadnięcia hasło w każdej usłudze. Nie jest jednak odporny na każdy atak, a samo zapewnienie producenta o szyfrowaniu nie wystarcza, żeby ocenić, jak chroni nasze dane. Znaczenie mają również konstrukcja aplikacji, zabezpieczenia urządzeń, sposób udostępniania dostępów i reakcja dostawcy na odkryte problemy.

Obawy są zrozumiałe: skoro w jednym miejscu przechowujemy dostęp do poczty, bankowości, dokumentów i firmowych systemów, wiadomość o włamaniu do takiej usługi brzmi szczególnie niepokojąco. Tyle że pod określeniem „włamanie do menedżera haseł” mogą kryć się zupełnie różne zdarzenia — od kradzieży zaszyfrowanej kopii danych po błąd dotyczący określonej wersji dodatku do przeglądarki.

W mageek.it przeanalizowaliśmy dokumentację, raporty badaczy, komunikaty o incydentach i informacje o audytach w ramach badań do naszego rankingu menedżerów haseł. Z tej analizy wynika, że bezpieczeństwo najlepiej oceniać przez konkretne pytania: co napastnik mógł zdobyć, jakich warunków wymagał atak, kogo dotyczył problem i co producent zrobił po jego wykryciu? W tym artykule pokazujemy, jak czytać takie informacje bez specjalistycznej wiedzy.

Artykuł opiera się na analizie mageek.it według stanu na 13 października 2026 r., z weryfikacją przywołanych źródeł podczas przygotowania tekstu 14 października 2026 r. Opisy historycznych zdarzeń nie oznaczają, że wymienione podatności nadal występują w aktualnych wersjach produktów.

Czy warto używać menedżera haseł, skoro może zostać zaatakowany?

Warto rozważyć go przede wszystkim jako sposób na rozwiązanie codziennego problemu: człowiek nie jest w stanie zapamiętać dziesiątek długich, niezależnych haseł. W praktyce często używa więc jednego hasła w kilku miejscach, tworzy łatwe do przewidzenia warianty albo zapisuje dane logowania w przypadkowych dokumentach. Menedżer pozwala generować i przechowywać oddzielne hasła bez konieczności uczenia się ich na pamięć; takie zastosowanie rekomenduje również brytyjskie National Cyber Security Centre.

Wyobraźmy sobie właścicielkę małej firmy, która używa podobnego hasła do sklepu internetowego, służbowej poczty i programu do faktur. Jeśli dane logowania wyciekną z jednego serwisu, mogą zostać wykorzystane do prób przejęcia pozostałych kont. Oddzielne hasła ograniczają ten efekt, ponieważ znajomość jednego z nich nie daje od razu dostępu do reszty.

Skupienie danych w sejfie rzeczywiście sprawia, że staje się on szczególnie ważnym zasobem. Wymaga zatem mocnego zabezpieczenia i przemyślanego sposobu odzyskiwania dostępu. Oceniając ten wybór, trzeba jednak uwzględnić również ryzyko związane z dotychczasowym sposobem pracy: wspólnym hasłem zespołu, arkuszem wysyłanym pocztą czy kontami zapisanymi wyłącznie na komputerze jednej osoby.

Z naszych badań wynika praktyczny wniosek: wartość menedżera haseł zależy także od tego, jakie niebezpieczne nawyki uda się dzięki niemu wyeliminować. Nawet dobrze oceniona aplikacja niewiele zmieni, jeśli pracownicy nadal będą przesyłać hasła w wiadomościach, a wszyscy otrzymają dostęp do całego firmowego sejfu.

Wyciek danych a podatność menedżera haseł - jaka jest różnica?

Podatność oznacza słabość, którą w określonych warunkach można wykorzystać. Wyciek oznacza, że dane faktycznie opuściły kontrolę uprawnionych osób lub zostały ujawnione. Opublikowanie opisu podatności nie jest zatem dowodem, że przestępcy skorzystali z niej przeciwko użytkownikom.

W naszej analizie oddzielaliśmy zdarzenia dotyczące infrastruktury dostawcy, aplikacji na urządzeniu, rozszerzeń przeglądarki, aktualizacji i zewnętrznych partnerów. Dzięki temu problem ograniczony do jednego narzędzia nie stawał się automatycznie oceną wszystkich sposobów korzystania z produktu.

Informacja w komunikacie	Co może oznaczać dla użytkownika	Co trzeba ustalić
Skradziono zaszyfrowany sejf	Napastnik ma kopię danych, których odczyt zależy od skuteczności zabezpieczeń.	Czy zdobył również klucze, które pola były zaszyfrowane i jakie zalecenia dotyczą danego konta?
Znaleziono błąd w rozszerzeniu	Konkretna funkcja dodatku do przeglądarki może zachowywać się niebezpiecznie.	Które wersje są podatne, czego wymaga atak i czy aktualizacja usuwa problem?
Przejęto konto użytkownika	Nieuprawniona osoba uzyskała dostęp do określonego konta.	Czy przyczyną było wykradzione hasło, błąd usługi czy przejęte urządzenie?
Doszło do incydentu u partnera	Zagrożone mogą być np. dane kontaktowe lub system używany przez pracowników dostawcy.	Czy incydent objął sejfy, inne dane klientów, czy wyłącznie system pomocniczy?
Usługa jest niedostępna	Użytkownik może mieć problem z dostępem do danych lub ich synchronizacją.	Czy to awaria, jakie funkcje działają i czy istnieją dowody naruszenia poufności?

Te rozróżnienia mają bezpośredni wpływ na decyzję. W jednym przypadku wystarczy zainstalować poprawkę, w innym trzeba sprawdzić urządzenie, a po kradzieży kopii sejfu może być potrzebna zmiana zapisanych w nim haseł. Samo słowo „incydent” nie rozstrzyga, która reakcja będzie właściwa.

Jak badaliśmy bezpieczeństwo menedżerów haseł w mageek.it?

Podstawą naszej pracy był przegląd dostępnych dowodów, obejmujący historię incydentów i podatności, konstrukcję zabezpieczeń oraz sposób działania producentów. Zestawienie zawiera zdarzenia z lat 2017–2026, przy czym starsze przypadki uwzględnialiśmy wtedy, gdy pomagały zrozumieć historię produktu lub podejście dostawcy do bezpieczeństwa. Nie prowadziliśmy własnych prób włamania ani laboratoryjnych testów aplikacji.

W karcie oceny przyjęliśmy zasadę: „Punkt tylko ze źródłem.” Każde oceniane twierdzenie powinno mieć wskazane źródło i datę weryfikacji. Największe znaczenie miały oryginalne publikacje badaczy, raporty audytów, rejestry podatności oraz dokumenty instytucji. Korzystaliśmy także z dokumentacji i komunikatów producentów, zaznaczając, kiedy informacja jest ich deklaracją. Rzetelna prasa branżowa pełniła rolę pomocniczą, natomiast zestawienia afiliacyjne i anonimowe wypowiedzi nie stanowiły podstawy punktacji.

Drugą zasadą było oddzielenie zasięgu od skutków. Duża liczba osób korzystających z produktu nie oznacza, że wszystkie padły ofiarą danego ataku. Sprawdzaliśmy więc m.in. wersję aplikacji, wymagane ustawienia, rodzaj konta, konieczność wcześniejszego dostępu do komputera oraz to, czy opis dotyczy faktycznej kradzieży, czy możliwości wykazanej przez badaczy.

Osobno ocenialiśmy historię zdarzeń, reakcję producenta i audyty. W przypadku audytów liczyło się nie tylko istnienie raportu, ale również jego aktualność, regularność badań, zakres oraz udokumentowanie napraw. Przy reakcji na podatności uwzględnialiśmy czas od zgłoszenia problemu do poprawki, a nie wyłącznie czas od publikacji artykułu w mediach.

Ta metoda ma swoje granice. Brak opisanego incydentu w sprawdzonych źródłach nie dowodzi, że produkt jest odporny na wszystkie ataki. Nasze materiały nie pozwalają też obliczyć procentowego prawdopodobieństwa włamania do konkretnego menedżera. Pozwalają za to porównać jakość dostępnych dowodów i sprawdzić, czy szerokie zapewnienia producenta mają pokrycie w konkretnych badaniach.

Czy po wycieku z menedżera haseł przestępcy znają wszystkie hasła?

Kradzież zaszyfrowanego sejfu nie oznacza automatycznie odczytania jego zawartości, ale pozostaje poważnym zdarzeniem. Napastnik może zachować kopię i próbować ją odblokować poza systemami producenta, dlatego znaczenie mają zarówno konstrukcja szyfrowania, jak i zabezpieczenia konkretnego użytkownika.

Można porównać to do wyniesienia zamkniętego sejfu z biura. Złodziej nie musi od razu znać jego zawartości, ale ma czas na próby otwarcia. W świecie cyfrowym takie próby mogą polegać na sprawdzaniu kolejnych kandydatów na hasło główne, jeżeli to właśnie z niego wyprowadzany jest klucz do danych. O skuteczności ochrony decyduje wtedy nie tylko długość hasła, lecz także jego nieprzewidywalność oraz sposób, w jaki aplikacja utrudnia masowe zgadywanie.

Czego uczy wyciek LastPass z 2022 roku?

W komunikacie z grudnia 2022 r. LastPass potwierdził skopiowanie kopii zapasowej danych sejfów. Zawierała ona zaszyfrowane pola, takie jak hasła i nazwy użytkowników, oraz informacje niezaszyfrowane, m.in. adresy stron internetowych. Producent wskazał również możliwość prób odgadnięcia haseł głównych w celu odszyfrowania skradzionych kopii.

Przypadek ten pokazuje, dlaczego pytanie „czy dane były zaszyfrowane?” trzeba uzupełnić pytaniem „które dane?”. Sama lista usług używanych przez firmę może stanowić wartościową informację, nawet gdy hasła pozostają nieczytelne. Pomaga bowiem rozpoznać jej narzędzia i przygotować wiarygodniej wyglądającą wiadomość podszywającą się pod dostawcę.

Z analizy tego zdarzenia wyciągamy również wniosek dotyczący czasu: zabezpieczenia powinny chronić dane także wtedy, gdy napastnik zachowa ich kopię na dłużej. Usunięcie dostępu do infrastruktury producenta nie odbiera mu pliku, który zdążył wcześniej skopiować.

Czy zmiana hasła głównego zabezpiecza skradziony sejf?

Zmiana hasła głównego chroni aktualnie używany sejf zgodnie z mechanizmem danego produktu, ale nie zmienia kopii, która wcześniej trafiła do napastnika. Taka kopia nadal zawiera dane w postaci z chwili kradzieży.

Jeżeli ocena incydentu wskazuje ryzyko ich odczytania, potrzebna może być również zmiana haseł w usługach zapisanych w sejfie. Dopiero zastąpienie starego hasła do poczty nowym powoduje, że odczytane później stare hasło przestaje nadawać się do logowania. Samo przeniesienie tych samych danych do innego menedżera nie daje takiego efektu.

Nie oznacza to konieczności zmieniania wszystkich haseł po każdej wiadomości o podatności. Zakres działania powinien wynikać z tego, czy konkretne konto było objęte incydentem, jakie dane mogły zostać ujawnione i jakie zalecenia wydano dla tej sytuacji.

Czy uwierzytelnianie dwuskładnikowe chroni skradzioną kopię haseł?

Dodatkowe potwierdzenie logowania, na przykład kluczem sprzętowym albo kodem z aplikacji, utrudnia nieuprawniony dostęp do konta. Nie należy jednak zakładać, że sam fakt włączenia tej funkcji uniemożliwia odczyt skradzionego pliku z sejfem.

Jeżeli drugi składnik służy do zatwierdzania logowania na serwerze, napastnik próbujący odszyfrować już skopiowane dane nie przechodzi przez ten ekran. Zabezpieczenie konta i zabezpieczenie samej kopii danych są więc osobnymi zagadnieniami, a ich powiązanie zależy od konstrukcji produktu. Włączenie dodatkowej ochrony nadal ma sens, ale nie zastępuje mocnego hasła głównego ani dobrej architektury szyfrowania.

Czy incydent bezpieczeństwa dotyczy wszystkich użytkowników menedżera?

Zasięg trzeba sprawdzać w komunikacie, ponieważ nazwa produktu w nagłówku często mówi mniej niż informacja o dotkniętej funkcji, wersji lub grupie kont. W naszych materiałach widać to szczególnie wyraźnie na przykładzie zdarzeń dotyczących Dashlane, Bitwarden i 1Password.

W przypadku Dashlane atak rozpoczęty 31 maja 2026 r. dotyczył mechanizmu rejestracji nowych urządzeń. Według producenta napastnikom udało się pobrać zaszyfrowane sejfy mniej niż 20 użytkowników planów osobistych. Komunikat nie potwierdzał odczytania haseł ani naruszenia wewnętrznych systemów Dashlane; po zakończeniu dochodzenia dostawca informował o braku dodatkowego wpływu. To istotne zdarzenie, którego zakresu nie należy rozszerzać na wszystkich klientów ani na sejfy firmowe.

Innego rodzaju problem wystąpił 22 kwietnia 2026 r. w Bitwarden. Dotyczył złośliwej paczki konkretnej wersji narzędzia CLI, czyli programu obsługiwanego poleceniami, używanego m.in. do automatyzacji. W oficjalnym wyjaśnieniu przedstawiciel Bitwarden wskazał, że problem obejmował osoby, które pobrały i próbowały użyć wersji CLI 2026.4.0, a zwykli użytkownicy usługi nie byli nim objęci. Firma deklarowała również brak naruszenia danych sejfów. Oficjalne wyjaśnienie Bitwarden.

Z kolei w 2023 r. 1Password wykrył podejrzaną aktywność w używanym przez pracowników środowisku Okta, związaną z incydentem u tego zewnętrznego dostawcy. Według opublikowanego komunikatu dochodzenie nie wykazało dostępu do danych użytkowników 1Password. Sam fakt wystąpienia ataku w otoczeniu firmy nie był więc równoznaczny z kradzieżą sejfów jej klientów. Opis incydentu opublikowany przez 1Password.

Wniosek z tych przykładów jest praktyczny: ocenę komunikatu warto zacząć od ustalenia, czy używamy wskazanej funkcji i czy nasze konto należy do wymienionej grupy. Dopiero wtedy można dobrać działania do rzeczywistej sytuacji.

Co oznacza zero knowledge i czy gwarantuje bezpieczeństwo haseł?

Określenie zero knowledge jest używane przez dostawców menedżerów haseł do opisania konstrukcji, w której serwer przechowuje zaszyfrowane dane, a producent nie powinien móc odczytywać ich treści. W praktyce trzeba sprawdzić, jak ta obietnica została zrealizowana i czy obejmuje również sytuację, w której ktoś przejmie serwer oraz zacznie celowo zmieniać jego zachowanie.

Badacze z ETH Zurich i Università della Svizzera italiana przyjrzeli się właśnie takiemu scenariuszowi. W pełnej wersji publikacji „Zero Knowledge (About) Encryption” z 2026 r. opisali łącznie 31 ataków dotyczących Bitwarden, LastPass, Dashlane i 1Password. Przyjęli warunek pełnej kontroli napastnika nad serwerem; skutki poszczególnych ataków były różne. Nie była to lista 31 rzeczywistych włamań do kont klientów ani dowód, że wszyscy użytkownicy tych usług utracili hasła. Publikacja badawcza, pełna wersja z 12 sierpnia 2026 r.

Dla osoby wybierającej narzędzie płynie stąd ważna lekcja: warto pytać, jak sprawdzono zachowanie całego systemu, w tym udostępnianie danych i odzyskiwanie dostępu. Deklaracja o zastosowaniu mocnego szyfrowania opisuje tylko część zabezpieczeń, a nie wszystkie sposoby, w jakie aplikacja może otrzymać nieprawidłowe instrukcje lub dane.

Dlaczego podatności rozszerzeń przeglądarki są tak istotne?

Rozszerzenie działa tam, gdzie użytkownik loguje się do usług i korzysta z formularzy, dlatego jego zachowanie ma duże znaczenie dla bezpieczeństwa. Musi poprawnie rozpoznawać kontekst strony oraz odróżniać świadomą decyzję człowieka od działania, do którego ktoś próbuje go podstępnie skłonić.

W badaniu opublikowanym przez Marka Tótha opisano tzw. clickjacking w rozszerzeniach menedżerów haseł. W uproszczeniu chodzi o takie manipulowanie elementami strony i interfejsu, żeby kliknięcie użytkownika wywołało inne działanie, niż ten zamierzał. W określonych scenariuszach mogło to prowadzić do ujawnienia danych, przy czym możliwość wykorzystania błędu zależała od produktu, wersji i warunków ataku.

Ten przykład pomaga zrozumieć, że hasło może być zagrożone również w momencie używania, gdy aplikacja ma je wypełnić w formularzu. Zabezpieczenie przechowywanego pliku jest tylko jednym etapem ochrony, dlatego aktualność rozszerzenia i poprawki jego zachowania są równie realnymi sprawami jak wybór algorytmu szyfrowania.

W naszej analizie ocenialiśmy więc osobno aplikację i rozszerzenie, zamiast przypisywać całemu produktowi jedną etykietę na podstawie nazwy technologii. Historycznego opisu błędu nie należy przy tym traktować jako informacji o bieżącym stanie wszystkich wersji: status napraw trzeba odczytywać wraz z datą.

Czy niezależny audyt potwierdza, że menedżer haseł jest bezpieczny?

Audyt dostarcza dowodów na temat określonego zakresu produktu w określonym czasie. Jego wartość zależy od tego, kto przeprowadził badanie, co sprawdził, jakie problemy znalazł i czy zweryfikował ich usunięcie. Sama informacja „produkt przeszedł audyt” nie pozwala jeszcze odpowiedzieć na te pytania.

Można to porównać do kontroli budynku: raport dotyczący instalacji elektrycznej jest ważny, ale nie mówi wszystkiego o zamkach, konstrukcji dachu czy późniejszych przeróbkach. Podobnie badanie aplikacji mobilnej nie musi obejmować rozszerzenia przeglądarki, a kontrola procedur organizacyjnych dostawcy nie zastępuje analizy kodu odpowiedzialnego za szyfrowanie.

Przy czytaniu informacji o audycie warto sprawdzić pięć rzeczy:

1. Wykonawcę: czy wskazano niezależną firmę lub badaczy, których pracę można zidentyfikować?
2. Datę i wersję: kiedy przeprowadzono badanie i do której wersji produktu odnoszą się wyniki?
3. Zakres: czy sprawdzono aplikacje, serwer, rozszerzenia, sposób szyfrowania, czy tylko wybrane elementy?
4. Dostępność ustaleń: czy można przeczytać raport lub przynajmniej konkretne podsumowanie wyników?
5. Naprawy: czy wiadomo, co poprawiono i czy wykonano ponowne sprawdzenie, nazywane retestem?

Dlaczego informacja o poprawkach bywa ważniejsza niż hasło „audyt zaliczony”?

Dobrym przykładem jest opis audytu Proton Pass prowadzonego przez Recurity Labs od stycznia do kwietnia 2026 r. Producent udostępnił odnośnik do raportu i poinformował o poprawkach dotyczących sposobu przechowywania poufnych danych w pamięci aplikacji komputerowej. Według opublikowanego podsumowania ponowna kontrola potwierdziła usunięcie tych problemów. Podsumowanie audytu Proton Pass z odnośnikiem do raportu.

Z perspektywy naszej metodyki cenna jest możliwość prześledzenia całego procesu: znaleziono problem, wprowadzono zmianę i sprawdzono jej skuteczność. Raport zawierający ustalenia oraz udokumentowane naprawy może dostarczać więcej użytecznej wiedzy niż ogólna deklaracja, że zewnętrzni specjaliści „potwierdzili bezpieczeństwo”.

Czy certyfikat obejmuje każdą wersję programu?

Zakres certyfikatu trzeba przeczytać równie uważnie jak zakres audytu. Na przykład certyfikacja ANSSI CSPN opisana przez projekt KeePassXC dotyczy wersji 2.7.9 działającej w Windows 10. Nie należy automatycznie przenosić tego wyniku na każdą przyszłą wersję, inny system ani odrębne aplikacje o podobnej nazwie. Sam projekt zaznacza, że przeglądy bezpieczeństwa są powiązane z konkretnymi wersjami i platformami.

Nie jest to powód, żeby pozostawać przy starej wersji programu. Jest to wskazówka, jak uczciwie interpretować dowód: certyfikat ma określony zakres, a aktualizacje i kolejne badania pozostają potrzebne.

Czy menedżer z mniejszą liczbą podatności jest bezpieczniejszy?

Liczba opublikowanych błędów nie wystarcza do takiej oceny. Produkt intensywnie badany może mieć więcej publicznych zgłoszeń niż rozwiązanie, któremu poświęcono niewiele uwagi. Z kolei producent udostępniający raporty ujawnia również problemy, o których u mniej przejrzystego dostawcy moglibyśmy się nie dowiedzieć.

Nie oznacza to, że dużą liczbę poważnych błędów można zignorować. Trzeba sprawdzić ich znaczenie, powtarzalność i sposób naprawy. Inaczej ocenimy drobny problem wykryty podczas audytu i poprawiony przed publikacją, a inaczej wadę umożliwiającą przejęcie danych, którą pozostawiono bez skutecznego rozwiązania.

Z tego powodu w badaniach mageek.it osobno analizowaliśmy historię incydentów, sposób ujawniania problemów i udokumentowane naprawy. Otwartość kodu również traktowaliśmy jako możliwość weryfikacji, która nabiera wartości wtedy, gdy ktoś rzeczywiście korzysta z niej do badania produktu.

Większe zaufanie buduje producent, którego działania można sprawdzić. Powinien jasno wskazać, co wie, czego jeszcze nie ustalił, kogo dotyczy problem i jakie kroki są potrzebne. Aktualizacja komunikatu w miarę postępów dochodzenia jest naturalna; znaczenie ma to, czy kolejne informacje pozwalają użytkownikowi podejmować lepsze decyzje.

Jak bezpiecznie używać menedżera haseł w firmie?

Najważniejszy wniosek z naszej analizy dotyczy połączenia produktu ze sposobem pracy. Wybór narzędzia powinien iść w parze z ustaleniem, kto zarządza kontami, kto otrzymuje dostęp do poszczególnych danych i jak firma odzyska je w razie nieobecności odpowiedzialnej osoby.

Na co dzień oznacza to stosowanie mocnego, unikalnego hasła głównego tam, gdzie produkt go wymaga, włączenie dodatkowego potwierdzania logowania, aktualizowanie aplikacji oraz ograniczanie dostępu pracowników do potrzebnych im zasobów. Równie ważna jest procedura odebrania uprawnień po zakończeniu współpracy i bezpiecznie przygotowany sposób odzyskania dostępu. Powinien działać także wtedy, gdy osoba, która zakładała sejf, jest niedostępna.

W naszych badaniach uwzględnialiśmy ciągłość działania właśnie dlatego, że dla firmy utrata możliwości zalogowania się do poczty czy systemu sprzedaży również jest problemem bezpieczeństwa. Ochrona obejmuje zarówno poufność danych, jak i możliwość korzystania z nich przez właściwe osoby.

Jeżeli chcesz sprawdzić, jak wygląda to w Twojej organizacji, zacznij od ustalenia, gdzie znajdują się kluczowe dostępy i kto nad nimi panuje. W ramach Analizy Dostępów można uporządkować ten punkt wyjścia, a następnie dobrać narzędzie i zasady pracy do potrzeb firmy. Sam wybór aplikacji jest częścią tego procesu.

Najczęstsze pytania o bezpieczeństwo menedżerów haseł

Czy menedżer haseł może zostać zhakowany?

Tak, atak może dotyczyć infrastruktury producenta, konta użytkownika, aplikacji lub urządzenia. Skutki zależą od tego, co zostało przejęte i jakie zabezpieczenia pozostały skuteczne. Włamanie do systemu pomocniczego dostawcy nie oznacza automatycznie odczytania haseł klientów.

Czy darmowy menedżer haseł jest bezpieczny?

Cena nie rozstrzyga o bezpieczeństwie. Należy sprawdzić konstrukcję produktu, dostępne audyty, aktualizacje i historię reakcji na problemy. W zastosowaniach firmowych znaczenie mają dodatkowo funkcje zarządzania uprawnieniami i odzyskiwania dostępu, które mogą różnić się między planami.

Czy można zaufać menedżerowi, który miał wyciek?

Ocena zależy od rodzaju i skali zdarzenia, ujawnionych przyczyn, wprowadzonych zmian oraz możliwości sprawdzenia ich skuteczności. Poważny wyciek jest istotnym argumentem przy wyborze dostawcy, a sam upływ czasu nie stanowi dowodu, że problem rozwiązano.

Czy po wycieku wystarczy przenieść hasła do innego menedżera?

Przeniesienie danych zmienia miejsce ich przechowywania, ale nie unieważnia starej kopii ani zapisanych w niej haseł. Jeżeli mogły zostać ujawnione, trzeba ocenić potrzebę ich zmiany w poszczególnych usługach, a także odwołania innych zagrożonych dostępów.

Czy istnieje menedżer haseł ze stuprocentową gwarancją bezpieczeństwa?

Żaden audyt ani certyfikat nie daje takiej gwarancji dla wszystkich przyszłych wersji i sytuacji. Można natomiast wymagać konkretnych dowodów: niezależnych badań, jasno opisanego zakresu ochrony, udokumentowanych napraw i komunikacji, która pozwala odpowiednio zareagować na problem.