OneTimeSecret vs PrivateNote: de ce contează unde criptați

Două moduri de a construi același link

În criptarea pe server, expeditorul trimite secretul către serviciu prin TLS. Serviciul primește textul în clar, îl criptează și stochează text cifrat. Poate apoi stoca încărcătura, o poate livra, o poate face să expire și o poate șterge. Serverul de aplicație face parte din procesul de criptare, pentru că textul în clar intră în serviciu înainte să devină text cifrat.

În criptarea pe partea clientului, dispozitivul expeditorului criptează mai întâi. Serviciul primește și stochează text cifrat. Acea încărcare circulă prin TLS. Serviciul nu primește cheia necesară pentru a decripta o încărcătură standard. Dispozitivul destinatarului decriptează local. Serviciul poate în continuare stoca, livra, face să expire și șterge încărcătura fără să aibă nevoie de acces la textul ei în clar.

Ambele concepții pot oferi linkuri temporare, acces limitat și expirare. Ambele pot fi descrise corect ca fiind criptate. OneTimeSecret folosește prima arhitectură; PrivateNote o folosește pe a doua. Întrebarea relevantă nu este, așadar, pur și simplu dacă un link de unică folosință este criptat, ci care sisteme trebuie să aibă acces la textul în clar pentru ca acel link să funcționeze.

OneTimeSecret: criptare pe server

În fluxul obișnuit OneTimeSecret, expeditorul trimite secretul prin TLS. Aplicația primește textul în clar, îl criptează pe server și stochează încărcătura criptată.

Aceasta oferă o protecție reală pentru datele stocate. Obținerea doar a stocării criptate nu dezvăluie neapărat conținutul, când materialul necesar pentru decriptare nu este disponibil atacatorului.

Compromisul de arhitectură apare înainte de stocare. TLS protejează secretul cât circulă între browser și OneTimeSecret, dar aplicația trebuie să prelucreze textul în clar ca să îl cripteze. Serverul de aplicație se află, așadar, în interiorul limitei de încredere criptografică.

Un proces de aplicație rău intenționat sau compromis în acel moment ar putea accesa secretul înainte să fie criptat pentru stocare. Criptarea pe partea clientului elimină această dependență anume, criptând secretul înainte să ajungă la serviciu.

Fraza de acces OneTimeSecret nu schimbă limita de criptare

Documentația OneTimeSecret descrie o frază de acces opțională. Când se folosește o frază de acces, OneTimeSecret spune că secretul este criptat pe serverele sale cu fraza de acces furnizată de expeditor. Spune că nu stochează fraza de acces însăși; în schimb, păstrează un hash bcrypt folosit ca să verifice fraza de acces la recuperare. Conform documentației sale, acel hash nu poate decripta el însuși secretul, iar secretul stocat, protejat prin frază de acces, nu poate fi decriptat fără fraza de acces originală.

Recuperarea folosește aceeași limită de pe server. Destinatarul furnizează fraza de acces către OneTimeSecret prin TLS. Serviciul o verifică și efectuează decriptarea pe server înainte să returneze textul în clar.

Aceasta înseamnă că procesul aplicației are acces la secret și la fraza de acces când are loc criptarea și prelucrează din nou fraza de acces și textul în clar rezultat în timpul recuperării. Un proces de aplicație rău intenționat sau compromis, care operează în oricare dintre aceste puncte, ar putea captura acele informații. Aceasta este o consecință a locului în care se execută criptarea și decriptarea, nu o afirmație că OneTimeSecret înregistrează sau folosește abuziv acele valori.

Documentația publică OneTimeSecret nu stabilește, prin ea însăși, fiecare detaliu al ierarhiei interne de chei — de exemplu, precis cum se combină materialul de chei de pe server, cheile per secret, derivarea cheilor și fraza de acces furnizată. Nu este nevoie să speculăm asupra acestor detalii de implementare pentru această comparație. Proprietatea documentată relevantă este că criptarea și decriptarea au loc pe partea serviciului.

Auto-găzduirea poate face rezonabilă încrederea în acel server

