Nenaudokite prieigos raktų vartotojo duomenims užšifruoti

Slaptažodžiai yra įdomiausi autentifikavimo plėtra per daugelį metų. Jie pašalina sukčiavimą, pašalina slaptažodžių naštą ir užtikrina sklandų prisijungimą, paremtą viešojo rakto kriptografija. Tačiau kūrėjų bendruomenėse plinta pavojinga klaidinga nuomonė: jei prieigos raktai yra kriptografiniai, jie tikrai gali užšifruoti ir vartotojo duomenis. Jie negali – ir bandydami jas naudoti tokiu būdu sukurs trapias, nepatikimas sistemas, kurios gali visam laikui užblokuoti naudotojus nuo savo informacijos. Norint suprasti, kodėl, reikia aiškiai pažvelgti į tai, kas iš tikrųjų yra slaptažodžiai, kokie yra šifravimo reikalavimai ir kur jie skiriasi, o tai labai svarbu bet kuriai neskelbtinus verslo duomenis tvarkančiai platformai.

Autentifikavimas ir šifravimas yra iš esmės skirtingi darbai

Autentifikavimas atsako į vieną klausimą: „Ar jūs esate tas, kuo tvirtinate? Šifravimas atsako visiškai kitaip: "Ar šie duomenys gali likti neįskaitomi visiems, išskyrus įgaliotas šalis?" Šios dvi problemos turi bendrų kriptografinių primityvų, tačiau inžineriniai reikalavimai labai skiriasi. Autentifikavimas turi įvykti vieną kartą per seansą, gali toleruoti retkarčiais gedimus su grakščiais atsarginiais veiksmais ir nereikia kiekvieną kartą pateikti tos pačios išvesties. Šifravimui reikalinga deterministinė, atkuriama prieiga prie rakto per visą duomenų naudojimo laiką – tai gali būti metai ar dešimtmečiai.

Kai autentifikuojate naudodami prieigos raktą, įrenginys sugeneruoja kriptografinį parašą, įrodantį, kad turite su paskyra susietą privatų raktą. Serveris patikrina šį parašą ir suteikia prieigą. Serveris ar net jūsų programa niekada negauna prieigos prie privataus rakto medžiagos. Tai yra funkcija, o ne apribojimas. Visas slaptažodžių saugos modelis priklauso nuo privataus rakto, kuris niekada nepalieka saugaus jūsų įrenginio anklavo. Tačiau norint šifruoti, reikia naudoti raktą duomenims transformuoti, o vėliau naudoti tą patį raktą (arba jo atitikmenį), kad pakeistumėte pakeitimą. Jei negalite patikimai pasiekti rakto, negalite patikimai iššifruoti.

Platformoms, tokioms kaip „Mewayz“, kurios tvarko neskelbtiną verslo informaciją – sąskaitas faktūras, darbo užmokesčio įrašus, CRM kontaktus, HR dokumentus 207 moduliuose – reikia šifravimo strategijų, pagrįstų raktais, kurie yra patvarūs, atkuriami ir nuosekliai pasiekiami. Pastatyti tai ant pagrindo, specialiai sukurto taip, kad būtų išvengta prieigos prie raktų, yra architektūrinis prieštaravimas.

Kodėl slaptažodžiai negali būti naudojami kaip šifravimo raktai

„WebAuthn“ specifikacija, kuria grindžiami prieigos raktai, buvo sąmoningai sukurta su apribojimais, dėl kurių šifravimas tampa nepraktiškas. Šių apribojimų supratimas atskleidžia, kodėl tai nėra spraga, kurią sumani inžinerija gali įveikti – tai pagrindinė dizaino riba.

