application_security/authentication

146 notes in this subject, read out of this brain and free to use. This is page 2 of 3.

RSA key size minimum 2048 bits

The private key used to generate the cipher key must be sufficiently strong for the anticipated lifetime. The current best practice is to select a key size of at least 2048 bits when using RSA keys. Additional information on key lifetimes and comparable key strengths can be found in NIST SP 800-57.

Use SHA-256 for certificate hashing

Certificates should use SHA-256 for the hashing algorithm, rather than the older MD5 and SHA-1 algorithms which have cryptographic weaknesses and are not trusted by modern browsers.

Certificate domain name matching with CN and SAN

The domain name (or subject) of the certificate must match the fully qualified name of the server that presents the certificate. The FQDN must be in the subjectAlternativeName (SAN) attribute, as modern Chrome versions ignore the commonName (CN) attribute. For compatibility, certificates should have the primary FQDN in the CN and the full list of FQDNs in the SAN.

Certificate domain naming guidelines

When creating a certificate: consider whether the www subdomain should be included; do not include non-qualified hostnames; do not include IP addresses; do not include internal domain names on externally facing certificates. If a server is accessible using both internal and external FQDNs, configure it with multiple certificates.

Wildcard certificates violate principle of least privilege

Wildcard certificates are valid for all subdomains of a domain (such as *.example.org) and violate the principle of least privilege. When multiple systems share a wildcard certificate, the likelihood that the private key is compromised increases as the key may be present on multiple systems, and the value of this key is significantly increased, making it a more attractive target for attackers.

Wildcard certificate usage restrictions

Only use wildcard certificates where there is a genuine need, not for convenience. Consider using ACME to allow systems to automatically request and update their own certificates. Never use wildcard certificates for systems at different trust levels: two VPN gateways could share a wildcard certificate; multiple instances of a web application could share one; but a VPN gateway and public web server should not; and a public web server and internal server should not.

Wildcard certificate management controls

When using wildcard certificates: consider using a reverse proxy server which performs TLS termination so the wildcard private key is only present on one system; maintain a list of all systems sharing a certificate to allow them all to be updated if the certificate expires or is compromised; limit the scope of a wildcard certificate by issuing it for a subdomain (such as *.foo.example.org) or a separate domain.

Use trusted Certificate Authority for Internet applications

For Internet facing applications, certificates must be signed by a trusted certificate authority (CA) which is well-known and automatically trusted by operating systems and browsers. LetsEncrypt provides free domain validated SSL certificates trusted by all major browsers.

Internal CA for internal applications

For internal applications, an internal CA can be used. This means the FQDN of the certificate will not be exposed to an external CA or publicly in certificate transparency lists. However, the certificate will only be trusted by users who have imported and trusted the internal CA certificate that was used to sign them.

Certification Authority Authorization DNS records

CAA DNS records define which CAs are permitted to issue certificates for a domain. The records contain a list of CAs, and any CA not included should refuse to issue a certificate for the domain. This prevents attackers from obtaining unauthorized certificates through less-reputable CAs and can limit which CAs administrators or developers are able to use.

Certificate validation types: DV, OV, EV

Domain Validated (DV) is the base validation type and all publicly issued certificates must be domain validated. Organization Validated (OV) certificates include the requestor's organization information in the certificate subject. Extended Validation (EV) certificates provide an even higher level of verification including all DV and OV verifications. As of 2019, no major browser shows EV status differently as browsers do not believe EV certificates provide additional protection.

Certificate validation security equivalence

All browsers and TLS stacks are unaware of the difference between DV, OV, and EV certificates, so they are effectively the same in terms of security. An attacker only needs to reach the level of practical control of the domain to get a rogue certificate. The extra work for OV or EV certificates does not increase the scope of an incident and may create an availability risk.

Use TLS for all pages, not just sensitive ones

TLS should be used for all pages, not just those considered sensitive like the login page. Pages without TLS enforcement could give attackers an opportunity to sniff session tokens or inject malicious JavaScript into responses.

HTTP to HTTPS redirect with permanent redirect

