Ne koristite zaporke za šifriranje korisničkih podataka

Zaporke su najuzbudljiviji razvoj autentifikacije u posljednjih nekoliko godina. Uklanjaju krađu identiteta, uklanjaju teret lozinki i pružaju besprijekorno iskustvo prijave uz podršku kriptografije s javnim ključem. No opasna zabluda širi se zajednicama programera: ako su pristupni ključevi kriptografski, sigurno mogu i šifrirati korisničke podatke. Ne mogu - a pokušaj da ih se koristi na taj način stvorit će krhke, nepouzdane sustave koji bi vašim korisnicima mogli trajno onemogućiti pristup vlastitim informacijama. Razumijevanje zašto zahtijeva jasan uvid u to što su pristupni ključevi zapravo, koji su zahtjevi za enkripciju i gdje se to dvoje razlikuje na načine koji su iznimno važni za bilo koju platformu koja rukuje osjetljivim poslovnim podacima.

Autentifikacija i enkripcija bitno su različiti poslovi

Autentifikacija odgovara na jedno pitanje: "Jeste li vi ono za što se predstavljate?" Enkripcija odgovara na sasvim drugo pitanje: "Mogu li ovi podaci ostati nečitljivi svima osim ovlaštenim osobama?" Ova dva problema dijele kriptografske primitive, ali se inženjerski zahtjevi oštro razlikuju. Provjera autentičnosti mora se dogoditi jednom po sesiji, može tolerirati povremeni neuspjeh s elegantnim zamjenama i ne mora proizvoditi isti izlaz svaki put. Enkripcija zahtijeva deterministički pristup ključu koji se može ponoviti tijekom cijelog životnog vijeka podataka — što može trajati godinama ili desetljećima.

Kada se autentifikujete šifrom, vaš uređaj generira kriptografski potpis koji dokazuje da imate privatni ključ povezan s vašim računom. Poslužitelj provjerava ovaj potpis i odobrava pristup. Ni u jednom trenutku poslužitelj — pa čak ni vaša aplikacija — ne dobivaju pristup samom materijalu privatnog ključa. Ovo je značajka, a ne ograničenje. Cijeli sigurnosni model pristupnih ključeva ovisi o tome da privatni ključ nikada ne napušta sigurnu enklavu vašeg uređaja. Ali enkripcija zahtijeva da koristite ključ za transformaciju podataka, a kasnije koristite taj isti ključ (ili njegov pandan) da poništite transformaciju. Ako ne možete pouzdano pristupiti ključu, ne možete pouzdano dešifrirati.

Platforme poput Mewayza koje upravljaju osjetljivim poslovnim podacima — fakturama, evidencijama plaća, CRM kontaktima, HR dokumentima u 207 modula — trebaju strategije šifriranja izgrađene na ključevima koji su trajni, povratni i dosljedno dostupni. Izgradnja toga na temeljima dizajniranim posebno za sprječavanje pristupa ključu je arhitektonska kontradikcija.

Zašto se zaporke ne koriste kao ključevi za šifriranje

Specifikacija WebAuthn, koja podupire pristupne ključeve, namjerno je dizajnirana s ograničenjima koja čine upotrebu enkripcije nepraktičnom. Razumijevanje ovih ograničenja otkriva zašto to nije jaz koji pametni inženjering može premostiti — to je temeljna granica dizajna.

• Nema izvoza ključa: Privatni ključevi generirani tijekom registracije zaporke pohranjuju se u hardverski podržane sigurne enklave (TPM, Secure Enclave ili ekvivalent). Operativni sustav i API-ji preglednika ne pružaju mehanizam za izdvajanje sirovog ključnog materijala. Možete tražiti ključ da nešto potpiše, ali ne možete pročitati sam ključ.
• Generacija nedeterminističkog ključa: Stvaranje zaporke za istog korisnika na drugom uređaju proizvodi potpuno drugačiji par ključeva. Nema početne fraze, nema puta derivacije, nema načina da se isti ključ rekonstruira na drugom uređaju. Svaka je registracija kriptografski neovisna.
• Dostupnost vezana uz uređaj: čak i uz sinkronizaciju zaporke (iCloud Keychain, Google Password Manager), dostupnost ovisi o sudjelovanju ekosustava. Korisnik koji se registrira na iPhoneu i kasnije prijeđe na Android može izgubiti pristup. Korisnik čiji je uređaj izgubljen, ukraden ili vraćen na tvorničke postavke suočava se s istim problemom.
• Samo odgovor na izazov: WebAuthn API izlaže navigator.credentials.get() koji vraća potpisanu tvrdnju, a ne neobrađeni materijal ključa. Primate potpis preko izazova koji pruža poslužitelj — koristan za dokazivanje identiteta, beskoristan za izvođenje ključa za šifriranje.
• Nema fleksibilnosti algoritma: Zaporke obično koriste ECDSA s krivuljom P-256. Čak i kad biste mogli pristupiti ključu, ECDSA je algoritam za potpisivanje, a ne algoritam za šifriranje. Trebat će vam dodatne transformacije (ECDH sporazum o ključu, KDF derivacija) koje API ne podržava u ovom kontekstu.