• Neeksportuojamas raktas: privatūs raktai, sukurti registruojant slaptažodį, saugomi aparatinės įrangos saugiuose anklavuose (TPM, Secure Enclave arba lygiaverčiai). Operacinė sistema ir naršyklės API nesuteikia jokio mechanizmo, kaip išgauti žaliavinę rakto medžiagą. Galite paprašyti rakto ką nors pasirašyti, bet negalite perskaityti paties rakto.
• Nedeterministinis raktų generavimas: sukūrus slaptažodžio raktą tam pačiam vartotojui kitame įrenginyje sukuriama visiškai skirtinga raktų pora. Nėra pradinės frazės, jokio išvedimo kelio ar būdo atkurti tą patį raktą kitame įrenginyje. Kiekviena registracija yra kriptografiškai nepriklausoma.
• Prieiga prie įrenginio: net naudojant slaptažodžio sinchronizavimą („iCloud Keychain“, „Google Password Manager“), pasiekiamumas priklauso nuo ekosistemos dalyvavimo. Naudotojas, užsiregistravęs „iPhone“ ir vėliau persijungęs į „Android“, gali prarasti prieigą. Naudotojas, kurio įrenginys buvo pamestas, pavogtas arba atkurtas gamykloje, susiduria su ta pačia problema.
• Tik atsakymas į iššūkius: „WebAuthn“ API atskleidžia navigator.credentials.get(), kuri pateikia pasirašytą tvirtinimą, o ne neapdorotą rakto medžiagą. Gaunate parašą per serverio pateiktą iššūkį – tai naudinga tapatybei įrodyti, nenaudinga šifravimo raktui gauti.
• Jokio algoritmo lankstumo: slaptažodžiuose paprastai naudojama ECDSA su P-256 kreive. Net jei galėtumėte pasiekti raktą, ECDSA yra pasirašymo, o ne šifravimo algoritmas. Jums reikės papildomų transformacijų (ECDH rakto sutarties, KDF išvedimo), kurių API nepalaiko šiame kontekste.

Kai kurie kūrėjai pasiūlė problemų sprendimo būdus – pavyzdžiui, naudojant PRF (pseudo-Random Function) plėtinį WebAuthn, kad autentifikavimo metu būtų gauti simetriški raktai. Nors šis plėtinys yra specifikacijoje, naršyklės palaikymas išlieka nenuoseklus, jis nepasiekiamas daugelyje mobiliųjų platformų ir vis tiek paveldi įrenginio surišimo problemą. Raktas, gautas naudojant PRF viename įrenginyje, negali būti atkurtas kitame įrenginyje su kitu slaptažodžiu, net ir naudojant tą pačią vartotojo paskyrą.

Duomenų praradimo scenarijus, kurio niekas nenori siųsti

Apsvarstykite, kas nutinka, kai užšifruojate vartotojo duomenis raktu, gautu iš jo prieigos rakto. Pirmą dieną viskas veikia gražiai. Vartotojas prisijungia, išvedamas raktas, sklandžiai užšifruojami ir iššifruojami duomenys. Tada po trijų mėnesių jų telefonas įkrenta į ežerą.

Taikant tradicinį autentifikavimą, įrenginio praradimas yra nepatogumas. Vartotojas atkuria savo paskyrą el. paštu, nustato naujus kredencialus ir toliau dirba. Bet jei jų duomenys buvo užšifruoti raktu, susietu su dabar panardinto įrenginio saugiu anklavu, tų duomenų nebėra. Dingo ne „sunku susigrąžinti“ – kriptografiškai negrįžtama. Joks klientų aptarnavimo bilietas, paskyros atkūrimo srautas, joks vadovų eskalavimas negali pakeisti matematikos. Duomenys taip pat galėjo būti ištrinti.

Pagrindinė šifravimo sistemos dizaino taisyklė: jei jūsų raktų valdymo strategija turi vieną gedimo tašką, dėl kurio visam laikui sunaikinama prieiga prie naudotojo duomenų, nesukūrėte saugos funkcijos – sukūrėte duomenų praradimo mechanizmą su papildomais veiksmais.

