OneTimeSecret vs PrivateNote: dlaczego miejsce szyfrowania ma znaczenie

Dwa sposoby zbudowania tego samego linku

Przy szyfrowaniu po stronie serwera nadawca przekazuje sekret usłudze przez TLS. Usługa otrzymuje tekst jawny, szyfruje go i zapisuje szyfrogram. Może wtedy przechowywać ładunek, dostarczyć go, wygasić i usunąć. Serwer aplikacji jest częścią procesu szyfrowania, bo tekst jawny wchodzi do usługi, zanim stanie się szyfrogramem.

Przy szyfrowaniu po stronie klienta urządzenie nadawcy szyfruje najpierw. Usługa otrzymuje i przechowuje szyfrogram. To wysłanie podróżuje przez TLS. Usługa nie otrzymuje klucza potrzebnego do odszyfrowania standardowego ładunku. Urządzenie odbiorcy odszyfrowuje lokalnie. Usługa nadal może przechowywać, dostarczać, wygaszać i usuwać ładunek bez dostępu do jego tekstu jawnego.

Oba projekty mogą dawać tymczasowe linki, ograniczony dostęp i wygaśnięcie. Oba można uczciwie nazwać szyfrowanymi. OneTimeSecret używa pierwszej architektury; PrivateNote drugiej. Właściwe pytanie nie brzmi więc po prostu, czy jednorazowy link jest zaszyfrowany, lecz które systemy muszą mieć dostęp do tekstu jawnego, aby ten link działał.

OneTimeSecret: szyfrowanie po stronie serwera

W zwykłym przebiegu OneTimeSecret nadawca przekazuje sekret przez TLS. Aplikacja otrzymuje tekst jawny, szyfruje go na serwerze i zapisuje zaszyfrowany ładunek.

Daje to realną ochronę danych zapisanych. Samo uzyskanie zaszyfrowanego magazynu nie musi ujawniać jego treści, gdy materiał potrzebny do odszyfrowania jest dla atakującego niedostępny.

Kompromis architektoniczny pojawia się przed zapisem. TLS chroni sekret w drodze między przeglądarką a OneTimeSecret, ale aplikacja musi przetworzyć tekst jawny, aby go zaszyfrować. Serwer aplikacji siedzi więc wewnątrz kryptograficznej granicy zaufania.

Złośliwy albo przejęty proces aplikacji w tym momencie mógłby uzyskać dostęp do sekretu, zanim zostanie on zaszyfrowany do zapisu. Szyfrowanie po stronie klienta usuwa tę konkretną zależność, szyfrując sekret, zanim dotrze on do usługi.

Fraza hasła OneTimeSecret nie zmienia granicy szyfrowania

Dokumentacja OneTimeSecret opisuje opcjonalną frazę hasła. Gdy fraza hasła jest użyta, OneTimeSecret podaje, że sekret jest szyfrowany na jego serwerach przy użyciu frazy hasła podanej przez nadawcę. Podaje, że samej frazy hasła nie zapisuje; zamiast tego zachowuje skrót bcrypt służący do weryfikacji frazy hasła przy odczycie. Według dokumentacji ten skrót sam nie może odszyfrować sekretu, a zapisany sekret chroniony frazą hasła nie może zostać odszyfrowany bez oryginalnej frazy hasła.

Odczyt używa tej samej granicy po stronie serwera. Odbiorca przekazuje frazę hasła do OneTimeSecret przez TLS. Usługa ją weryfikuje i wykonuje odszyfrowanie na serwerze, zanim zwróci tekst jawny.

Oznacza to, że proces aplikacji ma dostęp do sekretu i frazy hasła w chwili szyfrowania, a przy odczycie ponownie przetwarza frazę hasła i powstały tekst jawny. Złośliwy albo przejęty proces aplikacji działający w którymkolwiek z tych punktów mógłby potencjalnie przechwycić te informacje. To konsekwencja tego, gdzie wykonywane jest szyfrowanie i odszyfrowanie, a nie twierdzenie, że OneTimeSecret zapisuje te wartości albo ich nadużywa.

Publiczna dokumentacja OneTimeSecret sama z siebie nie ustala każdego szczegółu wewnętrznej hierarchii kluczy — na przykład tego, jak dokładnie łączy się materiał klucza po stronie serwera, klucze poszczególnych sekretów, wyprowadzanie klucza i podaną frazę hasła. Na potrzeby tego porównania nie trzeba spekulować o tych szczegółach implementacji. Istotną udokumentowaną właściwością jest to, że szyfrowanie i odszyfrowanie odbywają się po stronie usługi.