Neki su programeri predložili zaobilazna rješenja — korištenje PRF (Pseudo-Random Function) proširenja za WebAuthn, na primjer, za izvođenje simetričnih ključeva tijekom autentifikacije. Iako ovo proširenje postoji u specifikaciji, podrška preglednika ostaje nedosljedna, nedostupno je na mnogim mobilnim platformama i još uvijek nasljeđuje problem vezivanja uređaja. Ključ izveden putem PRF-a na jednom uređaju ne može se reproducirati na drugom uređaju s drugim pristupnim ključem, čak ni za isti korisnički račun.

Scenarij gubitka podataka koji nitko ne želi slati

Razmotrite što se događa kada kriptirate korisničke podatke ključem izvedenim iz njihove pristupne šifre. Prvog dana sve radi prekrasno. Korisnik se prijavljuje, ključ se izvodi, podaci se besprijekorno šifriraju i dekriptiraju. Zatim tri mjeseca kasnije njihov telefon pada u jezero.

Kod tradicionalne provjere autentičnosti gubitak uređaja predstavlja neugodnost. Korisnik oporavlja svoj račun putem e-pošte, postavlja nove vjerodajnice i nastavlja s radom. Ali ako su njihovi podaci bili šifrirani ključem vezanim za sigurnu enklavu sada potopljenog uređaja, ti podaci su nestali. Nije nestalo "teško oporaviti" — nestalo je kriptografski nepovratno. Nikakva prijava korisničke podrške, nikakav tijek oporavka računa, nikakva izvršna eskalacija ne mogu preokrenuti računicu. Podaci su možda i izbrisani.

Glavno pravilo dizajna sustava enkripcije: ako vaša strategija upravljanja ključem ima bilo koju točku kvara koja trajno uništava pristup korisničkim podacima, niste izgradili sigurnosnu značajku — izgradili ste mehanizam gubitka podataka s dodatnim koracima.

Za tvrtku koja posluje putem platforme — upravljanje odnosima s 50 klijenata u CRM-u, obrada mjesečnih plaća za 30 zaposlenika, praćenje voznog parka — trajni gubitak podataka s ispuštenog telefona nije manji problem korisničkog doživljaja. To je katastrofa kontinuiteta poslovanja. Upravo je to razlog zašto Mewayzova arhitektura odvaja mehanizme provjere autentičnosti od slojeva zaštite podataka, osiguravajući da niti jedan kvar uređaja ne može ugroziti pristup kritičnim poslovnim informacijama u bilo kojem od njegovih integriranih modula.

Što biste trebali koristiti umjesto toga

Dobra vijest je da postoje dobro uspostavljeni obrasci za šifriranje korisničkih podataka bez upadanja u zamku zaporke. Ovi su pristupi testirani u bitkama, široko podržani i dizajnirani posebno za slučajeve upotrebe enkripcije.

