Ne uporabljajte gesel za šifriranje uporabniških podatkov

Gesla so najbolj razburljiv razvoj preverjanja pristnosti v zadnjih letih. Odpravljajo lažno predstavljanje, odstranijo breme gesel in zagotavljajo brezhibno izkušnjo prijave, podprto s kriptografijo z javnimi ključi. Toda v skupnostih razvijalcev se širi nevarna napačna predstava: če so gesla kriptografska, lahko zagotovo šifrirajo tudi uporabniške podatke. Ne morejo - in poskus njihove uporabe na ta način bo ustvaril krhke, nezanesljive sisteme, ki bi lahko vašim uporabnikom trajno onemogočili dostop do njihovih lastnih informacij. Razumevanje, zakaj, zahteva jasen pogled na to, kaj so v resnici gesla, kaj zahteva šifriranje in kje se to dvoje razlikuje na načine, ki so izjemno pomembni za katero koli platformo, ki obravnava občutljive poslovne podatke.

Preverjanje pristnosti in šifriranje sta bistveno različni opravili

Preverjanje pristnosti odgovori na eno vprašanje: "Ali ste tisti, za katerega se predstavljate?" Šifriranje odgovarja na povsem drugačno vprašanje: "Ali lahko ti podatki ostanejo neberljivi vsem, razen pooblaščenim osebam?" Ti dve težavi imata skupne kriptografske primitive, vendar se inženirske zahteve močno razlikujejo. Preverjanje pristnosti se mora izvesti enkrat na sejo, lahko dopušča občasne napake z elegantnimi nadomestnimi nastavitvami in ni treba vsakič proizvesti enakega rezultata. Šifriranje zahteva determinističen, ponovljiv dostop do ključa skozi celotno življenjsko dobo podatkov – kar lahko traja leta ali desetletja.

Ko preverite pristnost z geslom, vaša naprava ustvari kriptografski podpis, ki dokazuje, da imate zasebni ključ, povezan z vašim računom. Strežnik preveri ta podpis in odobri dostop. Strežnik – ali celo vaša aplikacija – na nobeni točki ne dobi dostopa do samega materiala zasebnega ključa. To je funkcija in ne omejitev. Celoten varnostni model gesel je odvisen od tega, da zasebni ključ nikoli ne zapusti varne enklave vaše naprave. Toda šifriranje zahteva, da uporabite ključ za preoblikovanje podatkov in pozneje uporabite ta isti ključ (ali njegov dvojnik) za obračanje preoblikovanja. Če ne morete zanesljivo dostopati do ključa, ne morete zanesljivo dešifrirati.

Platforme, kot je Mewayz, ki upravljajo občutljive poslovne informacije – račune, evidence plač, stike CRM, dokumente HR v 207 modulih – potrebujejo šifrirne strategije, zgrajene na ključih, ki so trajni, jih je mogoče obnoviti in dosledno dostopni. Graditi to na temelju, zasnovanem posebej za preprečevanje dostopa ključev, je arhitekturno protislovje.

Zakaj se gesla ne uporabljajo kot šifrirni ključi

Specifikacija WebAuthn, ki podpira ključe, je bila namerno zasnovana z omejitvami, zaradi katerih je uporaba šifriranja nepraktična. Razumevanje teh omejitev razkriva, zakaj to ni vrzel, ki bi jo lahko premostil pameten inženiring – to je temeljna meja oblikovanja.

• Brez izvoza ključev: Zasebni ključi, ustvarjeni med registracijo gesla, so shranjeni v varnih enklavah, podprtih s strojno opremo (TPM, Secure Enclave ali enakovredno). API-ji operacijskega sistema in brskalnika ne zagotavljajo nobenega mehanizma za pridobivanje surovega ključnega materiala. Od ključa lahko zahtevate, da nekaj podpiše, ne morete pa prebrati samega ključa.
• Nedeterministična generacija ključev: Ustvarjanje gesla za istega uporabnika v drugi napravi povzroči popolnoma drugačen par ključev. Ni semenske fraze, ni poti izpeljave, ni načina za rekonstrukcijo istega ključa na drugi napravi. Vsaka registracija je kriptografsko neodvisna.
• Razpoložljivost glede na napravo: Tudi pri sinhronizaciji gesel (iCloud Keychain, Google Password Manager) je razpoložljivost odvisna od sodelovanja v ekosistemu. Uporabnik, ki se registrira na iPhone in kasneje preklopi na Android, lahko izgubi dostop. Uporabnik, katerega naprava je izgubljena, ukradena ali ponastavljena na tovarniške nastavitve, se sooča z isto težavo.
• Samo odziv na izziv: API WebAuthn razkrije navigator.credentials.get(), ki vrne podpisano trditev, ne surovega ključa. Prejmete podpis prek izziva, ki ga zagotovi strežnik – uporaben za dokazovanje identitete, neuporaben za pridobivanje šifrirnega ključa.
• Brez prilagodljivosti algoritma: Gesla običajno uporabljajo ECDSA s krivuljo P-256. Tudi če bi lahko dostopali do ključa, je ECDSA algoritem za podpisovanje in ne algoritem za šifriranje. Potrebovali bi dodatne transformacije (pogodba o ključu ECDH, izpeljava KDF), ki jih API v tem kontekstu ne podpira.

