Vaulted
5-minutowy audyt

Samodzielnie zweryfikuj szyfrowanie zero-knowledge Vaulted

Nie ufaj narzędziom bezpieczeństwa — weryfikuj je. Cztery testy w przeglądarce, bez instalacji, pięć minut.

60-sekundowa lista kontrolna

Najpierw przejrzyj to pobieżnie. Szczegółowy przewodnik poniżej omawia każdy krok dogłębnie.

  1. 1

    Otwórz DevTools → zakładka Network

    W Vaulted naciśnij Cmd+Option+I (macOS) lub F12 (Windows/Linux). Przejdź do zakładki Network i filtruj według Fetch/XHR.

  2. 2

    Utwórz sekret i sprawdź żądanie POST

    Wpisz rozpoznawalny ciąg canary (np. CANARY-12345) i kliknij Create. Znajdź żądanie POST /api/secrets. Otwórz zakładkę Payload — zobaczysz tylko ciphertext (base64) i iv. Wyszukaj w treści swój ciąg canary; nie ma go tam.

  3. 3

    Sprawdź link do udostępnienia

    Przyjrzyj się wygenerowanemu linkowi. Klucz deszyfrowania znajduje się za znakiem # (fragment URL). Zgodnie z RFC 3986 przeglądarki nigdy nie wysyłają fragmentów do serwera — ani w liniach żądań, ani w nagłówkach, ani w referrerach.

  4. 4

    Potwierdź, że deszyfrowanie odbywa się po stronie klienta

    Otwórz link w nowej karcie. Odpowiedź GET z /api/secrets/[id] zwraca tylko ciphertext. W panelu Sources wyszukaj crypto.subtle.decrypt — to wywołanie działa w Twojej przeglądarce, nie na naszym serwerze.

Otwórz Vaulted i zacznij →Przeczytaj model zagrożeń

Co weryfikujesz

Obietnica Vaulted jest konkretna: serwer nigdy nie widzi Twojego plaintextu ani Twojego klucza szyfrowania. Sprowadza się to do czterech obserwowalnych właściwości:

  1. Plaintext nie pojawia się w żadnym żądaniu sieciowym.
  2. Klucz szyfrowania nie pojawia się w żadnym żądaniu sieciowym.
  3. Fragment URL (gdzie przebywa klucz) nigdy nie dociera do serwera.
  4. Dane po stronie serwera samodzielnie nie pozwalają odtworzyć sekretu.

Jeśli wszystkie cztery właściwości zachodzą, architektura jest zero-knowledge z założenia — bez marketingowego żargonu.

Test 1 — Plaintext nigdy nie przechodzi przez sieć

  1. Otwórz vaulted.fyi.
  2. Otwórz DevTools i przejdź do zakładki Network. Filtruj według Fetch/XHR.
  3. Wpisz rozpoznawalny ciąg w pole sekretu — coś w rodzaju CANARY-12345.
  4. Kliknij Create.

Zobaczysz pojedyncze POST do /api/secrets. Kliknij je i zajrzyj do zakładki Payload.

Treść zawiera pole ciphertext i pole iv. Oba to zakodowane w base64url obiekty blob. Wyszukaj w payload CANARY-12345 — nie ma go tam. Plaintext został zaszyfrowany w przeglądarce przed wysłaniem żądania.

Jeśli chcesz być dokładny, ustaw ograniczenie sieci na „Slow 3G“ i powtórz test. Ciphertext nadal wygląda jak szum; plaintext nadal nigdzie nie widać.

Test 2 — Klucz też nigdy nie przechodzi przez sieć

Po utworzeniu sekretu Vaulted wyświetla Ci link do udostępnienia. Wygląda tak:

https://vaulted.fyi/s/abc123#dGhpcyBpcyBhIGtleQ
                              ^^^^^^^^^^^^^^^^^^^^
                              encryption key (base64url)

Część za # to fragment URL. Zgodnie z RFC 3986 przeglądarki przetwarzają fragmenty lokalnie — nigdy nie pojawiają się w liniach żądań HTTP, nagłówkach ani referrerach.

Aby to udowodnić:

  1. Skopiuj link do udostępnienia.
  2. Otwórz go w nowej karcie z otwartą zakładką Network w DevTools.
  3. Znajdź żądanie GET /s/abc123.
  4. Zajrzyj do zakładki Headers — pełny URL żądania, bez fragmentu.
  5. Zajrzyj do zakładki Request — bez fragmentu.
  6. Sprawdź document.referrer na następnej stronie — fragment usunięty.