For public facing applications, the web server may listen for unencrypted HTTP connections on port 80 and immediately redirect them with a permanent redirect (HTTP 301) to provide a better user experience for those who manually type in the domain name. This should be supported with the HTTP Strict Transport Security (HSTS) header.

Do not mix TLS and non-TLS content

A page available over TLS should not include any resources (JavaScript, CSS files) loaded over unencrypted HTTP. These unencrypted resources could allow attackers to sniff session cookies or inject malicious code. Modern browsers block attempts to load active content over unencrypted HTTP into secure pages.

Secure cookie flag for HTTPS-only transmission

All cookies should be marked with the Secure attribute, which instructs the browser to only send them over encrypted HTTPS connections to prevent them from being sniffed from unencrypted HTTP connections. This is important even if the website does not listen on HTTP (port 80), as an attacker performing an active man-in-the-middle attack could present a spoofed web server on port 80 to steal cookies.

Cache-Control: no-store for sensitive data

For modern HTTP/1.1+ clients and intermediaries, use the HTTP header: ``` Cache-Control: no-store ``` no-store is the strongest cache directive: it forbids both shared and private caches from storing any part of the response. The legacy combination Cache-Control: no-cache, no-store, must-revalidate plus Pragma: no-cache and Expires: 0 is only required if supporting pre-HTTP/1.1 caches (effectively obsolete in 2024+) and adds no protection beyond no-store on a modern stack.

Clear-Site-Data to clear cached client data at sign-out

To clear data already cached on the client at sign-out, additionally send the Clear-Site-Data header, for example: ``` Clear-Site-Data: "cache", "cookies", "storage" ``` Note that Cache-Control governs the HTTP cache; it does not control whether the browser stores cookies in its cookie jar, which is controlled by the cookie attributes (Max-Age, Expires, Session).

Mutual TLS authentication with client certificates

In mutual TLS (mTLS), both the client and server authenticate each other using TLS. The client proves their identity to the server with their own certificate. This enables strong authentication of the client and prevents an intermediate party from decrypting TLS traffic, even if they have a trusted CA certificate on the client system.

Client certificate challenges and administrative overhead

Client certificates are rarely used in public systems due to several challenges: issuing and managing client certificates involves significant administrative overhead; non-technical users may find installing client certificates difficult; organizations' TLS decryption practices can cause client certificate authentication to fail. However, client certificates and mTLS should be considered for high-value applications or APIs, particularly where users are technically sophisticated or part of the same organization.

Public key pinning deprecated in browsers

Public key pinning was added to browsers in the HTTP Public Key Pinning (HPKP) standard, but due to various issues it has subsequently been deprecated and is no longer recommended or supported by modern browsers. However, public key pinning can still provide security benefits for mobile applications, thick clients and server-to-server communication.

Online TLS configuration testing tools

Online tools to validate server TLS configuration: SSL Labs Server Test (ssllabs.com), CryptCheck (cryptcheck.fr), Hardenize (hardenize.com), ImmuniWeb (immuniweb.com/ssl/), Observatory by Mozilla (observatory.mozilla.org), Scanigma (scanigma.com), Stellastra (stellastra.com/tls-cipher-suite-check), OWASP PurpleTeam (purpleteam-labs.com) cloud.

Offline TLS configuration testing tools

Offline tools for testing TLS/SSL encryption: O-Saft (OWASP SSL advanced forensic tool), CipherScan (github.com/mozilla/cipherscan), CryptoLyzer (gitlab.com/coroner/cryptolyzer), SSLScan (github.com/rbsec/sslscan), SSLyze (github.com/nabla-c0d3/sslyze), testssl.sh, tls-scan (github.com/prbinu/tls-scan), OWASP PurpleTeam (purpleteam-labs.com) local.

WebSocket token refresh rotation long-lived connections hijacked sessions

Rotate tokens in long-lived connections to prevent hijacked sessions from persisting.

WebSocket Secure protocol WSS required for production

Never use unencrypted ws:// connections in production. Always use wss:// (WebSocket Secure) for all connections to prevent eavesdropping and tampering. The example shows: const socket = new WebSocket('wss://app.example.com/socket');