Nekateri razvijalci so predlagali rešitve — z uporabo razširitve PRF (Pseudo-Random Function) za WebAuthn, na primer za pridobivanje simetričnih ključev med preverjanjem pristnosti. Čeprav ta razširitev obstaja v specifikaciji, podpora za brskalnik ostaja nedosledna, ni na voljo na številnih mobilnih platformah in še vedno podeduje težavo vezave na napravo. Ključa, pridobljenega prek PRF v eni napravi, ni mogoče reproducirati v drugi napravi z drugačnim geslom, tudi za isti uporabniški račun.

Scenarij izgube podatkov, ki jih nihče ne želi poslati

Razmislite, kaj se zgodi, ko šifrirate uporabnikove podatke s ključem, ki izhaja iz njihovega gesla. Prvi dan vse deluje čudovito. Uporabnik se prijavi, ključ se izpelje, podatki se brezhibno šifrirajo in dešifrirajo. Nato tri mesece pozneje njun telefon pade v jezero.

Pri tradicionalnem preverjanju pristnosti je izguba naprave nevšečnost. Uporabnik obnovi svoj račun prek e-pošte, nastavi nove poverilnice in nadaljuje z delom. Toda če so bili njihovi podatki šifrirani s ključem, vezanim na varno enklavo zdaj potopljene naprave, teh podatkov ni več. Ni "težko obnoviti" več - kriptografsko nepovratno ni več. Nobena prijava za podporo strankam, noben tok obnovitve računa, nobena izvršna eskalacija ne more obrniti matematike. Podatki so lahko tudi izbrisani.

Glavno pravilo zasnove šifrirnega sistema: če ima vaša strategija upravljanja ključev katero koli točko napake, ki trajno uniči dostop do uporabniških podatkov, niste zgradili varnostne funkcije – zgradili ste mehanizem za izgubo podatkov z dodatnimi koraki.

Za podjetje, ki deluje prek platforme – upravljanje 50 odnosov s strankami v sistemu CRM, obdelava mesečnih plač za 30 zaposlenih, sledenje voznemu parku – trajna izguba podatkov zaradi padlega telefona ni manjša težava UX. To je katastrofa neprekinjenega poslovanja. To je ravno razlog, zakaj Mewayzova arhitektura ločuje mehanizme za preverjanje pristnosti od plasti zaščite podatkov, kar zagotavlja, da okvara posamezne naprave ne more ogroziti dostopa do kritičnih poslovnih informacij v katerem koli od njegovih integriranih modulov.

Kaj bi morali uporabiti namesto tega

Dobra novica je, da obstajajo dobro uveljavljeni vzorci za šifriranje uporabniških podatkov, ne da bi se ujeli v past gesla. Ti pristopi so preizkušeni v bitkah, široko podprti in zasnovani posebej za primer uporabe šifriranja.

Šifriranje na strani strežnika z upravljanimi ključi ostaja najbolj praktična izbira za veliko večino aplikacij. Vaša platforma šifrira podatke v mirovanju s ključi, ki jih upravlja ustrezna storitev za upravljanje ključev (KMS) – AWS KMS, Google Cloud KMS, HashiCorp Vault ali enakovredno. Uporabnik preveri pristnost (če želite z geslom!), strežnik pa pregledno obravnava šifriranje in dešifriranje. Tako večina platform SaaS ščiti podatke in deluje, ker so ključi trpežni, varnostno kopirani, vrtljivi in neodvisni od uporabnikove naprave.

Ključi za šifriranje, pridobljeni z geslom (z uporabo Argon2id ali scrypt za izpeljavo ključa) so primerni, ko potrebujete resnično šifriranje brez znanja, kjer niti strežnik ne more prebrati uporabniških podatkov. Kompromis je v tem, da izguba gesla pomeni izgubo podatkov, vendar si je mogoče gesla zapomniti, zapisati in shraniti v upraviteljih gesel – niso zaklenjena znotraj enklave strojne opreme. Storitve, kot sta 1Password in Standard Notes, učinkovito uporabljajo ta pristop.

