Ikke bruk passord for å kryptere brukerdata

Passnøkler er den mest spennende autentiseringsutviklingen på mange år. De eliminerer phishing, fjerner byrden med passord og leverer en sømløs påloggingsopplevelse støttet av offentlig nøkkelkryptering. Men en farlig misforståelse sprer seg gjennom utviklermiljøer: hvis passord er kryptografiske, kan de sikkert også kryptere brukerdata. De kan ikke - og forsøk på å bruke dem på den måten vil skape sprø, upålitelige systemer som kan låse brukerne dine ute fra deres egen informasjon permanent. Forstå hvorfor krever en klar titt på hva passord faktisk er, hva kryptering krever, og hvor de to divergerer på måter som betyr enormt for enhver plattform som håndterer sensitive forretningsdata.

Autentisering og kryptering er grunnleggende forskjellige jobber

Autentisering svarer på ett spørsmål: "Er du den du utgir deg for å være?" Kryptering svarer på en helt annen: "Kan disse dataene forbli uleselige for alle unntatt autoriserte parter?" Disse to problemene deler kryptografiske primitiver, men ingeniørkravene divergerer kraftig. Autentisering må skje én gang per økt, kan tolerere sporadisk feil med grasiøse fallbacks, og trenger ikke produsere samme utdata hver gang. Kryptering krever deterministisk, reproduserbar nøkkeltilgang over hele levetiden til dataene – som kan være år eller tiår.

Når du autentiserer med en passord, genererer enheten din en kryptografisk signatur som beviser at du har den private nøkkelen knyttet til kontoen din. Serveren bekrefter denne signaturen og gir tilgang. Ikke på noe tidspunkt får serveren – eller til og med applikasjonen din – tilgang til det private nøkkelmaterialet selv. Dette er en funksjon, ikke en begrensning. Hele sikkerhetsmodellen med passord er avhengig av at den private nøkkelen aldri forlater den sikre enklaven på enheten din. Men kryptering krever at du bruker en nøkkel for å transformere data, og senere bruker den samme nøkkelen (eller dens motpart) for å reversere transformasjonen. Hvis du ikke har pålitelig tilgang til nøkkelen, kan du ikke dekryptere pålitelig.

Plattformer som Mewayz som administrerer sensitiv forretningsinformasjon – fakturaer, lønnsposter, CRM-kontakter, HR-dokumenter på tvers av 207 moduler – trenger krypteringsstrategier bygget på nøkler som er holdbare, gjenvinnbare og konsekvent tilgjengelige. Å bygge det på et fundament designet spesielt for å hindre nøkkeltilgang er en arkitektonisk motsetning.

Hvorfor adgangsnøkler motstår å bli brukt som krypteringsnøkler

WebAuthn-spesifikasjonen, som underbygger adgangsnøkler, ble bevisst utformet med begrensninger som gjør bruk av kryptering upraktisk. Å forstå disse begrensningene avslører hvorfor dette ikke er et gap som smart ingeniørkunst kan bygge bro over – det er en grunnleggende designgrense.

Ingen nøkkeleksport: Private nøkler generert under registrering av passord lagres i maskinvarestøttede sikre enklaver (TPM, Secure Enclave eller tilsvarende). Operativsystemet og nettleser-API-ene gir ingen mekanisme for å trekke ut rånøkkelmateriale. Du kan be nøkkelen signere noe, men du kan ikke lese selve nøkkelen.

Ikke-deterministisk nøkkelgenerering: Å lage en passordnøkkel for samme bruker på en annen enhet produserer et helt annet nøkkelpar. Det er ingen startfrase, ingen avledningsbane, ingen måte å rekonstruere den samme nøkkelen på en annen enhet. Hver registrering er kryptografisk uavhengig.

Enhetsbundet tilgjengelighet: Selv med synkronisering av passord (iCloud Keychain, Google Password Manager), avhenger tilgjengeligheten av økosystemdeltakelse. En bruker som registrerer seg på en iPhone og senere bytter til Android kan miste tilgangen. En bruker hvis enhet er mistet, stjålet eller tilbakestilt til fabrikk, står overfor det samme problemet.

Bare utfordring-svar: WebAuthn API avslører navigator.credentials.get() som returnerer en signert påstand, ikke rånøkkelmateriale. Du mottar en signatur over en serverlevert utfordring – nyttig for å bevise identitet, ubrukelig for å utlede en krypteringsnøkkel.

Ingen algoritmefleksibilitet: Passnøkler bruker vanligvis ECDSA med P-256-kurven. Selv om du kunne få tilgang til nøkkelen, er ECDSA en signeringsalgor

Frequently Asked Questions

Why can't passkeys be used to encrypt user data?

Passkeys are designed exclusively for authentication, not encryption. They rely on public-key cryptography to verify your identity during login, but the private key never leaves your device and isn't accessible to applications. Encryption requires stable, reproducible keys that can consistently decrypt data over time. Passkeys lack this capability by design, making them fundamentally unsuitable for protecting stored user information.

What happens if you try to encrypt data with passkeys anyway?

You risk building a brittle system where users get permanently locked out of their own data. Passkeys can be revoked, rotated, or replaced across devices without warning. If encrypted data is tied to a specific passkey that gets deleted or updated, there is no recovery path. This creates a catastrophic data-loss scenario that no amount of engineering workaround can reliably prevent.

What should developers use instead of passkeys for data encryption?

Developers should use purpose-built encryption solutions such as AES-256 with proper key management, envelope encryption, or established libraries like libsodium. Keep authentication and encryption as separate concerns. Use passkeys for what they excel at — passwordless login — and dedicated encryption keys managed through secure key derivation and storage systems for protecting sensitive user data.

How does Mewayz handle authentication and data security for businesses?

Mewayz provides a 207-module business OS starting at $19/mo that separates authentication from data protection using industry best practices. Rather than misusing passkeys, the platform at app.mewayz.com implements proper encryption layers alongside secure login flows, ensuring businesses can protect customer data reliably without risking the lockout scenarios that come from conflating authentication with encryption.

Related Posts

• Vis HN: Musikalsk Intervalltrener
• Balansering av bussholdeplasser er rask, billig og effektiv
• Vis HN: CodeRLM – Tree-sitter-støttet kodeindeksering for LLM-agenter
• Eksponeringssimulator