{"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/credential","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/credential/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/credential/"},"term":{"en":"Credential","da":"Loginoplysning (credential)"},"aka":{"en":["login details"],"da":["loginoplysninger","legitimation","credential"]},"domain":["cs"],"cluster":"identity","layer":"identity","status":"current","summary":{"en":"Something a user presents to prove who they are, such as a password, a key card or a fingerprint.","da":"Noget, en bruger fremviser for at bevise, hvem vedkommende er, fx en adgangskode, et nøglekort eller et fingeraftryk."},"body":{"formal":{"en":"An item or piece of information bound to an identity and used during authentication to show that whoever presents it is the rightful holder of that identity.","da":"En genstand eller oplysning, der er knyttet til en identitet og bruges under autentificering til at vise, at den, der fremviser den, er identitetens retmæssige indehaver."},"plain":{"en":"Like a house key - whoever holds it is let in, which is exactly why you do not lend it out or leave it under the doormat.","da":"Som en husnøgle - den, der har den, bliver lukket ind, og netop derfor låner man den ikke ud eller lægger den under dørmåtten."},"inPractice":{"en":"The user name and password of a consultant at an auditing firm turn up for sale online; anyone who buys them can log in to client systems as the consultant until the password is changed.","da":"Brugernavn og adgangskode til en konsulent i et revisionsfirma bliver sat til salg på nettet; enhver, der køber dem, kan logge ind i kundernes systemer som konsulenten, indtil adgangskoden bliver skiftet."},"whyItMatters":{"en":"Stolen credentials are one of the most common ways attackers get in, because with them they look exactly like a legitimate user.","da":"Stjålne loginoplysninger er en af angribernes mest almindelige veje ind, fordi de med dem ligner en helt almindelig, legitim bruger."}},"deepDive":{"en":"Everyday usage treats \"credential\" as anything used to log in, but NIST SP 800-63-3 draws a sharper line. There, the authenticator is what the claimant possesses and controls (a password, an OTP device, a private key), while the credential is the object or data structure that authoritatively binds an identity, via one or more identifiers, to at least one authenticator. In that strict sense an X.509 certificate is a credential, since the CA's signature binds a subject name to a public key, and the matching private key is the authenticator. The distinction matters when reading standards, even though most product documentation uses the looser meaning.\n\nTechnically, credentials fall into three families. Shared secrets, such as passwords, PINs, API keys, HMAC keys and TOTP seeds (RFC 6238), require the verifier to hold something derived from the same secret, so a breach of the verifier's store enables offline cracking or direct reuse. Asymmetric credentials, such as TLS client certificates, SSH keys and FIDO2 passkeys, leave the verifier holding only a public key, so its compromise yields nothing usable for logging in. Derived bearer credentials, such as session cookies, OAuth access and refresh tokens and Kerberos tickets, are issued after authentication and grant access to whoever presents them unless they are sender-constrained, for example with mutual TLS (RFC 8705) or DPoP (RFC 9449).\n\nHandling rules follow from that split. Human secrets are stored as salted, slow hashes; machine secrets belong in a secrets manager or are replaced with short-lived credentials from a token service or workload identity federation; private keys should be non-exportable inside a TPM, secure enclave, smart card or HSM. Static cloud access keys committed to source control are a recurring cause of breaches, which is why secret scanning in CI and in repository hosting is now standard. Every credential needs a lifecycle: issuance, binding to the account, renewal, revocation (CRLs or OCSP for certificates) and prompt invalidation when compromise is suspected.\n\nMITRE ATT&CK groups the attacker side under the Credential Access tactic (TA0006), including Brute Force (T1110, with Credential Stuffing as T1110.004), OS Credential Dumping (T1003, for example reading LSASS memory with Mimikatz), Credentials from Password Stores (T1555), Unsecured Credentials (T1552) and Steal Web Session Cookie (T1539). Infostealer malware harvests browser-saved passwords and session cookies in bulk, so a credential can be stolen without any phishing page. A credential proves control of an identity; it does not itself carry permissions, which are attached to the account it unlocks.","da":"I daglig tale bruges \"credential\" om alt, der bruges til at logge ind, men NIST SP 800-63-3 trækker en skarpere grænse. Her er autentifikatoren det, som claimanten har og kontrollerer (en adgangskode, en OTP-enhed, en privat nøgle), mens credential er det objekt eller den datastruktur, der autoritativt binder en identitet via en eller flere identifikatorer til mindst én autentifikator. I den snævre forstand er et X.509-certifikat en credential, fordi CA'ens signatur binder et subjektnavn til en offentlig nøgle, og den tilhørende private nøgle er autentifikatoren. Sondringen er vigtig, når man læser standarder, selv om det meste produktdokumentation bruger den løsere betydning.\n\nTeknisk falder loginoplysninger i tre familier. Fælles hemmeligheder som adgangskoder, PIN-koder, API-nøgler, HMAC-nøgler og TOTP-seeds (RFC 6238) kræver, at verifieren opbevarer noget afledt af samme hemmelighed, så et brud på verifierens lager muliggør offline-knækning eller direkte genbrug. Asymmetriske loginoplysninger som TLS-klientcertifikater, SSH-nøgler og FIDO2-passkeys efterlader kun en offentlig nøgle hos verifieren, så et kompromis dér giver intet, der kan bruges til at logge ind. Afledte bearer-loginoplysninger som sessionscookies, OAuth-adgangs- og refresh-tokens og Kerberos-billetter udstedes efter autentificeringen og giver adgang til den, der fremviser dem, medmindre de er bundet til afsenderen, fx med gensidig TLS (RFC 8705) eller DPoP (RFC 9449).\n\nHåndteringsreglerne følger af den opdeling. Menneskers hemmeligheder gemmes som saltede, langsomme hashes; maskiners hemmeligheder hører hjemme i en secrets manager eller erstattes af kortlivede loginoplysninger fra en tokentjeneste eller workload identity federation; private nøgler bør ikke kunne eksporteres fra en TPM, en secure enclave, et chipkort eller en HSM. Statiske adgangsnøgler til cloud, der er committet til kildekoden, er en tilbagevendende årsag til brud, og derfor er secret scanning i CI og hos repository-udbyderen nu standard. Hver loginoplysning har brug for en livscyklus: udstedelse, binding til kontoen, fornyelse, tilbagekaldelse (CRL eller OCSP for certifikater) og hurtig ugyldiggørelse ved mistanke om kompromittering.\n\nMITRE ATT&CK samler angriberens side under taktikken Credential Access (TA0006), bl.a. Brute Force (T1110, med Credential Stuffing som T1110.004), OS Credential Dumping (T1003, fx læsning af LSASS-hukommelsen med Mimikatz), Credentials from Password Stores (T1555), Unsecured Credentials (T1552) og Steal Web Session Cookie (T1539). Infostealer-malware høster gemte browseradgangskoder og sessionscookies i stor stil, så loginoplysninger kan stjæles helt uden en phishingside. En loginoplysning beviser kontrol over en identitet; den bærer ikke selv rettigheder, som i stedet er knyttet til den konto, den låser op."},"edges":[{"type":"requires","to":"cs/identity","confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/identity-provider","why":{"en":"An identity provider stores and checks credentials on behalf of many applications.","da":"En identitetsudbyder gemmer og kontrollerer loginoplysninger på vegne af mange programmer."},"confidence":"high","strength":"normal"}],"depth":1,"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"}],"draft":true}