WebSocket protocol version RFC 6455 only

Only support RFC 6455 (the current WebSocket standard). Drop backward compatibility for outdated versions like Hixie-76 and hybi-00 which have known security vulnerabilities.

WebSocket compression perMessageDeflate disable for security

Disable permessage-deflate compression unless specifically needed. Compression can introduce security vulnerabilities similar to CRIME/BREACH attacks where compression combined with secret data can leak information. In Node.js: const wss = new WebSocket.Server({ perMessageDeflate: false });

WebSocket SameSite cookies CSWSH prevention

Use SameSite cookies (SameSite=Lax or SameSite=Strict) to prevent cross-site cookie transmission and strengthen Cross-Site WebSocket Hijacking (CSWSH) defenses.

WebSocket session expiration validation periodic re-validation

Close WebSocket connections when sessions expire. Re-validate user sessions periodically (every 30 minutes is a common interval) to ensure they remain valid. Example: function validateSession(ws, sessionId) { if (!isSessionValid(sessionId)) { ws.close(1008, 'Session expired'); return false; } return true; }

WebSocket logout close all user connections immediately

When users log out, close all their WebSocket connections immediately. Maintain a mapping of sessions to active connections so you can invalidate WebSocket access the moment logout occurs.

WebSocket message-level authorization check each action

Do not assume WebSocket connection equals unlimited access. Check authorization for each action during message processing. Example: ws.on('message', (data) => { const message = JSON.parse(data); if (message.action === 'delete_user' && !user.hasRole('admin')) { ws.send(JSON.stringify({type: 'error', message: 'Access denied'})); return; } });

WebSocket DoS protection connection limit per-user

Limit connections and resources by restricting total connections and implementing per-user limits (preferred) or per-IP limits where user identification isn't available.

WebSocket DoS protection message size limit maxPayload

Set message size limits, typically 64KB or less. In Node.js: const wss = new WebSocket.Server({ maxPayload: 64 * 1024 });

WebSocket DoS protection rate limiting message flooding

Implement rate limiting to prevent message flooding. A common starting point is 100 messages per minute.

WebSocket DoS protection idle timeout dead connections

Handle idle and dead connections by implementing idle timeouts to close inactive connections. Use heartbeat monitoring with ping/pong frames to detect and clean up dead connections.

WebSocket DoS protection backpressure flow control

Implement backpressure controls to prevent memory exhaustion from fast message producers. Many WebSocket implementations lack proper flow control, allowing attackers to overwhelm server memory by sending messages faster than they can be processed.

Node.js WebSocket verifyClient callback authentication origin checks

Node.js WebSocket framework best practice: Use the verifyClient callback for origin and authentication checks during handshake.

Node.js WebSocket maxPayload message size limit configuration

Node.js WebSocket framework best practice: Set maxPayload limits to prevent resource exhaustion from oversized messages.

Python Django Channels WebSocket authentication middleware origin validation

Python Django Channels best practice: Implement authentication middleware and origin validation. Use async exception handling to prevent application crashes from malformed WebSocket messages.

Java Spring WebSocket allowed origins configuration Spring Security

Java Spring best practice: Configure allowed origins explicitly and integrate Spring Security for authorization. Set message size limits in your WebSocket container configuration to prevent resource exhaustion.

Go Gorilla WebSocket CheckOrigin function validation not just return true

Go Gorilla WebSocket best practice: Implement validation in your CheckOrigin function - do not just return true. Set read limits, implement timeouts, and use context cancellation for graceful connection cleanup.

WebSocket service tunneling XSS attack risk VNC FTP SSH

WebSocket service tunneling for TCP services (VNC, FTP, SSH) creates security risks. If your application has XSS vulnerabilities, attackers could access these services directly from victims' browsers. If tunneling is necessary, implement additional authentication and access controls beyond the WebSocket layer.

WebSocket token-based authentication query string access logs exposure

For enhanced security, use token-based authentication instead of relying solely on cookies. Tokens can be passed in query strings but tokens will appear in access logs and should be redacted. Alternatively, pass tokens as part of WebSocket messages after connection establishment to avoid log exposure, but this requires protocol design considerations.