Klucz potrzebny odbiorcy do odszyfrowania sekretu był w URL, ale pozostał w jego przeglądarce. Serwer zobaczył GET /s/abc123 i nic więcej.

Test 3 — Serwer sam nie może odszyfrować

Otwórz terminal i wywołaj sekret bezpośrednio przez curl:

curl https://vaulted.fyi/api/secrets/abc123

Otrzymasz z powrotem JSON zawierający ciphertext i iv. To cały stan Twojego sekretu po stronie serwera.

Teraz spróbuj to rozszyfrować. Bez klucza z fragmentu URL nie możesz. AES-256-GCM z prawidłowo wygenerowanym losowym kluczem jest dla wszelkich praktycznych celów nieodróżnialny od losowego szumu. Pełny zrzut bazy danych z serwerów Vaulted dałby dokładnie to — zaszyfrowane obiekty blob i metadane.

To dosłowna definicja zero-knowledge: serwer przechowuje dane, których nie może odczytać.

Test 4 — Szyfrowanie odbywa się w JavaScripcie, który możesz zobaczyć

Vaulted używa Web Crypto API, która jest prymitywem przeglądarki — nie ma tu zaciemnionego kodu WASM ani natywnego modułu ukrywającego działanie. Możesz obserwować, jak odbywa się szyfrowanie.

  1. W DevTools otwórz zakładkę Sources.
  2. Wyszukaj crypto.subtle.encrypt (użyj Cmd+Option+F do wyszukiwania globalnego).
  3. Ustaw breakpoint na linii wywołującej crypto.subtle.encrypt.
  4. Wywołaj tworzenie nowego sekretu.
  5. Breakpoint zatrzymuje wykonanie. Sprawdź argumenty: zobaczysz swój plaintext jako Uint8Array, klucz AES-GCM i świeży losowy IV.
  6. Przejdź dalej. Wynikiem jest ciphertext, który zostanie wysłany.

Teraz obserwujesz, jak plaintext staje się ciphertextem — w Twojej przeglądarce, przed jakimkolwiek żądaniem sieciowym. Dane nie mogą obrać żadnej innej drogi.

Co to dowodzi

  • Żaden plaintext nie opuszcza przeglądarki. Test 1.
  • Żaden klucz nie opuszcza przeglądarki. Test 2.
  • Serwer nie może odszyfrować tego, co przechowuje. Test 3.
  • Szyfrowanie jest prawdziwe i odbywa się po stronie klienta. Test 4.

To cała obietnica zero-knowledge, zademonstrowana na działającym systemie produkcyjnym w pięć minut.

Czego to nie dowodzi

Weryfikacja to rzetelna praca — warto uczciwie wskazać jej granice.

  • Testy dowodzą zachowania w tej chwili. Przyszła zmiana kodu może złamać tę właściwość. Jeśli potrzebujesz stałej pewności, zasubskrybuj changelog i regularnie powtarzaj testy.
  • Nie chronią przed Twoim własnym urządzeniem. Keylogger lub złośliwe rozszerzenie przeglądarki może odczytać plaintext po odszyfrowaniu. To leży poza kontrolą jakiejkolwiek aplikacji webowej.
  • Zakładają, że JavaScript, który uruchomiłeś, to JavaScript serwowany przez Vaulted. Ukierunkowany atakujący, który przejął CDN, mógłby serwować innemu bundle'u pojedynczemu użytkownikowi. Subresource Integrity i reprodukowalne buildy ograniczają to ryzyko; zob. nasz model zagrożeń w celu uzyskania szczegółowych informacji.

Idź dalej

Jeśli chcesz pogłębić wiedzę:

Najsilniejszym argumentem za narzędziem bezpieczeństwa nie jest jego marketing. To fakt, że możesz je rozłożyć na części i potwierdzić, że robi to, co twierdzi. Vaulted jest zbudowany tak, żebyś mógł to zrobić.

Często zadawane pytania

Masz pytania lub znalazłeś coś niepokojącego? Napisz do [email protected] — publikujemy naszą politykę odpowiedzialnego ujawniania i odpowiadamy w ciągu 48 godzin.
Udostępnij sekret →