{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"cs/authentication","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/authentication/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/authentication/"},"term":{"en":"Authentication","da":"Autentificering"},"aka":{"en":["authn"],"da":["godkendelse","autentifikation"]},"domain":["cs","security"],"cluster":"identity","layer":"identity","status":"current","summary":{"en":"Checking that someone who logs in really is who they claim to be, usually by asking for a credential such as a password.","da":"At kontrollere, at den, der logger ind, virkelig er den, vedkommende udgiver sig for, typisk med en loginoplysning som en adgangskode."},"body":{"formal":{"en":"The process of confirming a claimed identity by checking one or more credentials - something the person knows, has or is - against what the system holds on record.","da":"Processen, hvor en påstået identitet bekræftes ved at kontrollere én eller flere loginoplysninger - noget personen ved, har eller er - mod det, systemet har registreret."},"plain":{"en":"Like a border guard comparing your face with your passport photo - the only question is “are you really you?”, not where you may go.","da":"Som en grænsevagt, der sammenligner dit ansigt med billedet i dit pas - det eneste spørgsmål er “er du virkelig dig?”, ikke hvor du må gå hen."},"inPractice":{"en":"A payroll clerk in a municipality types her user name and password, then approves a prompt in an app on her phone; only then does the payroll system accept that it really is her.","da":"En lønbogholder i en kommune indtaster brugernavn og adgangskode og godkender derefter en anmodning i en app på sin telefon; først da accepterer lønsystemet, at det virkelig er hende."},"whyItMatters":{"en":"Every later decision about access trusts the answer given here, so weak authentication lets an attacker walk in wearing someone else's identity.","da":"Alle senere beslutninger om adgang bygger på svaret her, så svag autentificering lader en angriber gå ind under en andens identitet."}},"deepDive":{"en":"NIST SP 800-63-4 (final in 2025) gives the standard vocabulary. A claimant proves control of one or more authenticators to a verifier; once bound to a subscriber account by a credential service provider, the authenticator becomes the thing checked at each login. Strength is graded as authenticator assurance levels in SP 800-63B-4: AAL1 permits a single factor, AAL2 requires two distinct factors, and AAL3 requires a phishing-resistant authenticator with a non-exportable private key. The same document sets reauthentication limits: at AAL2 the session should last no more than 24 hours overall and 1 hour of inactivity, and at AAL3 no more than 12 hours overall, with inactivity limited to 15 minutes.\n\nThe factors (knowledge, possession, inherence) are not equally robust against today's main attack, adversary-in-the-middle phishing, in which a proxy such as Evilginx relays the password and one-time code or push approval to the real site in real time and keeps the resulting session cookie. SP 800-63B-4 §3.2.5 defines phishing resistance as preventing disclosure of authenticator outputs to an impostor verifier, achieved either by channel binding (tying the output to the TLS channel, as with client certificates) or verifier-name binding (tying it to the relying party's identifier, as WebAuthn does with the origin and RP ID). Other hard rules in the same document: verifiers must stop an authenticator after at most 100 consecutive failed attempts on an account (§3.2.2), must not use knowledge-based security questions, and PSTN-delivered codes (SMS, voice) are a \"restricted\" authenticator (§3.1.3.3).\n\nUnderneath, most protocols are challenge-response: the verifier sends a fresh nonce and the claimant returns a value only the authenticator holder could compute, which defeats simple replay. Kerberos (RFC 4120) issues tickets from a key distribution centre so services never see the password, while NTLM's use of the password hash as the key is what makes pass-the-hash possible. Mutual authentication, where the server also proves its identity, is what TLS server certificates provide. Machines authenticate with mutual TLS, signed JWT client assertions (RFC 7523) or platform-issued workload identities rather than passwords.\n\nCommon misconceptions: authentication is not identity proofing, which happens once at enrolment (identity assurance levels in SP 800-63A); the weakest path is often account recovery or a help-desk reset rather than the login page; and an authentication result is a point-in-time event whose value is carried forward by a session, so session theft bypasses even strong MFA. Authentication answers who is asking; authorization, evaluated afterwards, decides what they may do.","da":"NIST SP 800-63-4 (endelig udgave fra 2025) giver det gængse begrebsapparat. En claimant beviser over for en verifier, at vedkommende har kontrol over en eller flere autentifikatorer; når en credential service provider har knyttet autentifikatoren til en brugerkonto, er det den, der kontrolleres ved hvert login. Styrken angives som authenticator assurance levels i SP 800-63B-4: AAL1 tillader én faktor, AAL2 kræver to forskellige faktorer, og AAL3 kræver en phishing-resistent autentifikator med en privat nøgle, der ikke kan eksporteres. Samme dokument fastsætter grænser for genautentificering: På AAL2 bør en session højst vare 24 timer i alt og 1 time uden aktivitet, og på AAL3 højst 12 timer i alt med inaktivitet begrænset til 15 minutter.\n\nFaktorerne (noget man ved, har eller er) er ikke lige robuste over for dagens hovedangreb, adversary-in-the-middle-phishing, hvor en proxy som Evilginx i realtid videresender adgangskode og engangskode eller push-godkendelse til det rigtige website og beholder den sessionscookie, der kommer ud af det. SP 800-63B-4 §3.2.5 definerer phishing-resistens som evnen til at forhindre, at autentifikatorens output afsløres over for en falsk verifier, enten ved kanalbinding (outputtet bindes til TLS-kanalen, som ved klientcertifikater) eller ved binding til verifierens navn (outputtet bindes til relying partyens identifikator, som WebAuthn gør med origin og RP ID). Andre faste regler i dokumentet: En verifier skal spærre en autentifikator efter højst 100 fejlede forsøg i træk på en konto (§3.2.2), må ikke bruge vidensbaserede kontrolspørgsmål, og koder sendt via telefonnettet (SMS, opkald) er en \"begrænset\" autentifikator (§3.1.3.3).\n\nUnder overfladen er de fleste protokoller challenge-response: Verifieren sender en frisk nonce, og claimanten returnerer en værdi, som kun indehaveren af autentifikatoren kan beregne, hvilket forhindrer simpel genafspilning. Kerberos (RFC 4120) udsteder billetter fra et key distribution center, så tjenesterne aldrig ser adgangskoden, mens NTLM bruger selve adgangskode-hashen som nøgle, og det er netop det, der gør pass-the-hash muligt. Gensidig autentificering, hvor serveren også beviser sin identitet, er det, TLS-servercertifikater leverer. Maskiner autentificerer sig med gensidig TLS, signerede JWT-klientassertions (RFC 7523) eller workload-identiteter udstedt af platformen frem for adgangskoder.\n\nTypiske misforståelser: Autentificering er ikke identitetssikring (identity proofing), som sker én gang ved registreringen (identity assurance levels i SP 800-63A); den svageste vej er ofte gendannelse af kontoen eller en nulstilling via servicedesken frem for selve loginsiden; og et autentificeringsresultat gælder kun i øjeblikket og føres videre af en session, så tyveri af sessionen omgår selv stærk MFA. Autentificering svarer på, hvem der spørger; autorisation, der vurderes bagefter, afgør, hvad vedkommende må."},"edges":[{"type":"requires","to":"cs/identity","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/credential","confidence":"high","strength":"normal"},{"type":"contrasts-with","to":"cs/authorization","why":{"en":"Authentication asks who you are; authorization asks what you may do. Passing the first does not grant the second.","da":"Autentificering spørger, hvem du er; autorisation spørger, hvad du må. At bestå den første giver ikke automatisk den anden."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"cs/session","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/zero-trust","why":{"en":"Zero Trust authenticates every request again instead of trusting anyone already inside the network.","da":"Zero Trust autentificerer hver forespørgsel på ny i stedet for at stole på alle, der allerede er inde på netværket."},"confidence":"high","strength":"normal"}],"depth":2,"sources":[{"title":"NIST SP 800-63-3, Digital Identity Guidelines","url":"https://pages.nist.gov/800-63-3/sp800-63-3.html","tier":"standard","publisher":"NIST"},{"title":"NIST SP 800-63B-4 - Authentication and Authenticator Management","url":"https://pages.nist.gov/800-63-4/sp800-63b.html","tier":"standard","publisher":"NIST"}],"draft":true}