Šifriranje na strani poslužitelja s upravljanim ključevima ostaje najpraktičniji izbor za veliku većinu aplikacija. Vaša platforma šifrira podatke u mirovanju koristeći ključeve kojima se upravlja putem odgovarajuće usluge upravljanja ključevima (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault ili ekvivalent. Korisnik se autentificira (s ključevima, ako želite!), a poslužitelj transparentno rukuje šifriranjem i dešifriranjem. Ovo je način na koji većina SaaS platformi štiti podatke, a to funkcionira jer su ključevi izdržljivi, sigurnosno kopirani, rotirajući i neovisni o bilo kojem korisničkom uređaju.

Ključevi za šifriranje izvedeni iz zaporke (koristeći Argon2id ili scrypt za izvođenje ključa) prikladni su kada vam je potrebna istinska enkripcija bez znanja gdje čak ni poslužitelj ne može čitati korisničke podatke. Kompromis je u tome što gubitak lozinke znači gubitak podataka, ali lozinke se mogu pamtiti, zapisivati ​​i pohranjivati ​​u upraviteljima lozinki — nisu zaključane unutar hardverske enklave. Usluge kao što su 1Password i Standard Notes učinkovito koriste ovaj pristup.

1. Koristite zaporke (ili bilo koju jaku metodu) za autentifikaciju — provjeru identiteta korisnika.
2. Nakon provjere autentičnosti, izvedite ili dohvatite ključeve za šifriranje putem zasebnog, namjenski izgrađenog sustava za upravljanje ključevima.
3. Implementirajte mehanizme deponiranja ili oporavka ključeva — ključeve za oporavak, sinkronizaciju ključeva na više uređaja ili skrbništvo nad organizacijskim ključem za poslovne račune.
4. Šifrirajte podatke u mirovanju i u prijenosu pomoću AES-256-GCM ili XChaCha20-Poly1305 s ključevima s vašeg KMS-a.
5. Povremeno rotirajte ključeve i održavajte sigurnosne kopije šifriranih ključeva koje mogu preživjeti svaku točku kvara.

Ovo razdvajanje pitanja nije samo najbolja praksa — to je jedina arhitektura koja vam omogućuje nadogradnju metoda provjere autentičnosti neovisno o vašoj strategiji šifriranja. Kada se šifre s vremenom razviju ili budu zamijenjene nečim boljim, vaši šifrirani podaci ostaju savršeno dostupni.

PRF proširenje: obećanja i zamke

Programeri koji pomno slijede specifikaciju WebAuthna mogu ukazati na proširenje prf kao potencijalni most između zaporki i enkripcije. Ovo proširenje omogućuje pouzdanoj strani da zatraži pseudo-slučajnu vrijednost izvedenu iz tajnog materijala pristupnog ključa tijekom ceremonije autentifikacije. U teoriji, ova bi vrijednost mogla poslužiti kao ključ za šifriranje ili sjeme.

U praksi, proširenje PRF-a suočava se sa značajnim preprekama usvajanja. Od početka 2026. podrška se dramatično razlikuje u različitim preglednicima i platformama. Safarijeva implementacija razlikuje se od Chromeove. Mnogi Android uređaji to uopće ne podržavaju. Hardverski sigurnosni ključevi imaju nedosljednu podršku. Za bilo koju platformu koja opslužuje raznoliku bazu korisnika — a Mewayz opslužuje više od 138 000 korisnika na svim glavnim operativnim sustavima i vrstama uređaja — izgradnja enkripcije na značajci s nejednakom dostupnošću operativno je neodrživa.

Još temeljnije, PRF ne rješava problem više uređaja. Pseudoslučajni izlaz izveden je iz specifičnog pristupnog ključa na određenom uređaju. Korisnik koji registrira pristupne ključeve na prijenosnom računalu i telefonu dobiva dva različita PRF izlaza za isti račun. Trebali biste kriptirati podatke izvedenim ključem jednog uređaja, a zatim nekako ponovno kriptirati ili podijeliti taj ključ s drugim uređajem — što vas ionako vraća na izgradnju odgovarajućeg sustava za upravljanje ključevima. U tom trenutku ključ izveden iz pristupnog ključa dodaje složenost bez dodavanja sigurnosti.

Lekcije za graditelje: Koristite pravi alat za pravi sloj

Iskušenje da se za šifriranje koriste pristupni ključevi dolazi iz dobrog instinkta — programeri žele iskoristiti jaku kriptografiju i smanjiti broj tajni kojima korisnici moraju upravljati. Ali sigurnosno inženjerstvo je u osnovi korištenje pravih primitiva na pravom sloju. I brava i sef štite dragocjenosti, ali ne biste ugradili zasun u trezor ili pokušali nositi sef u džepu.

Zaporke su izvrsne u svojoj namjeni. Smanjili su preuzimanja računa povezana s krađom identiteta do 99,9% u Googleovoj internoj implementaciji. Oni u potpunosti eliminiraju napade namještanja vjerodajnica. Oni pružaju iskustvo prijave koje je istovremeno sigurnije i praktičnije od lozinki. To je izvanredno postignuće i dovoljno je. Tražiti pristupne ključeve za rješavanje enkripcije je kao tražiti od vašeg vatrozida da služi i kao vaš rezervni sustav — on pogrešno razumije arhitekturu.

Pri izgradnji platformi koje upravljaju osjetljivim poslovnim operacijama, arhitektura bi trebala odražavati jasne granice. Autentifikacijom se potvrđuje identitet. Autorizacija određuje pristup. Enkripcija štiti podatke u mirovanju i prijenosu. Upravljanje ključem osigurava da ključevi enkripcije prežive gubitak uređaja, promjenu zaposlenika i promjene infrastrukture. Svaki sloj ima namjenski izrađene alate, a njihovo miješanje stvara krhkost koja izlazi na površinu u najgorim mogućim trenucima — kada korisnik najviše treba pristupiti svojim podacima, a ne može.

Prava sigurnost bez prekomjernog kompliciranja

Za većinu SaaS aplikacija i poslovnih platformi, praktična preporuka je jednostavna: entuzijastično usvojite pristupne ključeve za provjeru autentičnosti i upravljajte enkripcijom u potpunosti na strani poslužitelja s upravljanim KMS-om. To daje vašim korisnicima najbolje iskustvo prijave koje je danas dostupno, a istovremeno štiti njihove podatke infrastrukturom dizajniranom posebno za trajnost i oporavak.

Ako vaš model prijetnje uistinu zahtijeva end-to-end enkripciju gdje poslužitelj ne može pristupiti otvorenim tekstualnim podacima, uložite u odgovarajuću arhitekturu šifriranja na strani klijenta s ključevima izvedenim iz lozinke, kodovima za oporavak i deponiranim organizacijskim ključem — a ne prečacima izvedenim iz zaporke. Ulaganje u inženjering je veće, ali alternativa je isporuka sustava koji će na kraju nepovratno uništiti nečije podatke.

Odluke o sigurnosti s vremenom se povećavaju. Prečac koji se danas koristi postaje noćna mora migracije za tri godine kada se osnovni primitiv promijeni, ekosustav uređaja promijeni svoju politiku sinkronizacije ili preglednik obustavi proširenje. Izgradnja na pravim apstrakcijama od samog početka — autentifikacija kao autentifikacija, enkripcija kao enkripcija, svaka sa svojim životnim ciklusom ključa — temelj je koji platformama omogućuje skaliranje na stotine tisuća korisnika bez tempirane bombe zakopane u kriptografskom sistemu.

Često postavljana pitanja

Zašto se zaporke ne mogu koristiti za šifriranje korisničkih podataka?

Zaporke su dizajnirane isključivo za provjeru autentičnosti, a ne za šifriranje. Oslanjaju se na kriptografiju s javnim ključem za provjeru vašeg identiteta tijekom prijave, ali privatni ključ nikada ne napušta vaš uređaj i nije dostupan aplikacijama. Enkripcija zahtijeva stabilne, ponovljive ključeve koji mogu dosljedno dešifrirati podatke tijekom vremena. Zaporke nemaju tu mogućnost po dizajnu, što ih čini u osnovi neprikladnima za zaštitu pohranjenih korisničkih podataka.

Što će se dogoditi ako svejedno pokušate šifrirati podatke šiframa?

Riskujete izgradnju osjetljivog sustava u kojem korisnici trajno ostaju bez pristupa vlastitim podacima. Zaporke se mogu opozvati, rotirati ili zamijeniti na svim uređajima bez upozorenja. Ako su šifrirani podaci vezani uz određeni pristupni ključ koji se briše ili ažurira, ne postoji put oporavka. To stvara katastrofalan scenarij gubitka podataka koji nikakvo inženjersko rješenje ne može pouzdano spriječiti.

Što bi programeri trebali koristiti umjesto ključeva za šifriranje podataka?

Programeri bi trebali koristiti namjenska rješenja za šifriranje kao što je AES-256 s pravilnim upravljanjem ključem, enkripcijom omotnice ili uspostavljenim bibliotekama kao što je libsodium. Zadržite autentifikaciju i enkripciju kao zasebne brige. Upotrijebite zaporke za ono u čemu se ističu — prijava bez lozinke — i namjenske ključeve za šifriranje kojima se upravlja putem sigurnih sustava za izvođenje ključeva i pohranjivanje radi zaštite osjetljivih korisničkih podataka.

Kako Mewayz upravlja autentifikacijom i sigurnošću podataka za tvrtke?

Mewayz pruža poslovni OS od 207 modula počevši od 19 USD mjesečno koji odvaja autentifikaciju od zaštite podataka korištenjem najboljih praksi u industriji. Umjesto zlouporabe zaporki, platforma na app.mewayz.com implementira odgovarajuće slojeve šifriranja uz sigurne tijekove prijave, osiguravajući da tvrtke mogu pouzdano zaštititi korisničke podatke bez rizika od scenarija zaključavanja koji proizlaze iz spajanja autentifikacije s enkripcijom.