Verslui, kuris vykdo operacijas per platformą – tvarko 50 santykių su klientais CRM, apdoroja mėnesinį atlyginimą 30 darbuotojų, stebi transporto priemonių parką – nuolatinis duomenų praradimas nukritus telefonui nėra maža UX problema. Tai verslo tęstinumo katastrofa. Būtent todėl „Mewayz“ architektūra atskiria autentifikavimo mechanizmus nuo duomenų apsaugos sluoksnių, užtikrindama, kad joks įrenginio gedimas negalėtų pakenkti prieigai prie svarbios verslo informacijos visuose integruotuose moduliuose.

Ką turėtumėte naudoti vietoj to

Geros naujienos yra tai, kad egzistuoja nusistovėję naudotojų duomenų šifravimo modeliai nepatenkant į slaptažodžio spąstus. Šie metodai yra išbandyti, plačiai palaikomi ir sukurti specialiai šifravimo atveju.

Serverio pusės šifravimas naudojant valdomus raktus išlieka praktiškiausias pasirinkimas daugeliui programų. Jūsų platforma šifruoja nenaudojamus duomenis naudodama raktus, tvarkomus naudojant tinkamą raktų valdymo paslaugą (KMS) – AWS KMS, Google Cloud KMS, HashiCorp Vault ar lygiavertį. Vartotojas autentifikuojasi (jei norite su slaptažodžiais!), o serveris skaidriai tvarko šifravimą ir iššifravimą. Taip dauguma SaaS platformų apsaugo duomenis ir tai veikia, nes raktai yra patvarūs, jų atsarginės kopijos, pasukami ir nepriklauso nuo jokio vartotojo įrenginio.

Iš slaptažodžio gaunami šifravimo raktai (naudojant Argon2id arba scrypt raktams išvesti) tinka, kai reikia tikro nulio žinių šifravimo, kai net serveris negali nuskaityti vartotojo duomenų. Kompromisas yra tas, kad slaptažodžio praradimas reiškia duomenų praradimą, tačiau slaptažodžius galima įsiminti, užrašyti ir saugoti slaptažodžių tvarkytuvėse – jie nėra užrakinti aparatūros anklave. Tokios paslaugos kaip 1Password ir Standard Notes efektyviai naudoja šį metodą.

1. Naudokite prieigos raktus (arba bet kokį patikimą metodą) autentifikavimui – naudotojo tapatybei patvirtinti.
2. Po autentifikavimo išveskite arba nuskaitykite šifravimo raktus naudodami atskirą, specialiai sukurtą raktų valdymo sistemą.
3. Įdiekite raktų sąlyginio deponavimo arba atkūrimo mechanizmus – atkūrimo raktus, kelių įrenginių raktų sinchronizavimą arba organizacijos raktų saugojimą verslo paskyroms.
4. Šifruokite duomenis ramybės būsenoje ir perduodami naudodami AES-256-GCM arba XChaCha20-Poly1305 su raktais iš jūsų KMS.
5. Periodiškai kaitaliokite raktus ir kurkite šifruotų raktų atsargines kopijas, kurios išliks bet kuriuo gedimo momentu.

Šis problemų atskyrimas nėra tik geriausia praktika – tai vienintelė architektūra, leidžianti atnaujinti autentifikavimo metodus neatsižvelgiant į šifravimo strategiją. Kai slaptažodžiai galiausiai išsivysto arba pakeičiami kažkuo geresniu, jūsų užšifruoti duomenys lieka puikiai pasiekiami.

PRF plėtinys: pažadai ir spąstai

Kūrėjai, atidžiai besilaikantys WebAuthn specifikacijos, gali nurodyti plėtinį prf kaip galimą tiltą tarp slaptažodžių ir šifravimo. Šis plėtinys leidžia patikimai šaliai per autentifikavimo ceremoniją prašyti pseudoatsitiktinės vertės, gautos iš slaptos rakto medžiagos. Teoriškai ši reikšmė galėtų būti naudojama kaip šifravimo raktas arba pradinė dalis.

