HTTPS Login Security: Don’t Send Passwords!

TL;DR

Sending usernames and passwords with every HTTPS request is a very bad idea. It’s insecure, unnecessary, and easily exploitable. Use session cookies or tokens instead.

Why Sending Credentials With Every Request Is Dangerous

While HTTPS encrypts the data in transit, repeatedly sending login details exposes you to several risks:

• Increased Attack Surface: More opportunities for interception, even with HTTPS.
• Log File Exposure: Logs on servers (web server, application server) could accidentally record passwords if not properly configured.
• Browser History Risks: Passwords can end up in browser history files.
• Man-in-the-Middle Attacks: Although HTTPS helps prevent this, misconfigurations or compromised certificates weaken the protection.
• Replay Attacks: An attacker intercepting a request could potentially reuse those credentials.

How to Securely Handle Login Information

The correct way is to authenticate once and then maintain that authentication without repeatedly asking for login details.

1. Authentication Process

1. User Logs In: The user enters their username and password on a secure (HTTPS) page.
2. Server Verifies: The server checks the credentials against its database.
3. Session Creation: If valid, the server creates a session for the user. This session is identified by a unique ID.
4. Session Cookie/Token: The server sends this session ID back to the user’s browser as an HTTP cookie or in a token (e.g., JWT).

2. Subsequent Requests

For every following request, the browser automatically includes the session cookie/token.

• No Password Needed: The server uses the session ID to identify the user without needing their password again.
• Cookie Security: Ensure cookies are marked as Secure (only sent over HTTPS) and HttpOnly (not accessible via JavaScript).

# Example cookie settings in PHP

setcookie('session_id', $session_id, [ 'secure' => true, 'httponly' => true]);

3. Session Management

• Session Expiration: Sessions should have a limited lifetime to reduce the impact of stolen session IDs.
• Session Regeneration: Regenerate the session ID after login and periodically during use. This prevents session fixation attacks.
• Invalidation on Logout: Properly destroy the session when the user logs out.

4. Tokens (e.g., JWT)

JSON Web Tokens (JWTs) are another option, particularly for APIs or stateless applications.

• Token Creation: After successful login, the server creates a signed JWT containing user information.
• Token Storage: The token is sent to the client and stored (e.g., in local storage).
• Authorization Header: Subsequent requests include the token in the Authorization header.

# Example Authorization header

Authorization: Bearer <your_jwt_token>

Checking for Incorrect Implementation

1. Browser Developer Tools: Use your browser’s developer tools (Network tab) to inspect the requests. Look for username/password fields in the request payload after login.
2. Server Logs: Check server logs for any accidental recording of passwords.
3. Code Review: Carefully review authentication code to ensure it’s not sending credentials with every request.