1. Uporabite geslo (ali katero koli močno metodo) za preverjanje pristnosti – preverjanje identitete uporabnika.
2. Po preverjanju pristnosti pridobite ali pridobite šifrirne ključe prek ločenega, namensko izdelanega sistema za upravljanje ključev.
3. Implementirajte mehanizme za hrambo ali obnovitev ključev – obnovitvene ključe, sinhronizacijo ključev v več napravah ali skrbništvo organizacijskih ključev za poslovne račune.
4. Šifrirajte podatke v mirovanju in med prenosom z AES-256-GCM ali XChaCha20-Poly1305 s ključi iz vašega KMS.
5. Občasno menjajte ključe in vzdržujte šifrirane varnostne kopije ključev, ki preživijo vsako posamezno točko okvare.

Ta ločitev pomislekov ni samo najboljša praksa – je edina arhitektura, ki vam omogoča nadgradnjo metod preverjanja pristnosti neodvisno od vaše strategije šifriranja. Ko se gesla sčasoma razvijejo ali jih nadomesti nekaj boljšega, vaši šifrirani podatki ostanejo popolnoma dostopni.

Razširitev PRF: obljube in pasti

Razvijalci, ki natančno sledijo specifikaciji WebAuthn, lahko na razširitev prf opozarjajo kot na potencialni most med gesli in šifriranjem. Ta razširitev omogoča stranki, ki se zanaša, da zahteva psevdo-naključno vrednost, izpeljano iz tajnega materiala gesla med obredom preverjanja pristnosti. Teoretično bi lahko ta vrednost služila kot šifrirni ključ ali seme.

V praksi se razširitev PRF sooča s precejšnjimi ovirami pri sprejemanju. Od začetka leta 2026 se podpora močno razlikuje med brskalniki in platformami. Izvedba Safarija se razlikuje od Chroma. Številne naprave Android tega sploh ne podpirajo. Varnostni ključi strojne opreme imajo nedosledno podporo. Za katero koli platformo, ki služi raznoliki bazi uporabnikov – in Mewayz služi več kot 138.000 uporabnikom v vseh večjih operacijskih sistemih in vrstah naprav – je izgradnja šifriranja na funkciji z neenakomerno razpoložljivostjo operativno nevzdržna.

Še bolj temeljno, PRF ne reši težave z več napravami. Psevdonaključni izhod izhaja iz določenega gesla na določeni napravi. Uporabnik, ki registrira geslo na svojem prenosniku in telefonu, dobi dva različna izhoda PRF za isti račun. Podatke bi morali šifrirati z izpeljanim ključem ene naprave in nato nekako znova šifrirati ali ta ključ dati v skupno rabo z drugo napravo – kar vas tako ali tako pripelje nazaj k izgradnji ustreznega sistema za upravljanje ključev. Na tej točki ključ, izpeljan iz gesla, doda zapletenost brez dodatne varnosti.

Lekcije za gradbenike: Uporabite pravo orodje za pravo plast

Skušnjava, da bi za šifriranje uporabili ključe, izvira iz dobrega instinkta – razvijalci želijo izkoristiti močno kriptografijo in zmanjšati število skrivnosti, ki jih morajo upravljati uporabniki. Toda varnostni inženiring je v bistvu uporaba prave primitive na pravi ravni. Ključavnica in sef varujeta dragocenosti, vendar ne bi namestili zapaha v trezor ali poskušali nositi sefa v žepu.

Gesla se odlikujejo po svojem namenu. V Googlovi interni uvedbi so zmanjšali prevzeme računov, povezane z lažnim predstavljanjem, za do 99,9 %. Popolnoma odpravijo napade s polnjenjem poverilnic. Zagotavljajo izkušnjo prijave, ki je hkrati varnejša in priročnejša od gesel. To je izjemen dosežek in dovolj. Zahtevati, da ključa tudi rešijo šifriranje, je tako, kot bi zahtevali, da vaš požarni zid služi tudi kot vaš rezervni sistem - narobe razume arhitekturo.

