Difference between revisions of "Credential"

Latest revision as of 14:22, 29 October 2024

Full Title or Meme

A Credential in the digital realm is a structure which contains, at a minimum, a secret value which can be used in Authentication of a Subject or Authorization to access a resource.

Context

• The original digital Credential was just a shared secret, usually called a Password.
• More secure Credentials keep private keys which are used to build an ID Token which can include anti-replay elements, that (with User Consent) is sent to a requester.
• There are a large number of proposed alternates to passwords, many of which seem to be little more than an attempt to make the password longer and hide that long password in some secret place.

RFC 4949 Definition

The following taken from RFC 4949 (2007-08) gives some history and some challenges around the use of the word Credential.

1. /authentication/ "identifier credential": A data object that is a portable representation of the association between an identifier and a unit of authentication information, and that can be presented for use in verifying an identity claimed by an entity that attempts to access a system. Example: X.509 public-key certificate. (See: anonymous credential.)
2. /access control/ "authorization credential": A data object that is a portable representation of the association between an identifier and one or more access authorizations, and that can be presented for use in verifying those authorizations for an entity that attempts such access. Example: X.509 attribute certificate. (See: capability token, ticket.)
3. /OSIRM/ "Data that is transferred to establish the claimed identity of an entity." [I7498-2] Deprecated Definition: IDOCs SHOULD NOT use this definition. As explained in the tutorial below, an authentication process can involve the transfer of multiple data objects, and not all of those are credentials.
4. /U.S. Government/ "An object that is verified when presented to the verifier in an authentication transaction." Deprecated Definition: IDOCs SHOULD NOT use this definition, it mixes concepts in a potentially misleading way. For example, in an authentication process, it is the identity that is "verified", not the credential; the credential is "validated". (See: validate vs. verify.)

     Tutorial: In general English, "credentials" are evidence or
     testimonials that (a) support a claim of identity or authorization
     and (b) usually are intended to be used more than once (i.e., a
     credential's life is long compared to the time needed for one
     use). Some examples are a policeman's badge, an automobile
     driver's license, and a national passport. An authentication or
     access control process that uses a badge, license, or passport is
     outwardly simple: the holder just shows the thing.

     The problem with adopting this term in Internet security is that
     an automated process for authentication or access control usually
     requires multiple steps using multiple data objects, and it might
     not be immediately obvious which of those objects should get the
     name "credential".

     For example, if the verification step in a user authentication
     process employs public-key technology, then the process involves
     at least three data items: (a) the user's private key, (b) a
     signed value -- signed with that private key and passed to the
     system, perhaps in response to a challenge from the system -- and
     (c) the user's public-key certificate, which is validated by the
     system and provides the public key needed to verify the signature.
     -  Private key: The private key is *not* a credential, because it
        is never transferred or presented. Instead, the private key is
        "Authentication information", which is associated with the
        user's identifier for a specified period of time and can be
        used in multiple authentications during that time.
     -  Signed value: The signed value is *not* a credential; the
        signed value is only ephemeral, not long lasting. The OSIRM
        definition could be interpreted to call the signed value a
        credential, but that would conflict with general English.
     -  Certificate: The user's certificate *is* a credential. It can
        be "transferred" or "presented" to any person or process that
        needs it at any time. A public-key certificate may be used as
        an "identity credential", and an attribute certificate may be
        used as an "authorization credential".

This wiki does not accept the concept that the user's certificate is a credential and neither do any Identifier or Attribute Providers. Since the certificate is a public document, anyone could have a copy and the Presentation of a copy is not in any way proof of anything without verification of the signer or the holder.

Problems

• The only truly secure digital Credential is one with a secret that the Subject owns and controls.
  • Control in this case means that only the user can use the Credential to acquire access.
  • In this definition, if an attacker can use the Credential in an Authentication, then the user does not control it.
• An unguessable string is of little value if it can just be stolen. Lots of proposed new credential types are unguessable, it remains to be seem if they will be protected from theft or inadvertent release.
• The secret in the credential cannot be shared in any know scalable secure manner, so it must simply be the source of some Authentication response that is secure from spoofing and replay.
• If a credential is used to acquire access to a critical resource, like a patients financial or health assets, some method for recovery of that access must be available. The recovery could be restoration of the credential if it has not be compromised, and replacement of the credential if it has.