Praktiškai PRF plėtinys susiduria su didelėmis priėmimo kliūtimis. Nuo 2026 m. pradžios palaikymas įvairiose naršyklėse ir platformose labai skiriasi. „Safari“ diegimas skiriasi nuo „Chrome“. Daugelis „Android“ įrenginių jo visiškai nepalaiko. Aparatinės įrangos saugos raktai turi nenuoseklų palaikymą. Bet kuriai platformai, kuri aptarnauja įvairią vartotojų bazę, o „Mewayz“ aptarnauja daugiau nei 138 000 naudotojų visose pagrindinėse operacinėse sistemose ir įrenginių tipuose, šifravimo kūrimas naudojant funkciją, kurios pasiekiamumas yra nevienodas, yra netinkamas.

Iš esmės PRF neišsprendžia kelių įrenginių problemos. Pseudoatsitiktinė išvestis gaunama iš konkretaus slaptažodžio konkrečiame įrenginyje. Naudotojas, registruojantis prieigos raktus ir nešiojamajame kompiuteryje, ir telefone, gauna du skirtingus PRF išvestis tai pačiai paskyrai. Turėtumėte užšifruoti duomenis naudojant vieno įrenginio išvestinį raktą, o tada kažkaip iš naujo užšifruoti arba bendrinti tą raktą su kitu įrenginiu – tai bet kuriuo atveju sugrąžins jus prie tinkamos raktų valdymo sistemos kūrimo. Tuo metu iš slaptažodžio gautas raktas padidina sudėtingumą ir nepadidina saugumo.

Pamokos statybininkams: naudokite tinkamą įrankį tinkamam sluoksniui sukurti

Gundą naudoti slaptažodžius šifravimui kyla iš geros nuojautos – kūrėjai nori panaudoti stiprią kriptografiją ir sumažinti paslapčių, kurias naudotojai turi valdyti, skaičių. Tačiau saugumo inžinerija iš esmės yra tinkamo primityvumo naudojimas tinkamame lygmenyje. Spyna ir seifas saugo vertybes, tačiau saugyklos viduje neįtaisysite užrakto ar nebandysite nešiotis seifo kišenėje.

Slaptažodžiai puikiai tinka pagal paskirtį. Jie sumažino su sukčiavimu susijusių paskyrų perėmimą iki 99,9 % vidinėje „Google“ diegimo vietoje. Jie visiškai pašalina kredencialų užpildymo atakas. Jie suteikia prisijungimo patirtį, kuri yra saugesnė ir patogesnė nei slaptažodžiai. Tai puikus pasiekimas, ir to pakanka. Prašyti prieigos raktų, kad būtų išspręstas šifravimas, panašu į tai, kad ugniasienė būtų naudojama kaip atsarginė sistema – ji neteisingai supranta architektūrą.

Kuriant platformas, kuriose atliekamos jautrios verslo operacijos, architektūra turi atspindėti aiškias ribas. Autentifikavimas patvirtina tapatybę. Autorizacija nustato prieigą. Šifravimas apsaugo duomenis ramybės būsenoje ir juos perduodant. Raktų valdymas užtikrina, kad šifravimo raktai išgyventų įrenginio praradimą, darbuotojų kaitą ir infrastruktūros pokyčius. Kiekvienas sluoksnis turi specialiai sukurtus įrankius, o jų maišymas sukuria pažeidžiamumą, kuris išryškėja blogiausiu įmanomu momentu – kai vartotojui labiausiai reikia pasiekti savo duomenis, bet jis negali.

Saugumo užtikrinimas per daug neapsunkinant

Daugumai SaaS programų ir verslo platformų praktinė rekomendacija yra paprasta: entuziastingai naudokite slaptažodžius autentifikavimui ir šifravimą tvarkykite tik serverio pusėje, naudodami valdomą KMS. Tai suteikia vartotojams geriausią šiandien prieinamą prisijungimo patirtį ir apsaugo jų duomenis naudojant infrastruktūrą, sukurtą specialiai patvarumui ir atkūrimui.