Pri gradnji platform, ki obravnavajo občutljive poslovne operacije, mora arhitektura odražati jasne meje. Avtentikacija preverja identiteto. Avtorizacija določa dostop. Šifriranje ščiti podatke med mirovanjem in med prenosom. Upravljanje ključev zagotavlja, da šifrirni ključi preživijo izgubo naprave, menjavo zaposlenih in spremembe infrastrukture. Vsaka plast ima namensko izdelana orodja in njihovo mešanje ustvari krhkost, ki se pojavi v najslabših možnih trenutkih – ko uporabnik najbolj potrebuje dostop do svojih podatkov, a ne more.

Ustrezna varnost brez pretiranega kompliciranja

Za večino aplikacij SaaS in poslovnih platform je praktično priporočilo preprosto: z navdušenjem sprejmete gesla za preverjanje pristnosti in obravnavate šifriranje v celoti na strani strežnika z upravljanim KMS. To vašim uporabnikom omogoča najboljšo izkušnjo prijave, ki je danes na voljo, hkrati pa njihove podatke ščiti z infrastrukturo, zasnovano posebej za vzdržljivost in obnovitev.

Če vaš model groženj resnično zahteva šifriranje od konca do konca, kjer strežnik ne more dostopati do podatkov z navadnim besedilom, investirajte v ustrezno arhitekturo šifriranja na strani odjemalca s ključi, ki izhajajo iz gesel, obnovitvenimi kodami in deponiranjem organizacijskih ključev – ne bližnjic, ki izhajajo iz gesla. Investicija v inženiring je večja, vendar je alternativa pošiljanje sistema, ki bo sčasoma nepopravljivo uničil podatke nekoga.

Varnostne odločitve se sčasoma povečujejo. Bližnjica, uporabljena danes, čez tri leta postane nočna mora pri selitvi, ko se osnovni element spremeni, ekosistem naprave spremeni svojo politiko sinhronizacije ali brskalnik opusti razširitev. Graditi na pravih abstrakcijah že od samega začetka – avtentikacija kot avtentikacija, šifriranje kot šifriranje, vsako s svojim lastnim življenjskim ciklom ključa – je temelj, ki platformam omogoča, da se razširijo na stotine tisoč uporabnikov brez tiktakajoče tempirane bombe, zakopane v kriptografskem sistemu.

Pogosto zastavljena vprašanja

Zakaj gesla ni mogoče uporabiti za šifriranje uporabniških podatkov?

Gesla so zasnovana izključno za preverjanje pristnosti, ne za šifriranje. Za preverjanje vaše identitete med prijavo se zanašajo na kriptografijo z javnim ključem, vendar zasebni ključ nikoli ne zapusti vaše naprave in ni dostopen aplikacijam. Šifriranje zahteva stabilne, ponovljive ključe, ki lahko skozi čas dosledno dešifrirajo podatke. Gesla že po zasnovi nimajo te zmožnosti, zaradi česar so načeloma neprimerna za zaščito shranjenih uporabniških podatkov.

Kaj se zgodi, če vseeno poskusite šifrirati podatke z geslom?

Tvegate zgraditi krhek sistem, v katerem uporabniki trajno izgubijo dostop do svojih podatkov. Gesla je mogoče preklicati, zamenjati ali zamenjati med napravami brez opozorila. Če so šifrirani podatki vezani na določeno geslo, ki se izbriše ali posodobi, ni obnovitvene poti. To ustvari scenarij katastrofalne izgube podatkov, ki ga nobena inženirska rešitev ne more zanesljivo preprečiti.

Kaj naj razvijalci uporabljajo namesto gesel za šifriranje podatkov?

Razvijalci bi morali uporabljati namenske rešitve za šifriranje, kot je AES-256, z ustreznim upravljanjem ključev, šifriranjem ovojnice ali uveljavljene knjižnice, kot je libsodium. Preverjanje pristnosti in šifriranje naj bosta ločeni. Uporabite gesla za tisto, v čemer blestijo – prijavo brez gesla – in namenske šifrirne ključe, ki jih upravljate prek varnih sistemov za izpeljavo ključev in shranjevanje za zaščito občutljivih uporabniških podatkov.

Kako Mewayz obravnava avtentikacijo in varnost podatkov za podjetja?

Mewayz ponuja 207-modulni poslovni OS od 19 $/mesec, ki ločuje preverjanje pristnosti od zaščite podatkov z uporabo najboljših praks v industriji. Namesto zlorabe gesel platforma na app.mewayz.com izvaja ustrezne šifrirne plasti poleg varnih prijavnih tokov, s čimer podjetjem zagotavlja, da lahko zanesljivo zaščitijo podatke o strankah, ne da bi tvegali scenarije zaklepanja, ki izhajajo iz mešanja avtentikacije s šifriranjem.