By · Last updated 2026-03-17

Bumalik sa BlogTeknikal

LastPass Breach: Mga Aral sa Seguridad ng Vendor

Ni-encrypt ng LastPass ang data ng kanilang mga user. Ang mga vault ay ninakaw pa rin. Sumunod ang 600K+ na rekord ng Okta. Tumaas ng 300% ang mga insidente ng seguridad ng SaaS mula 2022 hanggang 2024. Narito ang dapat itanong sa bawat cloud vendor.

March 17, 20268 min basahin
LastPass breach lessonsSaaS vendor securitycloud vendor riskenterprise securityzero-knowledge architecture

Ang Insidenteng Nagbago ng Cloud Security

Na-update para sa 2026

Ang 2022 LastPass breach ay hindi pangunahing tungkol sa mga password manager. Ito ay tungkol sa tiwala. Ang mga firm ay nagtiwala sa isang cloud vendor ng kanilang data. Ang tiwalang iyon ay nasira. Ang sanhi ay mga nakatagong depekto, hindi pagpapabaya.

Nagbenta ang LastPass ng zero-knowledge na disenyo. Sa pagsasagawa, hindi ito zero-knowledge. 25 milyong user ang nagkaroon ng kanilang mga naka-encrypt na vault na ninakaw. Ang atake ay unang inisiwalat noong Agosto 2022. Nagbago ang LastPass ng kanilang mga pagsisiwalat nang ilang beses. Ang buong saklaw ay lumitaw noong huling bahagi ng 2022.

Para sa mga firm sa healthcare, pananalapi, at legal, hindi ito isang malayong balita. Ang mga sektong ito ay nakakaharap ng tunay na pananagutan kapag ang data ay tumagas. Ang kaso ng LastPass ay isang maagang senyales ng isang mas malawak na problema.

Dalawang Depekto na Nagbigay-daan sa Atake

Natuklasan ng post-incident na pagsusuri ang dalawang pangunahing kahinaan.

Mahinang key setup. Gumamit ang LastPass ng PBKDF2 para sa key derivation. Ang mga mas bagong account ay may 100,100 iteration. Inirerekomenda ng OWASP ang 600,000. Ang ilang lumang account ay may kasingbaba ng 1 iteration. Ang mas kaunting iteration ay ginagawang mabilis at mura ang mga brute-force na atake. Ang mga umaatake na may mga file ng vault ay maaaring subukan ang mga master password sa mataas na bilis.

Plaintext na metadata. Ang mga nilalaman ng vault ay naka-encrypt. Ngunit ang metadata ay hindi. Ang mga URL, username, at pangalan ng serbisyo ay lahat ay nakikita sa ninakaw na data. Nakikita ng mga umaatake kung aling mga serbisyo ang bawat user na may mga account. Nagbigay-daan iyon sa naka-target na phishing at credential stuffing. Hindi kinakailangan ang pag-crack ng vault.

Ipinapakita ng kasong ito kung bakit dalawang tanong ang dapat tanungin nang hiwalay. "Ang disenyo ba ay zero-knowledge?" ay isang tanong. "Tama ba ang pagbuo?" ay ibang tanong.

Okta noong 2023: Ibang Atake, Parehong Resulta

Noong Oktubre 2023, nag-ulat ang Okta ng isang insidente sa seguridad. Ang isang ninakaw na kredensyal ay nagbigay sa isang umaatake ng access sa sistema ng suporta ng customer nito. Ang atake ay naglantad ng 600,000+ na rekord ng suporta. Kasama rito ang mga file na na-upload ng mga customer sa panahon ng mga session ng suporta.

Ang Okta ay isang identity security platform. Ang isyu ay hindi isang depekto ng disenyo. Ito ay isang kabiguan ng kontrol sa access. Ang login ng isang support engineer ay ninakaw. Gumamit ang umaatake nito para maabot ang sensitibong data.

Ipinapakita ng LastPass at Okta ang dalawang pangunahing landas sa isang kompromiso ng vendor:

  • Mga kabiguan sa disenyo -- mga zero-knowledge na claim na hindi wastong itinayo
  • Mga kabiguan sa kontrol ng access -- mga wastong kredensyal na ginamit para maabot ang data na hindi nila dapat maabot