OneTimeSecret are codul-sursă deschis. O organizație își poate rula propria instanță în interiorul unui perimetru de securitate al întreprinderii, în loc să trimită secretele către serviciul public.

În acea implementare, a avea încredere în serverul de aplicație înseamnă a avea încredere în infrastructura pe care organizația o operează deja. Textul în clar ajunge în continuare la acel server, pentru că criptarea are loc tot acolo. Partea de cealaltă parte a limitei o reprezintă gazdele, operatorii și copiile de rezervă ale organizației. Pentru o echipă care acceptă deja aceste sisteme ca parte din drumul pe care îl parcurge un secret, criptarea pe server poate fi o alegere rezonabilă. Ea îngustează golul dintre modelele de amenințare de pe server și de pe client, pentru că operatorul nu mai este un serviciu din afară.

PrivateNote criptează înainte de încărcare

O notă PrivateNote standard este criptată înainte de încărcare. Browserul expeditorului, sau un proces local CLI, extensie Chrome, extensie de editor ori MCP, generează o cheie aleatoare și criptează încărcătura cu AES-256-GCM. Se încarcă doar text cifrat. TLS transportă acel text cifrat din browser către Cloudflare Worker al PrivateNote. Cheia de decriptare este plasată în fragmentul URL, partea de după #, de exemplu https://privatenote.ai/note/abc123#…. Fragmentul este tratat pe partea clientului și nu este inclus în cererea HTTPS (RFC 3986, §3.5; Standardul URL). Cloudflare Worker primește un identificator de notă și returnează text cifrat prin aceeași conexiune TLS. Browserul păstrează fragmentul și decriptează local.

O frază de acces protejează cheia dacă este compromis canalul linkului

O frază de acces pe PrivateNote face o treabă diferită de o frază de acces pe OneTimeSecret. Nota este deja text cifrat înainte să părăsească dispozitivul. Dacă adăugați o frază de acces, browserul derivă din ea o cheie de înfășurare cu Argon2id și folosește acea cheie de înfășurare ca să cripteze cheia notei. Fragmentul URL ține apoi cheia înfășurată. Destinatarul are nevoie de link și de fraza de acces. Browserul desface cheia local și abia apoi decriptează nota.

PrivateNote nu primește fraza de acces. Cererea de creare poartă text cifrat, un salt și parametrii de care browserul destinatarului are nevoie ca să încerce fraza de acces local. Nu există un hash pe server a cărui sarcină să fie verificarea frazei de acces. O frază de acces greșită eșuează decriptarea pe dispozitiv.

Fraza de acces protejează în plus, local, cheia de pe partea clientului dacă este compromis canalul care poartă linkul. Canalul vede atunci o cheie înfășurată, nu o cheie care poate deschide nota de una singură. Nu acesta este mecanismul care ține PrivateNote în afara căii textului în clar. Acea separare există deja la o notă standard, cu sau fără frază de acces. Partajați fraza de acces pe un canal diferit de link. Același mesaj prăbușește cele două straturi într-unul singur — aceeași regulă ca la partajarea unei parole în siguranță.

Tratarea cheilor în PrivateNote este descrisă la Cum funcționează: cheia de conținut este înfășurată cu Argon2id, iar cheia înfășurată circulă în link.

Ipoteza de încredere rămasă pentru clientul web

Criptarea pe partea clientului într-un browser nu este o aplicație web fără încredere. Criptografia poate rula local, în timp ce JavaScriptul care o implementează este livrat de site. Browserul are încredere în codul pe care îl primește pentru acea sesiune.

Cineva care poate modifica acel JavaScript — prin aplicație, un CDN sau pipeline-ul de implementare — ar putea schimba clientul și captura chei într-o sesiune viitoare de browser. Aceasta este o defecțiune diferită de furtul unei baze de date. O compromitere a stocării expune text cifrat. Livrarea de cod rău intenționat atacă punctul terminal cât timp cheia este efectiv prezentă.

