Videre til indhold 
Passkeys og WebAuthn gør en ende på risikable password-login i hosting og gør angreb på adgangsdata upraktiske. Hvem bruger i dag WebAuthn-hosting reducerer phishing, forhindrer credential stuffing og gør login betydeligt hurtigere.
Centrale punkter
- Beskyttelse mod phishing ved domænebinding
- Uden at delte hemmeligheder
- Passkeys i stedet for adgangskoder
- Hurtigere Login via biometri
- Overensstemmelse bliver nemmere
Hvorfor passkeys og WebAuthn-login nu er nødvendige i hosting
Jeg ser hver dag, hvordan Adgangskoder Hostingkonti udgør en risiko og belaster supportteamene. Phishing-mails, datalækager og genbrug af adgangskoder fører til kontoovertagelser og lange gendannelsesprocesser. Passkeys og WebAuthn løser dette grundlæggende problem, fordi der ikke længere er nogen hemmelig adgangskode på serveren, som angribere kan stjæle. Selv hvis en kriminel kender brugernavnet og værten, kan han ikke komme ind uden den private nøgle på min enhed. Som en overgangsforanstaltning er det værd at se på nyttige Adgangskodepolitik, indtil jeg helt er gået over til passkeys.
Sådan fungerer WebAuthn teknisk – enkelt forklaret
WebAuthn bruger offentlig nøgle-Kryptografi i stedet for adgangskoder. Hosting-serveren sender mig en udfordring, min enhed underskriver den lokalt med den private nøgle og returnerer kun underskriften. Serveren kontrollerer denne underskrift med den offentlige nøgle, som den har gemt ved min registrering. Den private nøgle forbliver altid på min enhed, forlader den aldrig og kan ikke aflyttes. Browsere kontrollerer desuden sidens oprindelse, hvilket blokerer login på falske domæner, så jeg ikke længere logger ind på kopier, der ligner de ægte.
Passkeys i hverdagen: Enheder, synkronisering, nødkoder
En adgangskode er min Registreringsnøgle for et domæne, beskyttet af biometri eller PIN på mine enheder. Jeg kan synkronisere adgangskoder på tværs af enheder, hvilket gør det nemt at logge ind på bærbar computer, smartphone og tablet. Hvis en enhed svigter, kan jeg stadig handle, fordi jeg kan bruge den samme adgangskode på andre enheder eller gemme en hardwarenøgle. I nødstilfælde har jeg gendannelsesmuligheder klar, f.eks. en anden registreret sikkerhedsnøgle. På den måde sikrer jeg, at bekvemmelighed ikke går ud over sikkerheden, og at jeg altid har adgang.
Phishing-modstand og domænebinding
Passkeys er knyttet til Domæne bundet til den side, hvor jeg registrerer den. Jeg kan ikke bruge min adgangskode på en phishing-side, fordi browseren og authenticatoren kontrollerer den ægte oprindelse. Selv perfekt kopierede login-sider fejler automatisk. Angreb, der opfanger adgangsdata, mister deres effekt, fordi der ikke overføres genanvendelige hemmeligheder. Jeg aflaster mig selv og mit team, da jeg ikke længere behøver at kontrollere hver eneste mistænkelig e-mail, før jeg logger ind.
Sikkerhedsarkitektur uden delte hemmeligheder
Når det gælder adgangskoder, ligger Belastning på serveren: hashing, salting, rotation og beskyttelse mod dataudslip. WebAuthn vender op og ned på denne model, da serveren kun gemmer min offentlige nøgle. Et læk giver således angribere intet materiale, som de kan bruge til at forfalske logins. Credential stuffing bliver ineffektivt, da hver adgangskode kun gælder for ét domæne og én konto. Netop denne adskillelse gør host-konti modstandsdygtige over for bredt spredte angreb.
| Kriterium | Adgangskoder | WebAuthn/Passkoder |
|---|---|---|
| Hemmelighed på serveren | Ja (Hashes) | Nej (kun offentlig nøgle) |
| Modstandsdygtighed over for phishing | Lav | Høj (Domænebinding) |
| Genbrug | Ofte | Umuligt (omfattet) |
| brugervenlighed | Lav (Mærk, tryk) | Høj (Biometri/PIN) |
| Supportomkostninger | Høj (Nulstil) | Lav (Recovery-Flow) |
Passwordless hosting i praksis
Jeg registrerer min enhed én gang via biometri eller PIN-kode, serveren gemmer den offentlige nøgle, og så er det klaret. Næste gang jeg logger ind, bekræfter jeg login med fingeraftryk eller ansigtsgenkendelse uden at skulle indtaste tegnstrenger. Jeg kan desuden integrere en hardware-nøgle, hvis retningslinjerne kræver flere faktorer. For at sikre en problemfri introduktion bruger jeg en klar opsætningsproces med god onboarding-tekst og gendannelsesmuligheder. Hvis du planlægger at komme i gang med det tekniske, finder du nyttige trin i denne vejledning til Implementering af WebAuthn.
Overholdelse, revisioner og juridiske krav
Stærk autentificering understøttes Revision-krav, fordi jeg kan tildele begivenheder entydigt. WebAuthn reducerer ansvarsrisici, da serveren ikke længere gemmer adgangskoder, der kan udgøre en risiko for berørte brugere i tilfælde af et læk. Til revisioner kan jeg stille autentificeringsprotokoller til rådighed og udvide retningslinjer til hardwarenøgler eller biometriske godkendelser. Det letter interne sikkerhedsevalueringer og eksterne revisioner. Virksomheder drager fordel af det, fordi klare beviser og mindre angrebsflader hjælper med at undgå konflikter med krav.
Brugeroplevelse: Hurtig, sikker, enkel
Jeg sparer tid, fordi jeg ikke Adgangskoder mere at taste eller nulstille. Log-in føles som at låse sin smartphone op: bekræft, færdig. Support-tickets på grund af glemte, udløbne eller spærrede adgangskoder falder markant. For admin-teams forbliver fokus på arbejdet i stedet for adgangskodepleje. Hvis du også sætter pris på single sign-on, kan du elegant koble passkeys sammen med OpenID Connect SSO og reducerer friktionen yderligere.
Indførelse uden brud: Overgangsstrategier
Jeg starter med WebAuthn som Primært-metoden og tillader midlertidigt fallbacks for ældre enheder. Browser-dækningen er allerede meget høj, så de fleste brugere drager direkte fordel af det. Jeg implementerer konsekvent HTTPS, HSTS og host-header-validering, så scoping fungerer korrekt. For ældre systemer planlægger jeg midlertidige engangskoder eller gemte adgangskoder, indtil overgangen er afsluttet. Det er vigtigt at kommunikere klart: hvorfor adgangskoder er mere sikre, hvordan gendannelse fungerer, og hvilke skridt brugerne skal tage.
Hyppige indvendinger afklaret
Hvis jeg mister min enhed, forbliver nøgle Ja, for biometri eller PIN-kode beskytter den lokalt. Jeg gemmer desuden en ekstra adgangskode eller hardwarenøgle, så jeg straks kan logge ind igen. Jeg løser problemet med fælles adgang ved at tildele hver person sin egen login og afgrænse rettighederne tydeligt. Det er mere sikkert og overskueligt end at dele en adgangskode. Til automatisering bruger jeg API-tokens i stedet for personlige logins, så jeg kan styre rettigheder og processer tydeligt.
Teknisk dybde: Registrering, signaturer og referenceværdier
For at sikre en robust implementering er jeg opmærksom på detaljerne: rpId skal passe nøjagtigt til det domæne eller underdomæne, jeg sikrer. Udfordringer er tilfældige, entydige og kortvarige (f.eks. 60-180 sekunder), så gentagelser ikke virker. Ud over den offentlige nøgle gemmer jeg også credentialId, brugerhåndtag og tæller/signaturtæller for at genkende klonindikatorer. Hvad angår algoritmerne, klarer jeg mig godt med P-256 eller Ed25519; jeg forbyder svage eller forældede kurver. Attestation behandler jeg efter behov: I åben hosting er „none“ normalt tilstrækkeligt, i regulerede miljøer kan jeg tillade udvalgte AAGUID'er, hvis jeg ønsker at foreskrive bestemte hardwarenøgler.
Platform- vs. hardware-nøgler, opdagelige legitimationsoplysninger
Jeg skelner mellem Platformautentificering (f.eks. bærbar computer, smartphone) og Cross-platform-nøgler (Hardware-sikkerhedsnøgle). Platform-adgangskoder er praktiske og synkroniseres ofte automatisk, mens hardware-nøgler er ideelle som anden faktor og til administratorer med højere rettigheder. Discoverable Credentials (også kaldet „adgangskoder“) letter login uden brugernavn, mens ikke-opdagelige Credentials er gode til strengt administrerede konti. Det er vigtigt at registrere mindst to uafhængige autentificeringsmetoder for hver kritisk konto, så jeg ikke skaber et sikkerhedshul, når jeg skifter enhed.
Roller, klienter og delegation i hosting
I den daglige hosting-praksis findes der Teams, forhandlere og kunder. Derfor adskiller jeg adgangen tydeligt: Hver person får sit eget login med adgangskode, og jeg tildeler rettigheder via roller i stedet for via delte adgangsdata. Jeg begrænser midlertidig adgang i tid, f.eks. for eksterne udviklere. For forhandlere satser jeg på delegering: De administrerer kundekonti uden nogensinde at kende deres hemmeligheder. Audit-logs og entydige nøglepar hjælper mig med senere at tildele handlinger til personer eller roller.
SSH, Git og API: Uden adgangskode, men anderledes
Ud over web-login tænker jeg på SSH og Git. WebAuthn er browserbaseret; til serveradgang bruger jeg moderne nøgleprocedurer (f.eks. FIDO2- eller klassiske SSH-nøgler) i stedet for adgangskoder. Til implementeringer og CI/CD bruger jeg kortvarige tokens med snævert omfang i stedet for at automatisere personlige konti. På den måde bevares princippet om adskillelse: Mennesker autentificerer sig via adgangskode, maskiner via token eller nøglemateriale, som jeg kan rotere og minimere.
Møder, step-up og følsomme handlinger
Efter vellykket autentificering starter jeg en kortvarig session og forny dem sikkert. For særligt følsomme handlinger (f.eks. SSH-nøgleoverførsel, backup-download, faktura- eller DNS-ændringer) kræver jeg en aktuel brugerverifikation („step-up“) via adgangskode, selvom der stadig er en aktiv session. Dette reducerer misbrug gennem sessionstyveri. Jeg forhindrer session-fixation, binder cookies til Origin og indstiller strenge SameSite- og Secure-flags.
Tilgængelighed og supportoplevelse
Jeg tænker på Tilgængelighed: Brugere har brug for klare oplysninger om, hvad der sker under frigivelsen af adgangskoden. Jeg skriver fejlmeddelelser, der er meningsfulde („Denne enhed understøtter ikke adgangskoder til dette domæne“) og tilbyder en PIN-alternativ til biometri. Til helpdesken dokumenterer jeg standardtilfælde: tilføjelse af ny enhed, spærring af mistet enhed, udskiftning af hardwarenøgle, kontooverførsel ved medarbejderudskiftning. På den måde forbliver supportprocesserne korte og reproducerbare.
Databeskyttelse: Færre personlige risici
Biometriske data forlader ikke mine enheder; de låser kun den private nøgle op lokalt. På serversiden gemmer jeg kun det absolut nødvendige: offentlig nøgle, identifikationsnummer, metadata til sikkerhed og revision. Jeg definerer klart opbevaringsfrister og sletningskoncepter. Da der ikke længere findes adgangskoder, mindskes konsekvenserne af mulige lækager for slutbrugerne mærkbart. Det letter vurderingen af konsekvenserne for databeskyttelsen og reducerer informationspligten i alvorlige tilfælde.
Målbare effekter og målinger
Jeg måler succesen af min omstilling med konkrete nøgletal: Andel af login uden adgangskode, tid til vellykket login, afbrydelsesprocent ved registrering, antal adgangskode-resets (bør falde kraftigt), phishing-relaterede tickets, svindel- eller spærringshændelser pr. måned. Jeg observerer, at login-tiden er blevet kortere, og at logins foregår mere konsistent, hvilket også forbedrer konverteringen i selvbetjeningsportaler.
Behandl fejlbilleder korrekt
Jeg kender på forhånd de typiske forhindringer: Forkert rpId eller subdomæne-mismatch fører til afviste anmodninger. Tidsspredning kan gøre udfordringer ugyldige; jeg holder serverure synkrone. Blokerede pop-ups eller begrænsede browserprofiler forhindrer visning af WebAuthn-prompten; jeg forklarer de nødvendige tilladelser. Når der skiftes enhed, henviser jeg tydeligt til den anden registrerede adgangskode eller den gemte hardwarenøgle og har en kontrolleret gendannelsesproces klar, der forhindrer misbrug gennem sociale tricks.
Skalering, ydeevne og omkostninger
WebAuthn aflaster min infrastruktur dér, hvor password-resets, lockouts og TOTP-drift hidtil har bundet support og backend. Kryptografien i sig selv er hurtig; latenstiden skyldes primært brugerinteraktionen (biometri/PIN) og ikke serveren. Jeg drager fordel af mindre brute force og login-DDoS, fordi der ikke er behov for hastighedsbegrænsning på passwordforsøg. Samlet set falder TCO mærkbart: færre tickets, færre sikkerhedsforanstaltninger omkring adgangskodelagring og mindre risiko for datatyveri.
Tjekliste til min start
- HTTPS, HSTS og korrekt rpId/Origin fastlægge
- Registrering med mindst to autentifikatorer pr. administrator
- Klar genopretningsstrategi uden svage fallbacks
- Definer step-up for følsomme handlinger
- Registrer auditlogs for registrering, login og gendannelse
- Opret onboarding-tekster, fejlmeddelelser og helpdesk-playbooks
- Indfør KPI'er og evaluer dem regelmæssigt
Kort fortalt: Sådan kommer jeg i gang med Passkeys
Jeg aktiverer WebAuthn i hostingpanelet og registrerer mindst to faktorer: et biometrisk enhed plus en hardwarenøgle. Derefter konfigurerer jeg gendannelsesindstillinger og fjerner gamle adgangskoder, så snart alle involverede er skiftet over. Jeg dokumenterer processen, kommunikerer ændringer tidligt og har en kompakt helpdesk-artikel klar. Derefter kontrollerer jeg regelmæssigt, om alle admin-konti virkelig fungerer uden adgangskode. Sådan opbygger jeg trin for trin et login-model, der fjerner grundlaget for phishing og credential stuffing.
