By · Last updated 2026-03-16

Atgal į BlogąTechninė

ZK teiginių vertinimas po LastPass

438 mln. USD pavogta iš LastPass vartotojų po jų "užšifruotų" saugyklų pažeidimo. Sekė 1,2 mln. GBP ICO bauda. Štai patikrinimų sąrašas, kaip įvertinti, ar tiekėjo teiginys yra realus.

March 16, 20268 min skaityti
zero-knowledge evaluationvendor security assessmentLastPass breachcloud encryption claimsGDPR Article 32

Atotrūkis tarp teiginio ir architektūros

Atnaujinta 2026 m.

Kiekvienas debesijos tiekėjas sako tą patį: "Mes šifruojame jūsų duomenis." Tas teiginys beveik visada yra teisingas. Beveik visada jo nepakanka.

2022 m. LastPass pažeidimas yra geriausias pavyzdys. LastPass šifravo vartotojų slaptažodžių saugyklas. Jie naudojo realų šifravimą. Teiginys buvo tikslus. Ir vis dėlto 25 mln. vartotojų turėjo savo saugyklas pavogtas. Iki 2025 m. 438 mln. USD buvo paimta iš LastPass vartotojų kriptovaliutų plėšimuose. Coinbase Institutional sekė šį skaičių.

Jungtinės Karalystės Informacijos komisaro biuras 2025 m. gruodį nubaudė LastPass JK subjektą 1,2 mln. GBP. Priežastis: "nesugebėjimas įgyvendinti tinkamų techninių ir organizacinių saugumo priemonių." Šifravimas buvo realus. Tačiau jis neatitiko reikalaujamo standarto.

LastPass byla keičia pagrindinį klausimą bet kuriam debesijos privatumo įrankiui. Ne "ar jie šifruoja mūsų duomenis?", bet: "ar jie gali iššifruoti mūsų duomenis?"

Keturi klausimai, kurie iš tikrujų svarbūs

Keturi klausimai atskleidžia, ar tiekėjo nulinių žinių teiginys atlaiko tikrinimą.

1. Kur vyksta raktų išvedimas?

Tikrame nulinių žinių dizaine raktų išvedimas vyksta kliente. Tai reiškia naršyklėje ar darbalaukio programoje, prieš siunčiant bet kokius duomenis. Raktas vietoje užšifruoja duomenis. Tik šifrotekstas pasiekia tiekėjo serverius.

Jei tiekėjas išveda raktus savo serveriuose, jie laiko raktus. Jei jie laiko raktus, jie gali iššifruoti. Teiginys gali būti tikslus - tačiau jis klaidina.

2. Ar tiekėjas kada nors mato aiškų tekstą?

Kai kurie įrankiai šifruoja duomenis saugomi. Tačiau jie iššifruoja apdorojimui. Tai gali vykti, kai veikia AI modeliai, paieškos indeksai ar audito žurnalai. Per tą langą aiškus tekstas yra tiekėjo sistemose. Ataka tuo momentu atskleidžia nešifruotus duomenis.

3. Kas nutinka pagal teisinį procesą?

Tiekėjas su serverio pusės raktais gali būti priverstas perduoti iššifruotą turinį. Tiekėjas su tikrais nuliniais žinių gali tik pateikti šifrotekstą. Jiems nėra ko perduoti, net pagal šaukimą.

4. Ką atskleidžia pilnas serverio kompromisas?

Tikroje nulinių žinių sistemoje pilnas kompromisas duoda tik užšifruotus blokus. Uzpuolikas gauna šifrotekstą be raktų. Tiekėjo raktų sistemoje įsibrovimas atskleidžia tiek raktus, tiek duomenis iš karto.

LastPass įgyvendinimo spraga

LastPass incidentas atskleidė vieną specifinį trūkumą. Senesni paskyros naudojo PBKDF2 su tik 1 iteracija raktų išvedimui. Saugus skaičius yra 600 000 iteracijų. Tas silpnas nustatymas padarė žiaurios jėgos atakas prieš pavogtas saugyklas įmanomas.

Tai rodo, kodėl dizaino tikrinimas vienas nepakanka. Tiekėjas gali naudoti nulinių žinių dizainą ir vis tiek jį blogai įgyvendinti. Klauskite apie abu: kur raktai yra išvedami ir kaip stiprus yra algoritmas.

Kitoks nesėkmės būdas: Okta

2023 m. spalį Okta atskleidė daugiau nei 600 000 klientų paramos įrašų nutekėjimą. Okta yra tapatybės platforma. Tai nebuvo silpnas nulinių žinių dizainas. Tai buvo palaikymo sistemos įsibrovimas, laikantis klientų duomenis.

300 % SaaS atakų augimas 2024 m. (AppOmni/CSA) atspindi abu nesėkmių tipus. Nulinių žinių dizainas sprendžia pirmąjį tipą. Jis nepašalina visos rizikos. Tačiau jis užtikrina, kad pilnas sistemos kompromisas neatskleidžia jokių iššifruojamų klientų duomenų.

Kaip atrodo realus vertinimas

Stai praktinis patikrinimų sąrašas pirkimo ir saugumo komandoms.

Architektūros peržiūra:

  • Klauskite, kur vyksta raktų išvedimas - kliente ar tiekėjo serveryje
  • Prašykite šifravimo algoritmo, rakto ilgio ir iteracijų skaičiaus
  • Patvirtinkite, kad aiškus tekstas niekada nesiunčiamas į tiekėjo serverius

Kompromiso scenarijaus testas:

  • Klauskite, ką atskleistų pilnas serverio kompromisas
  • Vienintelis teisingas atsakymas: "užšifruotas šifrotekstas, kurio mes negalime iššifruoti"
  • Bet kuris kitas atsakymas reiškia, kad teiginys nėra tikra nulinė žinių

Teisinio proceso peržiūra:

  • Klauskite, ar tiekėjas gali laikytis šaukimo dėl klientų aiškaus teksto
  • Tikras nulinių žinių tiekėjas negali pateikti to, ko jie neturi

Atitikties patikrinimas:

  • Prašykite tiekėjo BDAR 32 straipsnio dokumentacijos
  • ISO 27001 - konkrečiai A priedo kriptografines kontroles - suteikia išorinį patvirtinimą

1,2 mln. GBP LastPass ICO bauda rodo, kad reguliatoriai dabar tikrina, ar šifravimo teiginiai atitinka reikalaujamą standartą. Pirkimo komandos gali taikyti tą patį testą prieš incidentui nutinkant.

Žiūrėkite mūsų saugumo ir atitikties apžvalgą apie tai, kaip anonym.legal tvarko nulines žinias. Atitikties dokumentacija išsamiai apima BDAR 32 straipsnį. Dažniems klausimams žiūrėkite nulinių žinių DUK.

Šaltiniai

Pasiruošę apsaugoti savo duomenis?

Pradėkite anonimizuoti PII su 285+ subjektų tipais 48 kalbomis.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.