4 Identity, Access, and Cryptography

Identity and access lifecycle

Identity and access management (IAM) establishes digital identities, manages their credentials, and controls access to resources. A typical identity lifecycle includes creating an account, assigning roles and authenticators, changing access when a person's job changes, and promptly disabling accounts when access is no longer needed. Regular access reviews help identify permissions that are excessive or out of date.

Keep four functions distinct:

• Identification: A person or system claims an identity, such as by entering a username.

• Authentication: The system verifies the claimed identity using an authenticator.

• Authorization: The system decides what an authenticated identity is permitted to do.

• Accounting and auditing: The system records activity so it can be reviewed and investigated.

Successful authentication does not guarantee authorization. For example, a user may authenticate to a company portal but still lack permission to view payroll records.

Access policies and shared identity

Apply least privilege by granting only the access needed for assigned tasks. Separation of duties divides sensitive actions so that they may require more than one person or role. Privileged access management (PAM) protects administrator accounts and high-impact permissions, often through separate administrator accounts, limited-duration access, and activity logging.

Access-control models

• Discretionary access control (DAC): Resource owners grant or revoke access, commonly through permissions or access-control lists.

• Mandatory access control (MAC): A central policy uses security labels or classifications to decide access; individual users cannot override that policy.

• Role-based access control (RBAC): Permissions are assigned to roles, and users receive access through their assigned roles. For example, a “billing clerk” role may allow reading invoices and issuing refunds up to a defined limit.

• Attribute-based access control (ABAC): Rules evaluate attributes of the user, resource, requested action, and context. For example, a policy might allow a clinician to view a patient record only when the clinician is assigned to that patient and is using an approved device.

Single sign-on (SSO) lets a user authenticate once to an identity provider and then access multiple connected services without separately entering credentials at each service. Federation allows separate organizations or services to trust identity assertions from an identity provider. SAML and OpenID Connect are commonly used federation standards. SSO can reduce password reuse, but it makes the identity provider especially important to secure and monitor.

Authentication and account protection

Authentication factors are commonly grouped by what they involve:

• Something you know: A password or PIN.

• Something you have: A hardware security key, smart card, or authenticator device.

• Something you are: A biometric characteristic, such as a fingerprint.

Multi-factor authentication (MFA) combines two or more different factor types. Two passwords do not constitute MFA because both are knowledge factors. A biometric used with a device-based authenticator can provide possession and inherence factors.

Phishing-resistant authentication, such as appropriately implemented FIDO/WebAuthn security keys or passkeys, binds authentication to the legitimate service. One-time codes that users manually enter can still be phished or relayed, so MFA is not automatically phishing-resistant.

Passwords should be unique and difficult to guess. Systems should store password verifiers using a unique salt and a password-hashing scheme designed to slow guessing, not as plaintext or with only a fast, general-purpose hash. Rate limiting and monitoring can reduce online guessing attacks. Avoid unnecessary periodic password changes, but require a change when a password is suspected to be compromised. Authenticator management also includes secure enrollment and recovery, and revoking a lost or stolen authenticator.

Cryptographic goals and key use

Cryptography supports several different security goals:

• Confidentiality: Encryption makes data unreadable to parties without the required key.

• Integrity: A cryptographic check can reveal unauthorized changes.

• Authentication: A cryptographic credential or message authenticator can help verify an identity or data origin.

• Nonrepudiation: A digital signature can provide evidence that a particular private key signed data, though it does not by itself prove who controlled the key or what a signer intended.

Symmetric encryption uses the same secret key to encrypt and decrypt. It is efficient for protecting large amounts of data, but the key must be shared securely. Asymmetric cryptography uses a related public and private key. Public-key algorithms can support digital signatures and key establishment; they are generally combined with symmetric encryption for efficient data protection.

A cryptographic hash produces a fixed-length digest of data. A secure hash can help detect changes when the expected digest is trusted, but a plain hash does not authenticate who created the data. A message authentication code (MAC) uses a secret key to protect integrity and authenticate data to parties that share that key. A digital signature uses a private key to sign and a corresponding public key to verify; it supports integrity and verification of the signing key's holder. Hashes, MACs, and signatures are not interchangeable with encryption.

Key security depends on more than choosing an algorithm. Generate keys with suitable randomness, limit who can access them, protect and rotate them appropriately, and revoke or replace compromised keys. Keep private keys secret; public keys may be distributed openly.

Certificates and trust

A digital certificate binds an identity, such as a website's domain name, to a public key. In a public-key infrastructure (PKI), a certificate authority (CA) signs certificates. Clients build a chain of trust from a certificate through any intermediate CAs to a trusted root. A certificate does not prove that a website or organization is harmless; it helps establish that a public key is associated with the identity named in the certificate.

When validating a certificate, check that it chains to a trusted CA, is within its validity period, matches the intended name or identity, and is acceptable for the intended use. Also consider its revocation status. A certificate revocation list (CRL) distributes lists of revoked certificates, while OCSP allows a client to check a certificate's status online.

Secure communications

Secure protocols combine cryptographic tools and procedures to protect communications.

• TLS protects application traffic with confidentiality and integrity and can authenticate a server using certificates; client-certificate authentication is also possible. HTTPS is HTTP carried over TLS. Investigate a certificate warning rather than bypassing it without investigation. The TLS 1.3 specification is RFC 9846.

• SSH provides secure remote login and other network services using secure transport and user authentication. Verify a server's host key rather than blindly accepting an unexpected change. SFTP transfers files over SSH.

• IPsec protects IP-layer communications and is commonly used for VPNs. Depending on configuration, it can provide confidentiality, integrity, authentication, and replay protection.

Legacy protocols and secure configuration

Recognize legacy or insecure choices. SSL, Telnet, FTP, and unencrypted HTTP do not provide the protections expected of modern secure connections. SNMPv1 and SNMPv2c rely on community strings and do not provide the protections of SNMPv3's security features.

Use current, securely configured protocols, and disable obsolete versions and weak algorithms. Across identity and cryptographic systems, protect privileged access, use phishing-resistant authentication where appropriate for sensitive accounts, protect keys, and validate certificates and their status.