Pipigilan ng zero-knowledge na disenyo ang unang uri. Hindi nito titigilan ang isang umaatake na may mga wastong kredensyal ng suporta. Ngunit hinaharangan nito ang umaatakeng iyon mula sa pagbabasa ng data ng customer. Hindi kailanman hawak ng vendor ang nai-decrypt na nilalaman. Tingnan ang aming pangkalahatang-ideya ng seguridad at pagsunod para sa kung paano nailalapat ito sa mga tool ng PII.

Tumaas ng 300% ang mga Kaganapan sa Seguridad ng SaaS sa Dalawang Taon

Natuklasan ng Obsidian Security ng isang 300% na pagtaas sa mga kaganapan sa seguridad ng SaaS platform mula 2022 hanggang 2024.

Hindi ito isang 300% na pagtaas sa kakayahan ng umaatake. Dalawang puwersa ang nagmamaneho nito. Mabilis na lumago ang paggamit ng SaaS. Sinundan ng mga umaatake ang data. Ang isang kompromiso ng vendor ay maaaring maglantad ng data mula sa dose-dosenang kliyente nang sabay-sabay. Ang pay-off na iyon ay nagbibigay-pabor sa mga atake ng vendor kaysa sa mga atake ng isang firm.

Ang mga enterprise na nag-assume na ligtas ang mga cloud platform ay kailangang i-update ang pananaw na iyon. Pangunahing target na ngayon ang mga SaaS vendor.

Mga Tanong na Itatanong sa Anumang Cloud Vendor

Para sa mga koponan ng pagbili at seguridad, sinasaklaw ng checklist na ito ang mga pangunahing lugar.

Setup ng encryption:

  • Itanong ang key derivation algorithm, bilang ng iteration, at mga setting ng memorya.
  • Kumpirmahing natutugunan ng mga bilang ng iteration ang mga minimum ng OWASP. Iyon ay 600,000 PBKDF2-SHA256 o katumbas na Argon2id.
  • I-verify na ang key derivation ay tumatakbo sa inyong device, hindi sa mga server ng vendor.

Pagkakalantad ng metadata:

  • Itanong kung aling metadata ang nakaimbak sa plaintext sa tabi ng naka-encrypt na nilalaman.
  • Humiling ng modelo ng data. Dapat itong ipakita kung aling mga field ang naka-encrypt at kung aling mga field ay nakikita sa isang atake.

Access ng suporta:

  • Itanong kung maaaring i-access ng staff ng suporta ang data ng customer.
  • Kumpirmahing hindi maaaring maabot ng mga sistema ng suporta ang plaintext ng customer.

Kasaysayan ng insidente:

  • Itanong ang lahat ng nakaraang mga kaganapan sa seguridad, kasama ang mga nasa ibaba ng mga threshold ng pampublikong pagsisiwalat.
  • Suriin kung gaano kasimpleto at katapat ang mga nakaraang pagsisiwalat.

Ang insidente ng LastPass ay isang kabiguan sa pagbuo at isang kabiguan sa tiwala. Ang mga vendor na may mga tiyak na sagot ay nagbibigay-daan sa tunay na pagsusuri ng panganib. Ang mga vendor na may malabong mga claim ay nagtatago ng panganib. Ang panganib na iyon ay kadalasang lumilitaw pagkatapos lamang ng isang atake. Tingnan ang aming pangkalahatang-ideya ng pagsunod para sa gabay sa ebalwasyon ng vendor.


Gumagamit ang anonym.legal ng zero-knowledge na arkitektura para sa anonymization ng PII. Ang key derivation ay tumatakbo sa pamamagitan ng Argon2id sa inyong browser o desktop app. Ang encryption ay nagaganap bago umalis ang data sa inyong device. Ang mga server ay nag-iimbak lamang ng ciphertext na hindi nila maaaring i-decrypt. Matuto pa.

Mga Pinagkukunan

Handa nang protektahan ang iyong data?

Simulan ang anonymization ng PII gamit ang 285+ uri ng entidad sa 48 wika.

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.