Własny hosting może uczynić zaufanie do tego serwera rozsądnym

OneTimeSecret jest open source. Organizacja może uruchomić własną instancję wewnątrz firmowego obwodu bezpieczeństwa, zamiast wysyłać sekrety do usługi publicznej.

W takim wdrożeniu zaufanie do serwera aplikacji jest zaufaniem do infrastruktury, którą organizacja już prowadzi. Tekst jawny nadal dociera do tego serwera, bo szyfrowanie nadal odbywa się tam. Po drugiej stronie granicy są własne hosty organizacji, operatorzy i kopie zapasowe. Dla zespołu, który już akceptuje te systemy jako część drogi sekretu, szyfrowanie po stronie serwera może być rozsądnym wyborem. Zwęża lukę między modelem zagrożeń po stronie serwera a modelem po stronie klienta, bo operator nie jest już usługą zewnętrzną.

PrivateNote szyfruje przed wysłaniem

Standardowa notatka PrivateNote jest szyfrowana przed wysłaniem. Przeglądarka nadawcy albo lokalny proces CLI, rozszerzenia Chrome, rozszerzenia edytora lub MCP generuje losowy klucz i szyfruje ładunek algorytmem AES-256-GCM. Wysyłany jest tylko szyfrogram. TLS niesie ten szyfrogram z przeglądarki do workera Cloudflare PrivateNote. Klucz odszyfrowania trafia do fragmentu URL, części po #, na przykład https://privatenote.ai/note/abc123#…. Fragment jest obsługiwany po stronie klienta i nie wchodzi do żądania HTTPS (RFC 3986, §3.5; standard URL). Worker otrzymuje identyfikator notatki i zwraca szyfrogram tym samym połączeniem TLS. Przeglądarka zatrzymuje fragment i odszyfrowuje lokalnie.

Fraza hasła chroni klucz, jeśli kanał linku zostanie przejęty

Fraza hasła w PrivateNote pełni inną rolę niż fraza hasła w OneTimeSecret. Notatka jest już szyfrogramem, zanim opuści urządzenie. Jeśli dodadzą Państwo frazę hasła, przeglądarka wyprowadza z niej klucz owijający za pomocą Argon2id i tym kluczem owijającym szyfruje klucz notatki. Fragment URL trzyma wtedy owinięty klucz. Odbiorca potrzebuje linku i frazy hasła. Przeglądarka rozwija klucz lokalnie i dopiero wtedy odszyfrowuje notatkę.

PrivateNote nie otrzymuje frazy hasła. Żądanie utworzenia niesie szyfrogram, sól i parametry, których przeglądarka odbiorcy potrzebuje, aby wypróbować frazę hasła lokalnie. Nie ma skrótu po stronie serwera, którego zadaniem byłaby weryfikacja frazy hasła. Błędna fraza hasła powoduje niepowodzenie odszyfrowania na urządzeniu.

Fraza hasła dodatkowo chroni klucz po stronie klienta lokalnie, jeśli kanał niosący link zostanie przejęty. Ten kanał widzi wtedy owinięty klucz, a nie klucz, który sam otwiera notatkę. To nie jest mechanizm, który trzyma PrivateNote poza ścieżką tekstu jawnego. To oddzielenie jest już obecne przy standardowej notatce, z frazą hasła albo bez niej. Frazę hasła należy udostępnić innym kanałem niż link. Ta sama wiadomość składa obie warstwy w jedną — ta sama zasada co przy bezpiecznym udostępnianiu hasła.

Obsługę kluczy w PrivateNote opisuje Jak to działa: klucz treści jest owijany za pomocą Argon2id, a owinięty klucz podróżuje w linku.

Pozostałe założenie zaufania do klienta webowego

Szyfrowanie po stronie klienta w przeglądarce nie jest aplikacją webową bez zaufania. Kryptografia może działać lokalnie, podczas gdy JavaScript, który ją realizuje, dostarcza witryna. Przeglądarka ufa kodowi, który otrzymuje na tę sesję.

Ktoś, kto może zmienić ten JavaScript — przez aplikację, CDN albo potok wdrożenia — mógłby zmienić klienta i przechwycić klucze w przyszłej sesji przeglądarki. To inna awaria niż kradzież bazy. Kompromitacja magazynu ujawnia szyfrogram. Złośliwe dostarczenie kodu atakuje punkt końcowy wtedy, gdy klucz naprawdę jest obecny.