O extragere ulterioară a bazei de date nu poate fabrica chei de pe partea clientului care nu au fost stocate niciodată acolo. Un client compromis activ poate ataca secretele tratate în acea sesiune. Aceeași ipoteză este scrisă în modelul de amenințare PrivateNote: codul aplicației livrate nu a fost modificat cu rea intenție, iar dispozitivele expeditorului și ale destinatarului sunt de încredere în momentul criptării și al decriptării.

Software-ul instalat îngustează acea dependență de o pagină proaspăt descărcată. Un CLI, o extensie de editor sau o aplicație nativă rulează cod pe care l-ați instalat. Acești clienți depind în continuare de sistemul de operare, de semnare, de dependențe și de canalul de actualizare. Uneltele pentru dezvoltatori folosesc aceeași separare ca browserul: criptați local, încărcați text cifrat, lăsați cheia în fragment.

Durata de viață și confidențialitatea

Un link de unică folosință răspunde la două întrebări separate. Cât timp ar trebui să existe încărcătura criptată? Și cine o poate decripta cât timp există? Distrugerea ei după recuperare sau după expirare scurtează fereastra. Nu decide cine ar fi putut să o citească în acea fereastră. Durata de viață și confidențialitatea se susțin reciproc. Una nu ține locul celeilalte.

Distincția este cea mai netă când încărcătura este autoritate: chei API, acreditări de bază de date, tokenuri cloud, coduri de recuperare, parole de infrastructură. Un serviciu de partajare a secretelor există pentru că expeditorul vrea mai puține sisteme cărora să le încredințeze acea informație. Dacă intermediarul trebuie doar să poarte un obiect criptat opac, să impună expirarea și să îl șteargă, serverul poate face acea muncă fără să primească secretul sau cheia care îl deschide.

Unde stă limita

„Criptat” nu vă spune unde stă limita de încredere. Standardul care merită folosit este o limită de încredere minimă: principiul privilegiului minim aplicat la cine trebuie să vadă textul în clar. În ingineria criptografică modernă, scopul nu este doar să aveți încredere că un server se comportă corect, ci să reduceți necesitatea matematică a încrederii, din capul locului.

OneTimeSecret descrie un sistem criptat pe server. Cu protecție prin frază de acces, spune că secretul stocat nu poate fi decriptat ulterior fără fraza de acces și că o compromitere a serverului ar lăsa secretul în siguranță atât timp cât acea frază de acces rămâne necunoscută. O frază de acces slabă poate fi forțată prin încercări. Dacă este slabă, acea compromitere poate lăsa secretul recuperabil. Textul în clar și fraza de acces ajung la OneTimeSecret la creare, pentru că criptarea are loc pe serverele sale, iar fraza de acces este trimisă înapoi la recuperare, ca acele servere să poată decripta.

PrivateNote face o alegere de arhitectură diferită. Încărcătura este criptată înainte să ajungă la serviciu, iar cheia standard a încărcăturii rămâne pe partea clientului. O frază de acces, când setați una, protejează în plus acea cheie de pe partea clientului, local, dacă este compromis canalul care poartă linkul. Ea nu este trimisă către PrivateNote.

OneTimeSecret criptează secretul dumneavoastră. Clientul care folosește serviciul PrivateNote îl criptează înainte ca serviciul să îl primească. Această distincție nu depinde de presupunerea că vreunul dintre furnizori ar fi rău intenționat. Ea reduce întrebarea la arhitectură: de câte sisteme este nevoie să aibă acces la textul în clar pentru ca serviciul să funcționeze?

Întrebări frecvente

Surse primare

Informațiile de arhitectură despre OneTimeSecret au fost verificate față de documentația sa publică la 23 septembrie 2026. Implementările produselor și documentația se pot schimba.

• Documentația OneTimeSecret
• OneTimeSecret despre securitate și fraze de acces
• Codul-sursă OneTimeSecret
• Cum funcționează criptarea PrivateNote
• PrivateNote pentru dezvoltatori, inclusiv CLI
• RFC 3986, secțiunea 3.5, care separă fragmentul de URI înainte de dereferențiere
• Standardul URL, fragment, despre tratarea fragmentului pe partea clientului