Revisiting Password-Based Login

Passwords have been a cornerstone of online security for decades, and they're not without their flaws. In this article we’ll explore how to make them as secure as possible.

Where Password Systems Often Fail

Traditional password systems often rely on methodologies that expose users to risks. Consider these common issues:

• Plaintext Passwords Over HTTPS: Even when transmitted via HTTPS, clear text passwords can be intercepted by proxies, firewalls, browser network inspection (e.g. at an Internet Café) or malicious administrators. Even your Google account password is sent in clear-text over HTTPS, that’s how common it is.
• Replay Attacks: Some systems send a hashed password instead of plaintext, but attackers can use the hash in a playback attack to impersonate the user. But at least they can’t see your password easily.
• Phishing and User Habits: Repetitive password prompts condition users to treat login dialogues as routine, making them easy targets for phishing tools like EvilGinx2. Even two-factor authentication (TFA) can be bypassed by replaying captured credentials.

A Secure Login Architecture

At Homebase, we’ve engineered an approach to password-based login that integrates modern cryptographic practices while addressing common security pitfalls. Here’s a detailed technical walk-through of how it works:

The Homebase Password Login process is structured to prioritize security at every step. Here’s a high-level overview of how it works:

Request a Nonce: The client begins by requesting a Random Nonce Package from the host over HTTPS. Since the user-name is the domain we know for certain that we’re talking with the right host.

Calculate and Send Password Reply: Using the nonce from the host and user password entered in the browser, the browser calculates a secure password reply and sends it back to the host.

Validate and Authenticate: The host validates the reply, decrypts the reply, and securely establishes the session.

Step 1: The Random Nonce Package

When the Homebase owner client requests a login, the host generates a Nonce Package. This data is used subsequently in step 2 and contains the following components:

Field Type Description

Nonce64 string A base64-encoded string of 16 random bytes for the client to use in calculations.

SaltPassword64 string A base64-encoded salt for password hashing.

SaltKek64 string A base64-encoded salt for deriving the Key Encryption Key (KEK).

PublicJwk string The host’s ECC-384 public key in JWK (JSON Web Key) format.

CRC uint32 A CRC32C checksum of the public JWK to ensure key integrity.

This nonce package ensures every login attempt is unique, preventing replay attacks.

Step 2: Calculating the Password Reply

Using the password entered by the user and the nonce package, the client calculates a Password Reply. This reply includes the following:

Field Type Description

Nonce64 string The original nonce from the server.

NonceHashedPassword64 string A nonce-hardened hash of the salted password.

PublicKeyJwk string The client’s ECC-384 public key for secure communication.

CRC uint32 The CRC32C checksum of the server’s public JWK.

GcmEncrypted64 string A GCM-encrypted payload containing:

- Hashed Password: Derived using PBKDF2 and SaltPassword64.

- Key Encryption Key (KEK): Derived using PBKDF2 and SaltKek64.

- Secret: A unique random value for secure session management.

The reply is securely encrypted using the host’s (verified) ECC public key, ensuring confidentiality and integrity. Hereafter the reply is sent over HTTPS to the host.

Step 3: Host Validation and Session Establishment

When the host receives the password reply, it validates and processes the data:

Nonce Validation: The host computes the expected NonceHashedPassword64 and compares it with the received value. A mismatch means login failure.

Payload Decryption: Using ECC and AES-GCM, the host decrypts the GcmEncrypted64 payload and derives the KEK.

Session Establishment: If validation succeeds, the host issues:

• Session Cookies: Secure HTTP-only cookies containing a session ID and half-key.
• Shared Secret: Stored securely on the client for future authentication.

This approach ensures robust session security, even if a single layer is compromised.

Beyond Passwords: Tackling Common User Issues

We’ve also addressed usability concerns that plague traditional systems:

• Unique Login Dialogues: Homebase uses visually distinct dialogues for new device logins and sensitive password confirmations, reducing phishing risks.
• Persistent Sessions: Once logged in, users rarely need to re-enter their password, as session cookies don’t expire unnecessarily. Thus, we avoid password dialog fatigue.
• User Awareness: Password confirmation screens display user-specific images, making phishing attempts obvious to even inattentive users.

Tokens: A Versatile Mechanism

Session tokens are at the heart of Homebase’s communication. These tokens encapsulate:

• ID: A unique session identifier.
• Half-Key: A cryptographic key for additional security.
• Shared Secret: An encrypted value used for verifying session integrity.

This tokenized approach extends seamlessly to:

• Owner Tokens: For managing a user’s session.
• App Tokens: For inter-service communication (e.g., chat or photos).
• Grant Tokens: For secure identity exchange between users.

The Future of Password-Based Login

While passwords remain a necessity for now, the Homebase architecture paves the way for a password-less future via the YouAuth protocol. With advanced cryptographic techniques, thoughtful user experience design, and robust tokenization, we’re redefining what password-based login can achieve in the long run. This means that in Homebase you don’t need to enter your password when logging into chat, photos, etc. because all these logins happen via YouAuth. You only need to use your password when logging in to the owner-console.

The next time you log in, know that your security is our top priority.