Późniejszy zrzut bazy nie może wytworzyć kluczy po stronie klienta, które nigdy tam nie były zapisane. Aktywnie przejęty klient może atakować sekrety obsługiwane w tej sesji. To samo założenie jest wpisane w model zagrożeń PrivateNote: dostarczony kod aplikacji nie został złośliwie zmodyfikowany, a urządzenia nadawcy i odbiorcy są zaufane w chwili szyfrowania i odszyfrowania.

Zainstalowane oprogramowanie zwęża tę zależność od świeżo pobranej strony. CLI, rozszerzenie edytora albo aplikacja natywna uruchamia kod, który został zainstalowany. Te klienty nadal zależą od systemu operacyjnego, podpisu, zależności i kanału aktualizacji. Narzędzia dla deweloperów używają tego samego podziału co przeglądarka: szyfrowanie lokalne, wysłanie szyfrogramu, klucz zostaje we fragmencie.

Czas życia i poufność

Jednorazowy link odpowiada na dwa osobne pytania. Jak długo zaszyfrowany ładunek powinien istnieć? I kto może go odszyfrować, dopóki istnieje? Zniszczenie po odczycie albo po wygaśnięciu skraca okno. Nie rozstrzyga, kto mógł go odczytać w tym oknie. Czas życia i poufność wspierają się wzajemnie. Jedno nie zastępuje drugiego.

Rozróżnienie jest najostrzejsze, gdy ładunkiem jest uprawnienie: klucze API, poświadczenia baz danych, tokeny chmurowe, kody odzyskiwania, hasła infrastruktury. Usługa udostępniania sekretów istnieje, bo nadawca chce, aby mniej systemów było powiernikiem tej informacji. Jeśli pośrednik ma tylko przenieść nieprzezroczysty zaszyfrowany obiekt, wymusić wygaśnięcie i go usunąć, serwer może wykonać tę pracę, nie otrzymując sekretu ani klucza, który go otwiera.

Gdzie leży granica

„Zaszyfrowane” nie mówi, gdzie leży granica zaufania. Standardem wartym stosowania jest minimalna granica zaufania: zasada najmniejszych uprawnień zastosowana do tego, kto musi widzieć tekst jawny. We współczesnej inżynierii kryptograficznej celem nie jest jedynie zaufanie, że serwer zachowa się właściwie, lecz zmniejszenie matematycznej konieczności zaufania w ogóle.

OneTimeSecret opisuje system szyfrowany po stronie serwera. Przy ochronie frazą hasła podaje, że zapisanego sekretu nie da się później odszyfrować bez frazy hasła oraz że kompromitacja serwera zostawiłaby sekret bezpieczny, dopóki ta fraza hasła pozostaje nieznana. Słabą frazę hasła można złamać siłowo. Jeśli jest słaba, taka kompromitacja nadal może zostawić sekret możliwy do odzyskania. Tekst jawny i fraza hasła docierają do OneTimeSecret przy tworzeniu, bo szyfrowanie odbywa się na jego serwerach, a fraza hasła jest wysyłana z powrotem przy odczycie, aby te serwery mogły odszyfrować.

PrivateNote podejmuje inną decyzję architektoniczną. Ładunek jest szyfrowany, zanim dotrze do usługi, a standardowy klucz ładunku pozostaje po stronie klienta. Fraza hasła, gdy zostanie ustawiona, dodatkowo chroni ten klucz po stronie klienta lokalnie, jeśli kanał niosący link zostanie przejęty. Nie jest wysyłana do PrivateNote.

OneTimeSecret szyfruje sekret. Klient korzystający z usługi PrivateNote szyfruje go, zanim usługa go otrzyma. To rozróżnienie nie zależy od założenia, że którykolwiek dostawca jest złośliwy. Sprowadza pytanie do architektury: ile systemów potrzebuje dostępu do tekstu jawnego, aby usługa działała?

Częste pytania

Źródła pierwotne

Informacje o architekturze OneTimeSecret zostały sprawdzone względem jego publicznej dokumentacji 23 września 2026 r. Implementacje produktów i dokumentacja mogą się zmienić.

• Dokumentacja OneTimeSecret
• OneTimeSecret o bezpieczeństwie i frazach hasła
• Kod źródłowy OneTimeSecret
• Jak działa szyfrowanie PrivateNote
• PrivateNote dla deweloperów, w tym CLI
• RFC 3986, punkt 3.5, który oddziela fragment od URI przed dereferencją
• Standard URL, fragment, o obsłudze fragmentu po stronie klienta