Example of Attacks

These are some of the attacks that continue unabated in the wild. They will surely be used against new, untried, solutions.

1. A Bunch of Malicious Google Play Apps Stole User Banking Info ARS Technica 2021-11-20

   RESEARCHERS SAID THEY’VE discovered a batch of apps that were downloaded from Google Play more than 300,000 times before the apps were revealed to be banking trojans that surreptitiously siphoned user passwords and two-factor-authentication codes, logged keystrokes, and took screenshots. The apps—posing as QR scanners, PDF scanners, and cryptocurrency wallets

Solutions

• A Certificate binds a credential to an Identifier of its Subject as well as (potentially) other Attributes.
• Often there is also a binding to some sort of real-world credential, typically a piece of paper with a seal.
• NIST 800-63 (all versions) describe a Credential Service Provider which is designed to issue credentials to users after they by had the Identity Proofing prior to employment by the government. This flow can be substantially different in commercial systems, but there is always a need to verify the security of the user's private key or other secret that is a part of a credential.
• Web Authentication defines a Public Key Credential as data one entity presents to another in order to authenticate the former to the latter [RFC4949]. The term public key credential refers to one of: a public key credential source, the possibly-attested credential public key corresponding to a public key credential source, or an authentication assertion. Which one is generally determined by context. In other words, this credential is evidence that the user holds the private key, while in rfc 4949 and in this wiki, the credential is the object held that can be used multiple times (i.e. the private key).
• The best known Credential of the day (2020) is a Private Key Component.
• Digital Credentials Consortium's GitHub We are building an infrastructure for digital academic credentials that can support the education systems of the future. Find out more about us at our website.

Verifiable Credential

The W3C recommendation for a Verifiable Credential (VC) allows all sorts of modifications of the concept of Credential which takes it far beyond what is described here.

• As a general rule the credential is protected by a Decentralized ID or did with a published method. The entire security of the VC is limited by the control of the issuance and protect storage of any issued credential.
  • Issuance of a bogus credential is always possible given the low bar for an issuer. If the Relying Party can be fooled into accepting a bogus credential, there is no recourse that the user has withing the VC ecosystem. Any recourse needs to come from the real-world - that is from outside the system.
  • Protection of a credential in a user's possession. If the attacker is able to either steal the user's private keys, or to fool the user into using those private keys, then they can succeed at Identity Theft, a legal term that usually requires the proof of loss of significant value to the user, similar to use of a credit card to purchase a TV.

W3C Credential

The W3C has specified the use of a user Credential for authentication based primarily on the FIDO 2.0 specification.

• What are requirements when more than one SPC credential matches? Was addressed by the W3C SPC (Secure Payment Confirmation) Task Force with John Bradley representing FIDO. 2021-11-08

Misc. Credentials

Some private solutions for replacing passwords are:

• IdRamp announced (2021-11-24) that "Passwordless Credential Orchestration Manager is Now Available in the Oracle Cloud Marketplace". The link will take you to a collection of VCs that encoded as QR codes that lead to a user sign-in to Oracle. These really are just long passwords. It is not clear how they are protected from misuse.

Recovery by Restoration

• In the simplistic case of a password, the only restoration would be a copy of the password stored by the Subject in some secure location.
• In the case of a private key in a secure store, it may be sufficient to restore the value to a secure store if the user has had the foresight to enable such a process. These are never simple and always involve a second factor or physical access to the secure store as well. Two possible approaches:

1. At home recovery using another computer as either active (able to use the creds) or passive (just a store.)
2. In the cloud, either on a share belonging to the subject, or in a trusted third party. In either case the creds might be encrypted in such a manner that only the user could access them for installation in a smartphone.

Recovery by Replacement

• In the simplistic case of a password as a credential, a Website will go through a password replacement process which typically includes some other factor of identification, such as a cell phone or email address.
• In the case of a private key in a secure store, it may be sufficient to create a new value in a secure store. The recovery process is them much like the initial creation of the credential and the roll out of the certificate for that new key to all of the places where it will be used.
• A hybrid solution would create a new key on the subject's device and then use it to encrypt the incoming key so that only the user's device could decrypt it and load it into the device's secure store.

Browser Credential Management

The W3C Is maintaining an API to let user's store credential in the browser. See the wiki page Credential Management for current information about that.

References