Web service client authorization requirements

A web service should authorize its clients whether they have access to the method in question. Following an authentication challenge, the web service should check the privileges of the requesting entity whether they have access to the requested resource. This should be done on every request, and a challenge-response Authorization mechanism added to sensitive resources like password changes, primary contact details such as email, physical address, payment or delivery instructions.

TLS required for all sensitive web service communication

All communication with and between web services containing sensitive features, an authenticated session, or transfer of sensitive data must be encrypted using well-configured TLS. This is recommended even if the messages themselves are encrypted because TLS provides numerous benefits beyond traffic confidentiality including integrity protection, replay defenses, and server authentication.

Server certificate validation requirements

The service consumer should verify that the server certificate is issued by a trusted provider, is not expired, is not revoked, matches the domain name of the service, and that the server has proven that it has the private key associated with the public key certificate by properly signing something or successfully decrypting something encrypted with the associated public key.

Basic Authentication over TLS not recommended

If used, Basic Authentication must be conducted over TLS, but Basic Authentication is not recommended because it discloses secrets in plain text (base64 encoded) in HTTP Headers.

Client Certificate Authentication using Mutual-TLS recommended

Client Certificate Authentication using Mutual-TLS is a common form of authentication that is recommended where appropriate for web service authentication.

Separate administrative access from web services

Ensure access to administration and management functions within the Web Service Application is limited to web service administrators. Ideally, any administrative capabilities would be in an application that is completely separate from the web services being managed by these capabilities, thus completely separating normal users from these sensitive functions.

gRPC token-based authentication best practices

Implement token expiration and refresh mechanisms with short-lived tokens (15-60 minutes). Avoid embedding credentials in gRPC method parameters; use metadata headers instead.

gRPC mutual TLS (mTLS) client configuration in Go

For mTLS client configuration in Go: load client certificate and key with tls.LoadX509KeyPair(clientCertFile, clientKeyFile), load CA certificate file, create certificate pool with x509.NewCertPool() and append PEM certs. Create TLS credentials with credentials.NewTLS(&tls.Config{Certificates: []tls.Certificate{cert}, RootCAs: caCertPool}). Establish connection with grpc.Dial(address, grpc.WithTransportCredentials(creds)).

gRPC mTLS certificate rotation

Use short-lived certificates of 90 days or less in mTLS deployments for service-to-service communication, with automated rotation to limit the impact of compromised keys.

gRPC JWT token validation interceptor in Go

Implement a unary server interceptor that retrieves metadata from incoming context with metadata.FromIncomingContext(ctx), checks for 'authorization' header, trims 'Bearer ' prefix, and validates the token. Return status.Errorf(codes.Unauthenticated, message) for missing or invalid tokens.

gRPC API key authentication in Go

Validate API keys by extracting metadata from context with metadata.FromIncomingContext(ctx), checking for 'x-api-key' header, and validating the key value. Return status.Error(codes.Unauthenticated, message) for missing or invalid keys.

gRPC role-based authorization in Go

Implement method-level authorization checks by maintaining a methodPermissions map that associates method names with required roles. For each request, retrieve user roles from context and check if any user role matches the required role for the method. Return status.Errorf(codes.PermissionDenied, message) when authorization fails.

OMB M-22-09 compliance with Zero Trust controls

Phishing-resistant MFA, device certificates, and encrypted DNS help meet OMB M-22-09 compliance requirements.

Zero Trust core principle: all authentication and authorization is dynamic and strictly enforced

Security decisions happen in real-time for every access request. Do not rely on static rules or permanent permissions. The system should automatically adjust access based on current risk levels, revoke access for compromised accounts, and isolate suspicious devices.

Zero Trust response to stolen credentials

Unlike traditional security that only resets password and adds basic MFA, Zero Trust uses continuous risk assessment, device verification, and behavioral analysis. Access can be denied even with valid credentials if risk is high.

User account management: review access regularly

Check who has access every quarter.

Zero Trust response to privileged account abuse

Use just-in-time access with automatic expiration and continuous monitoring instead of permanent admin rights with periodic reviews.

Give your agent this brain