Authentication Mechanisms
1. SSH Keys
- Components:
- Public Key: Shared with the server and can be distributed widely. It is associated with the user’s account on the server.
- Private Key: Kept secret by the user. It must be protected with strong security practices, often encrypted with a passphrase.
- How Authentication Works:
1. Key Generation: The user generates a key pair using tools like `ssh-keygen`.
2. Public Key Distribution: The public key is copied to the server (usually added to the `~/.ssh/authorized_keys` file).
3. Connection Process:
- The user initiates an SSH connection.
- The server checks if the public key matches any key in the `authorized_keys` file.
- The server generates a challenge, encrypted with the user’s public key.
- The user’s SSH client decrypts the challenge with the private key and sends the response back.
- If the response is correct, the server grants access.
- Security Benefits:
- No Passwords Over the Network: Since authentication is done using keys, there’s no need to send passwords over the network, reducing the risk of interception.
- Stronger Security: SSH keys can be much stronger than passwords due to the larger bit size of the key (e.g., 2048-bit or 4096-bit keys).
- Common Uses:
- Automated Scripts: SSH keys are often used for automated tasks like backups or deployments, where passwordless login is essential.
- Multi-factor Authentication: SSH keys can be combined with other methods like passwords or hardware tokens for additional security.
2. OAuth
- Key Concepts:
- Resource Owner: The user who owns the data being accessed.
- Client: The application requesting access to the user’s data.
- Authorization Server: The server issuing tokens after authenticating the resource owner and obtaining authorization.
- Resource Server: The server hosting the resource being accessed (e.g., APIs).
- OAuth Flows:
1. Authorization Code Flow (most common):
- The client redirects the user to the authorization server.
- The user logs in and grants the client permission to access specific resources.
- The authorization server sends an authorization code to the client.
- The client exchanges this code for an access token.
- The access token is then used to access the resource server.
2. Implicit Flow: Suitable for client-side applications. The access token is obtained directly from the authorization server without an intermediate authorization code.
3. Client Credentials Flow: Used when the client is accessing its own resources or when the user’s involvement is not required.
4. Resource Owner Password Credentials Flow: The client collects the username and password directly from the user, which is generally discouraged due to security concerns.
- Tokens:
- Access Token: Used by the client to access resources on the resource server.
- Refresh Token: Allows the client to obtain a new access token without re-authenticating the user.
- Scopes: Define what the access token can do, like "read-only" or "write access" to certain data.
- Security Considerations:
- Token Expiry: Tokens should have a short lifespan to minimize the impact if they are compromised.
- Token Revocation: OAuth supports revoking tokens if a session is terminated or if the token is misused.
- PKCE (Proof Key for Code Exchange): Enhances security by ensuring that the authorization code cannot be intercepted during the authorization code flow.
3. SSL/TLS Certificates
- Certificate Structure:
- Common Name (CN): The domain name the certificate is issued for.
- Subject Alternative Names (SANs): Additional domains/subdomains covered by the certificate.
- Public Key: Used by clients to establish a secure connection.
- Issuer: The Certificate Authority (CA) that issued the certificate.
- Signature: The CA’s digital signature that verifies the authenticity of the certificate.
- How SSL/TLS Works:
1. Handshake Process:
- The client (e.g., a web browser) connects to the server and requests a secure session.
- The server sends its SSL/TLS certificate to the client.
- The client verifies the certificate’s authenticity using the CA’s public key.
- The client generates a session key, encrypts it with the server’s public key, and sends it to the server.
- The server decrypts the session key with its private key.
- Both the server and client use this session key to encrypt all subsequent communications.
2. Session Resumption: To improve performance, SSL/TLS can use session IDs or session tickets to resume a previous secure session without repeating the entire handshake.
- Types of Certificates:
- Domain Validated (DV): Confirms the ownership of the domain.
- Organization Validated (OV): Confirms the ownership of the domain and the legitimacy of the organization.
- Extended Validation (EV): Provides the highest level of validation, including legal and operational checks of the organization, often indicated by a green address bar in browsers.
- Security Concerns:
- Certificate Revocation: Certificates can be revoked if compromised, and browsers can check revocation status via CRLs (Certificate Revocation Lists) or OCSP (Online Certificate Status Protocol).
- Man-in-the-Middle (MitM) Attacks: If an attacker can obtain a fraudulent certificate, they could intercept communications. Certificate pinning and CA monitoring help mitigate this risk.
4. Credentials
- Traditional Credentials:
- Username: Often public and used to identify the user.
- Password: A secret known only to the user and the authentication system.
- Hashing and Salting: Passwords are usually stored as cryptographic hashes in a database, often with added "salt" (random data) to defend against rainbow table attacks.
- Multi-Factor Authentication (MFA):
- Something You Know: The traditional password or PIN.
- Something You Have: A physical token, smart card, or mobile phone generating one-time passwords (OTPs) or receiving push notifications.
- Something You Are: Biometrics like fingerprints, facial recognition, or retina scans.
- Credential Management:
- Password Policies: Strong passwords are required (length, complexity), and regular password changes are enforced.
- Credential Rotation: Especially in systems with automated access, credentials should be rotated regularly to reduce the risk of long-term exposure.
- Credential Storage: Sensitive credentials should be stored securely, often encrypted, with restricted access.
- Single Sign-On (SSO): Allows users to authenticate once and gain access to multiple systems without re-entering credentials, improving security and user experience.
- Threats:
- Phishing: Attackers trick users into providing their credentials.
- Brute Force Attacks: Automated attempts to guess passwords.
- Credential Stuffing: Using stolen credentials from one breach to try to access other systems.
Each of these mechanisms offers different levels of security and is suited to different scenarios. Combining them, such as using SSH keys with MFA or OAuth with SSL/TLS, provides stronger security across various systems and services.
Comments