Jei jūsų grėsmės modeliui iš tikrųjų reikalingas visiškas šifravimas, kai serveris negali pasiekti paprasto teksto duomenų, investuokite į tinkamą kliento pusės šifravimo architektūrą su slaptažodžiu gautais raktais, atkūrimo kodais ir organizacijos rakto sąlyginio deponavimo priemone, o ne iš slaptažodžio gautų sparčiųjų klavišų. Investicijos į inžineriją yra didesnės, tačiau alternatyva yra pristatyti sistemą, kuri galiausiai sunaikins kažkieno duomenis neatkuriamai.

Saugumo sprendimai ilgainiui sudėtingi. Šiandien pasirinktas spartusis klavišas tampa migracijos košmaru po trejų metų, kai pasikeičia pagrindinis primityvus, įrenginio ekosistema pakeičia sinchronizavimo politiką arba naršyklė nebenaudoja plėtinio. Nuo pat pradžių pagrįstas teisingomis abstrakcijomis – autentifikavimas kaip autentifikavimas, šifravimas kaip šifravimas, kurių kiekvienas turi savo rakto gyvavimo ciklą – yra pagrindas, leidžiantis platformoms pasiekti šimtus tūkstančių vartotojų be tiksinčios bombos, palaidotos kriptografinėje santechnikoje.

Dažniausiai užduodami klausimai

Kodėl slaptažodžių negalima naudoti vartotojo duomenims užšifruoti?

Slaptažodžiai skirti tik autentifikavimui, o ne šifravimui. Jie naudojasi viešojo rakto kriptografija, kad patvirtintų jūsų tapatybę prisijungimo metu, tačiau privatus raktas niekada nepalieka jūsų įrenginio ir nėra pasiekiamas programoms. Šifravimui reikalingi stabilūs, atkuriami raktai, kurie laikui bėgant gali nuosekliai iššifruoti duomenis. Prieigos raktams trūksta šios galimybės, todėl jie iš esmės netinkami saugomai naudotojo informacijai apsaugoti.

Kas atsitiks, jei vis tiek bandysite užšifruoti duomenis naudodami prieigos raktus?

Rizikuojate sukurti trapią sistemą, kurioje naudotojai visam laikui negalės gauti savo duomenų. Prieigos raktai gali būti atšaukti, pasukti arba pakeisti įvairiuose įrenginiuose be įspėjimo. Jei užšifruoti duomenys susieti su konkrečiu slaptažodžiu, kuris ištrinamas arba atnaujinamas, atkūrimo kelio nėra. Taip sukuriamas katastrofiškas duomenų praradimo scenarijus, kurio negali patikimai išvengti joks inžinerinis sprendimas.

Ką kūrėjai turėtų naudoti vietoj prieigos raktų duomenims šifruoti?

Kūrėjai turėtų naudoti specialiai sukurtus šifravimo sprendimus, pvz., AES-256 su tinkamu raktų valdymu, vokų šifravimu arba nusistovėjusiomis bibliotekomis, pvz., libsodium. Autentifikavimą ir šifravimą laikykite atskirais klausimais. Naudokite slaptažodžius tam, kas jiems puikiai tinka – prisijungimui be slaptažodžio – ir specialius šifravimo raktus, valdomus naudojant saugias raktų išvedimo ir saugojimo sistemas, kad apsaugotumėte neskelbtinus vartotojo duomenis.

Kaip „Mewayz“ tvarko įmonių autentifikavimą ir duomenų saugumą?

Mewayz teikia 207 modulių verslo OS, pradedant nuo 19 USD per mėnesį, kuri atskiria autentifikavimą nuo duomenų apsaugos, naudojant geriausią pramonės praktiką. Vietoje app.mewayz.com esanti platforma, užuot piktnaudžiavusi slaptažodžiais, kartu su saugiais prisijungimo srautais įdiegia tinkamus šifravimo sluoksnius, užtikrindama, kad įmonės galėtų patikimai apsaugoti klientų duomenis, nerizikuodami blokavimo scenarijais, atsirandančiais dėl autentifikavimo ir šifravimo supainiojimo.