W czerwcu 2026 trzy wydarzenia wznowiły debatę o realnych gwarancjach menedżerów «zero-knowledge»: badanie akademickie ETH Zurich i Aalto University mapuje 25 ataków możliwych do wykorzystania przy skompromitowanym serwerze, wyciek w LastPass przechodzi przez zewnętrzny CRM, a badacz z DEF CON 33 wykazuje przejęcie autofill poprzez clickjacking. Oto konkretny wpływ tych trzech wydarzeń na architekturę ARDNTECH, bez retoryki marketingowej.
Opublikowano 23 czerwca 2026 przez ARDNTECH EI · Analiza wewnętrzna na podstawie publicznych ujawnień
Kradzież tokenów OAuth w Klue (narzędzie do analizy sprzedażowej zintegrowane z Salesforce) umożliwiła dostęp do danych kontaktowych klientów LastPass. Zaszyfrowane sejfy nie zostały ujawnione. Realnym ryzykiem jest ukierunkowany phishing na podstawie listy kontaktów skradzionej u peryferyjnego podwykonawcy, a nie kompromitacja rdzenia kryptograficznego.
Wnioski : zero-knowledge chroni sejfy, a nie metadane przechowywane przez podmioty trzecie.
Matteo Scarlata i jego współautorzy (zrelacjonowani przez Ars Technica) mapują 25 ataków pokazujących, że gwarancje «zero-knowledge» Bitwarden, Dashlane i LastPass ulegają osłabieniu, jeśli serwer zostanie skompromitowany i aktywne są pewne opcjonalne funkcje: odzyskiwanie konta, udostępnianie poprzez dystrybucję kluczy publicznych, kompatybilność wsteczna kryptografii (downgrade KDF).
Wnioski : formalnie poprawny ZK musi odpierać scenariusz skompromitowanego serwera, a nie tylko uczciwego administratora.
Marek Tóth wykazuje, że autofill 11 menedżerów może zostać wyzwolony przez niewidoczny overlay. Wystarczy jedno kliknięcie na fałszywy baner cookies, aby wypełnić pola strony kontrolowanej przez atakującego. Narażoną powierzchnią jest logika wstrzykiwania DOM rozszerzenia, a nie sejf serwerowy.
Wnioski : rozszerzenie przeglądarki jest powierzchnią ataku odrębną od serwera, do utwardzenia niezależnie.
Badanie obiera za cel trzy rodziny funkcji, które przy skompromitowanym serwerze osłabiają gwarancje ZK. Oto ich odpowiedniki w architekturze ARDNTECH.
| Wektor z badania | Architektura ARDNTECH | Werdykt |
|---|---|---|
|
Odzyskiwanie konta
Kopia klucza sejfu przechowywana po stronie serwera, możliwa do użycia, jeśli serwer zostanie skompromitowany |
Wrap jest tworzony po stronie klienta (Argon2id) na podstawie kodu odzyskiwania, który posiada wyłącznie użytkownik. Serwer przechowuje nieprzejrzyste wrapy: nie może ponownie wyprowadzić klucza. Konsumpcja z natychmiastowym czyszczeniem. | Bezpieczny |
|
Downgrade kryptograficzny
Zmuszenie klienta do użycia słabszego algorytmu podczas wrapu odzyskiwania |
Zablokowany po stronie serwera: komponent inspekcyjny parsuje rzeczywistą armaturę (SKESK v6, S2K Argon2id, obecny AEAD, koszty progowe). Spreparowany klient dokonujący downgrade jest odrzucany i zmuszony do reaktywacji. | Zneutralizowany |
|
Podstawienie klucza publicznego przy udostępnianiu
Serwer podaje własny klucz zamiast klucza odbiorcy |
Serwer udostępnia klucz publiczny + odcisk odbiorcy. Poprawka z czerwca 2026 (repozytorium rozszerzeń) obejmuje weryfikację po stronie klienta. Punkt rezydualny: upewnienie się, że zmiana klucza znanego kontaktu wyzwala wyraźny alert. | W weryfikacji |
|
Klucze odzyskiwania administratora (typu LastPass)
Administrator grupy może ponownie zaszyfrować sejf użytkownika po stronie serwera |
ARDNTECH nie posiada mechanizmu «break-glass admin» po stronie serwera, który ponownie szyfrowałby klucz sejfu użytkownika do klucza administratora. Udostępnianie zespołowe przechodzi wyłącznie przez klucz publiczny zespołu i jego odcisk. | Bezpieczny z założenia |
Synteza : skompromitowany serwer ARDNTECH nie pozwala odszyfrować wrapów odzyskiwania: są one nieprzejrzyste, wyprowadzone po stronie klienta z sekretu, którego serwer nie posiada, a downgrade KDF jest odrzucany przy rejestracji. To dokładnie te scenariusze są wykorzystywane w innych menedżerach przez badanie ETH/Aalto. Są one tutaj zamknięte przez wybory architektoniczne udokumentowane w modelu zagrożeń.
Badania Tótha dotyczą logiki wstrzykiwania DOM rozszerzeń. To autofill i autologin są narażonymi powierzchniami. Sejf serwerowy nie jest tu winny: to rozszerzenie wypełniające pola może zostać oszukane. Poniższe punkty są obecnie audytowane w rozszerzeniu ARDNTECH.
visibility:hidden, rozmiar bliski zeru lub element zasłonięty (hit-testing punktu kliknięcia).window.top === window.self lub to samo pochodzenie.z-index, ponowna weryfikacja widoczności w momencie kliknięcia.Zdrowy rdzeń kryptograficzny może zostać obejściem przez peryferyjny stos SaaS. Sejfy LastPass nie drgnęły, ale lista kontaktów została skradziona u zewnętrznego integratora CRM.
Obecni podwykonawcy ARDNTECH (Scaleway, Brevo, Stancer, HIBP, Bugsink) są ujęci w rejestrze opublikowanym na stronie Zaufanie. Zero-knowledge chroni sejfy, a nie listę kontaktów w nieujętym zewnętrznym CRM.
Rotacja tokenów integracji zewnętrznych, minimalne zakresy, natychmiastowe odwołanie w razie incydentu. Dostępy do systemów peryferyjnych nie mogą pozwalać na odtworzenie mapy klientów.
Weryfikowalny zero-knowledge, hostowany we Francji, kod źródłowy AGPLv3. Prywatna beta jest dostępna po rejestracji.