Decalajul dintre afirmație și arhitectură
Fiecare furnizor de cloud care gestionează date sensibile face o versiune a aceleiași afirmații: "Criptăm datele tale." Afirmația este aproape întotdeauna adevărată — și aproape întotdeauna insuficientă.
Breșa LastPass din 2022 este studiul de caz definitoriu. LastPass a criptat seifurile de parole ale utilizatorilor lor. Au folosit criptare. Afirmația era exactă. Și totuși 25 de milioane de utilizatori au avut seifurile lor criptate exfiltrate, și $438 de milioane au fost furați ulterior de la utilizatorii LastPass în jafuri de criptomonede din aval prin 2025, conform cercetării de la Coinbase Institutional.
Birou Comisarului pentru Informații din Marea Britanie a amendat entitatea LastPass din Marea Britanie cu £1,2 milioane în decembrie 2025 pentru "eșecul de a implementa măsuri tehnice și organizaționale de securitate adecvate." Criptarea exista. Măsurile de securitate nu au îndeplinit standardul necesar.
Pentru întreprinderi care evaluează instrumente de confidențialitate în cloud — inclusiv platforme de anonimizare PII — precedentul LastPass schimbă întrebarea de achiziție. Întrebarea nu este "criptează ei datele noastre?" Ci "pot ei decripta datele noastre?"
Cele patru întrebări Zero-Knowledge care contează cu adevărat
Când evaluezi afirmația zero-knowledge a unui furnizor, patru întrebări determină dacă arhitectura este genuină:
1. Unde se întâmplă derivarea cheii?
În arhitectura zero-knowledge adevărată, derivarea cheii de criptare se întâmplă pe partea client — în browser sau aplicația desktop — înainte ca orice date să fie transmise. Cheia derivată este folosită pentru a cripta datele local. Doar textul cifrat criptat se transmite la serverele furnizorului.
Dacă furnizorul derivează chei de criptare pe serverele lor, ei dețin cheile. Dacă dețin cheile, pot decripta. Afirmația este din punct de vedere tehnic exactă ("criptăm") dar înșelătoare în implicația sa.
2. Are furnizorul vreodată acces la textul clar?
Unele instrumente criptează datele în repaus, dar le decriptează pentru procesare — rulând modele AI, analize, indexare de căutare sau generare de jurnale de audit. În perioada de procesare, textul clar este accesibil pe infrastructura furnizorului. O breșă în acea perioadă expune datele în formă necriptată.
3. Ce se întâmplă sub proces legal?
Dacă o agenție guvernamentală servește o citație furnizorului, ce date pot produce? Un furnizor cu chei pe server poate fi obligat să producă conținut decriptat. Un furnizor cu arhitectură zero-knowledge poate produce doar text cifrat criptat — chiar și sub constrângere legală, nu au nimic util de predat.
4. Ce expune o compromitere completă a serverului?
Într-o implementare zero-knowledge genuină, o breșă completă a infrastructurii furnizorului produce doar bloburi criptate. Atacatorul primește text cifrat fără cheile pentru a-l decripta. Într-o implementare cu cheie controlată de furnizor, o breșă de server expune cheile alături de date.
Eșecul implementării LastPass
Breșa LastPass a dezvăluit un decalaj specific de implementare: conturile mai vechi foloseau PBKDF2 cu doar 1 iterație pentru derivarea cheii, în loc de 600.000 de iterații recomandate. Derivarea cheii mai slabă a făcut atacurile brute-force pe seifurile exfiltrate din punct de vedere computațional fezabile.
Aceasta ilustrează de ce evaluarea afirmațiilor zero-knowledge necesită examinarea detaliilor de implementare, nu doar descrierile arhitecturale. Un furnizor poate folosi un design zero-knowledge în timp ce îl implementează slab. Întrebările corecte de pus acoperă atât arhitectura (locația derivării cheii) cât și forța implementării (algoritm și numărul de iterații).
Breșa Okta: Un mod de eșec diferit
În octombrie 2023, Okta a dezvăluit că 600.000+ înregistrări de suport pentru clienți au fost scurse într-o breșă. Okta este o platformă de identitate — compania pe care multe întreprinderi o folosesc pentru a securiza accesul la alte instrumente cloud. Breșa Okta a fost un mod de eșec diferit de LastPass: nu o slăbiciune în implementarea zero-knowledge, ci o compromitere a infrastructurii de suport care se întâmplă să conțină date de clienți.
Creșterea breșelor SaaS de 300% în 2024 (AppOmni/CSA) reflectă ambele moduri de eșec: slăbiciuni arhitecturale ca LastPass și compromitări de infrastructură ca Okta. Arhitectura zero-knowledge abordează modul de eșec arhitectural. Nu elimină tot riscul de breșă, dar asigură că chiar și o compromitere completă a infrastructurii nu expune date de clienți decriptabile.
Cum arată o evaluare genuină
Pentru echipele de achiziție care evaluează afirmații zero-knowledge, lista de verificare a evaluării:
Revizuire arhitecturală:
- Solicită documentație care arată unde se întâmplă derivarea cheii (client-side vs. server-side)
- Întreabă despre algoritmul de criptare, lungimea cheii și numărul de iterații
- Solicită confirmarea că textul clar nu este niciodată transmis la serverele furnizorului
Testare scenariilor de breșă:
- Întreabă furnizorul să descrie ce ar expune o compromitere completă a serverului
- Dacă răspunsul include orice altceva decât "text cifrat criptat pe care nu îl putem decripta," afirmația nu este zero-knowledge genuină
Revizuire proces legal:
- Întreabă dacă furnizorul poate respecta o citație care necesită producerea de text clar al clientului
- Furnizorii zero-knowledge genuini nu pot produce ceea ce nu au
Documentație de conformitate:
- Solicită documentația de conformitate GDPR Articolul 32 a furnizorului
- Certificarea ISO 27001 (în special Anexa A controale criptografice) oferă verificare externă a practicilor de gestionare a cheilor
Amenda de £1,2 milioane LastPass ICO stabilește că furnizorii care fac afirmații de criptare sunt supuși evaluării de reglementare a faptului că acele afirmații îndeplinesc standardul necesar. Același cadru de evaluare pe care îl aplică reglementatorii este disponibil pentru echipele de achiziție înainte ca o breșă să se întâmple.
Surse: