How to secure your authentication using nonces

Introduction

Nobody wants to get hacked, right?

Just imagine someone walking into your bank and claiming to be you, or worse, someone accessing your personal data by pretending to be your trusted application. When authentication goes wrong, it's not just about losing data—it's about losing trust, money, and sometimes even your reputation.

A single-pass barcode to protect our system

What if we had something that could only be used once so the server knows that this request has been made before? Just like a concert ticket with a unique barcode becomes useless once you've used it to enter. This simple idea helps us catch anyone trying to replay old requests to trick our system. This concept is called nonces or "Number used once" and we're going to learn exactly that.

Understanding Nonces

What is a nonce?

A nonce is a random or pseudo-random number that can only be used once within a cryptographic communication. Nonces are mostly used to preventing replay attacks, where an attacker intercepts a valid request and tries to send it again to gain unauthorised access.

Think of it as giving each request a unique fingerprint that the server can remember and reject if it sees the same fingerprint twice. This way, even if someone captures your login request, they can't simply replay it because the nonce makes each request unique and time-sensitive.

Where do we see Nonces?

Beyond simple prevention of replay attacks, you might see nonces at different places:

• API Authentication and OAuth2: Nonces help maintain session integrity and freshness of a request.

• Blockchain based transactions: Nonces prevent double spending attacks.

• Password reset tokens & multi-factor authentication: depend on nonces or nonce-like mechanisms.

Building a Secure Authentication System

Why not go with traditional authentication?

Traditional authentication systems (and many systems even now) typically work in a straightforward manner where

• Client sends credentials to the server, and

• Server responds with a token or session identifier if the credentials are valid.

Traditional systems treat each request independently without any mechanism to detect if the same request has been sent before. This creates a possibility where an attacker can intercept a valid authentication request and replay it multiple times to gain unauthorised access.

Consider a mobile banking app that sends your login credentials over HTTPS. While the transport is encrypted, if an attacker captures the encrypted request, they can replay it later when you're offline to get the credentials from your bank and access your account. The bank server has no way to distinguish between your legitimate login attempt and the attacker's replay because both requests look identical.

Introducing Nonces into the Authentication Process

To solve the above problem, a nonce gets introduced at the very beginning of the authentication handshake, before any sensitive credentials are exchanged between the client and server. Here's exactly how it works:

1. When a client wants to authenticate, it first makes a request to the server asking for a fresh nonce, and the server generates a unique, time-limited number and sends it back to the client.

2. The client then takes this nonce, combines it with their credentials (often through hashing or signatures), and sends this combined package back to the server for verification.

3. The server checks both the validity of the credentials and ensures that the nonce hasn't been used before and hasn't expired, effectively creating a two-factor verification system.

This process transforms each authentication attempt into a unique, non-replayable event because even if an attacker captures the entire exchange, the nonce expires and becomes useless for future attempts.

Implementing Nonces

Generating Nonces Securely

A secure nonce must be unique and unpredictable. The most reliable approach involves using a timestamp (uniqueness), combined with random elements (unpredictability). Epoch timestamps work exceptionally well for nonce generation because they naturally provide uniqueness over time—no two requests can have the exact same timestamp down to the millisecond. However, using timestamps alone would make nonces predictable, which is why we need to add a random component to them.

// Function to generate a nonce (a pseudo-random set of digits)
const generateNonce = () => {
    const currentTimeStamp = Date.now();
    const randomThreeDigits = Math.floor(Math.random()*900) + 100; // always ensures a 3-digit number
    return `${currentTimeStamp}${randomThreeDigits}`;
};

This combination creates nonces that are mathematically unique across time and computationally unpredictable, giving your authentication system both reliability and security.

Ensuring Communication Security

Combine nonces with the payload to create a unique package

The most effective approach is to create a hash (also called a fingerprint) that incorporates both the actual payload and the nonce, making replay attacks impossible even if the hash itself is compromised, as nonces are unique and can be used only once, and so is the hash. Here's how to implement secure credential hashing with nonces:

const crypto = require('crypto');

// Utility: creates a hash
function createSecureHash(password, nonce, salt) {
    // Combine password, nonce, and salt for maximum security
    const combined = `${password}:${nonce}:${salt}`;

    // Use SHA-256 for hashing
    const hash = crypto.createHash('sha256')
        .update(combined)
        .digest('hex');

    return hash;
}

// Utility: generates a nonce
function generateNonce() {
    const currentTimeStamp = Date.now();
    const randomThreeDigits = Math.floor(Math.random()*900) + 100; // always ensures a 3-digit number
    return `${currentTimeStamp}${randomThreeDigits}`;
}

// Example usage on client side
function authenticateUser(username, password) {
    const nonce = generateNonce();
    const salt = 'your-app-specific-salt'; // Should be unique per application
    const passwordHash = createSecureHash(password, nonce, salt);

    return {
        username,
        passwordHash,
        nonce
    };
}

This approach ensures that even if an attacker captures the hash, they can't reuse it because the nonce changes with each request, making the hash completely different every time.

In traditional authentication requests, the credentials (username and hashed password) are sent directly to the backend without a nonce. A hacker need not know your password to hack you, but they just need the entire HTTP request (maybe via the cURL or something) to replay the authentication request and mimic you.

After using nonces, for a hacker to be able to ‘hack’ your account, they need to know your exact password now. Therefore, nonces have reduced a layer of vulnerability by adding another security layer.

Some things to keep in mind!

Effective Key Management and Rotation

Rotate your nonce generation keys every 30-90 days and never store them in your application code. Set up automated alerts when keys are about to expire so your authentication system doesn't suddenly break in production.

Managing State with Nonces

Store used nonces in a fast database like Redis with automatic expiration to prevent memory bloat, and always check if a nonce has been used before accepting any authentication request.

Handling UX and debugging

Set nonce expiration times between 5-10 minutes to balance security with user experience. Log nonce generation and validation events (never log the actual nonce values) to help troubleshoot authentication issues in production.

Conclusion

We've journeyed from understanding the fundamental vulnerability of replay attacks to implementing a complete nonce-based authentication system that transforms your application from a sitting duck into a fortress that knows the difference between legitimate users and malicious imposters.

A few extra lines of code and infrastructure setup you invest in nonces today could save you from the nightmare of explaining to users why their data was compromised tomorrow, so make security a priority from day one, not an afterthought when it's too late.

Catch you in the next one.
Goodbye!