Stop Storing Password Hashes: I Built a "Zero-Storage" Auth System for the AI Era

A passwordless authentication system where the server knows absolutely nothing about your users. Zero honeypots, zero breaches, zero regrets.

---

I built an authentication system where the server stores zero secrets. No password hashes, no emails, no recovery tokens. The server only knows a user_id derived from the user's master_secret, and authentication is proven cryptographically via HMAC. If the database is breached, there's literally nothing to steal.

---

🔥 The Problem: Your Auth Database is a Ticking Time Bomb

Let's be brutally honest about modern authentication:

Every authentication system is a honeypot.

Even with Argon2id, bcrypt, or scrypt, you're still storing:

• Password hashes (crackable with enough GPU power)
• Email addresses (for credential stuffing attacks)
• Password reset tokens (if stolen, game over)
• Session tokens (if leaked, instant access)

The AI Multiplier

In 2026, AI has made this 10x worse:

1. Pattern Recognition: AI can cross-reference leaked databases in seconds, finding correlations humans would miss
2. Smart Dictionary Attacks: AI generates context-aware password guesses based on user profiles
3. Automated Credential Stuffing: AI tests millions of leaked credentials across platforms simultaneously
4. Social Engineering: AI crafts personalized phishing attacks using leaked data

The uncomfortable truth: If a hacker gets your database, it's not a matter of if they'll exploit it, but how fast.

The Real Question

What if we could build an auth system where there's nothing to steal?

---

💡 The Solution: CryptoLogin - Zero-Storage Authentication

The time is now ripe for it

CryptoLogin uses a challenge-response mechanism inspired by Zero-Knowledge principles.
The server never stores your secret. Your secret never leaves your device.

---

I built CryptoLogin, an authentication system based on a radical principle:

The server should never know anything about the user that the user doesn't explicitly share.

Core Principles

1. No secrets on the server - No password hashes, no emails, no recovery tokens
2. Client-side derivation - The user_id is derived locally from the master_secret using PBKDF2
3. HMAC-based authentication - The client proves knowledge of the master_secret via cryptographic signature
4. Zero-knowledge flow - The master_secret never leaves the browser

What the Server Actually Stores

-- That's it. Just a user_id and some metadata.
CREATE TABLE users (
    user_id TEXT PRIMARY KEY,        -- 64-char hex, derived from master_secret
    user_data TEXT,                  -- Optional JSON metadata
    created_at TEXT,
    updated_at TEXT,
    last_activity_at TEXT,
    challenge TEXT                   -- Temporary, for active login sessions only
);

No passwords. No emails. No secrets. If this database is breached, the attacker gets... a bunch of random-looking hex strings. Useless.

---

🔐 How It Works: The Zero-Knowledge Flow

The Cryptographic Flow

┌──────────┐                              ┌──────────┐
│  Client  │                              │  Server  │
└────┬─────┘                              └────┬─────┘
     │ 1. Derive user_id from master_secret    │
     │    (PBKDF2-SHA512, 100k iterations)     │
     │                                         │
     │ 2. POST /auth/login/init {user_id}      │
     │ ──────────────────────────────────────► │
     │                                         │ 3. Generate challenge
     │    4. Return challenge                  │
     │ ◄────────────────────────────────────── │
     │                                         │
     │ 5. Compute HMAC(challenge, user_id)     │
     │                                         │
     │ 6. POST /auth/login/verify              │
     │    {user_id, hmac}                      │
     │ ──────────────────────────────────────► │
     │                                         │ 7. Verify HMAC
     │    8. Return session                    │
     │ ◄────────────────────────────────────── │
     │                                         │
     ✅ Authenticated                          ✅ Session created

Why This is Secure

1. The master_secret never leaves the browser - It's only used locally to derive user_id and compute HMAC
2. The server can't impersonate the user - It doesn't know the master_secret, only the derived user_id
3. Replay attacks are impossible - Each challenge is single-use and expires after login
4. Database breaches are harmless - The attacker gets user_id values, which are useless without the master_secret

The Cryptographic Standards

Component	Algorithm	Purpose
Key Derivation	PBKDF2-SHA512 (100,000 iterations)	Derive user_id from master_secret
Authentication	HMAC-SHA256	Prove knowledge of master_secret
Comparison	Constant-time comparison	Prevent timing attacks

No custom crypto. Everything uses industry-standard algorithms via the Web Crypto API (browser) and Python's hashlib/hmac (server).

---

🚀 Integration in 5 Minutes

Backend (Python/Flask)

pip install cryptologin

from flask import Flask, request, jsonify
from cryptologin import CryptoLogin
from cryptologin.core.user_manager_v2 import UserManagerV2
from cryptologin.storage.sqlite_v2 import SQLiteStorageV2

app = Flask(__name__)

# Initialize CryptoLogin
storage = SQLiteStorageV2(db_path="auth.db", auto_migrate=True)
user_manager = UserManagerV2(storage=storage)

@app.route('/auth/register_v2', methods=['POST'])
def register():
    data = request.json
    user_id = data['user_id']  # Derived client-side from master_secret
    user_manager.register_user_v2(user_id, data.get('user_data', {}))
    return jsonify({"success": True, "user_id": user_id})

@app.route('/auth/login/init_v2', methods=['POST'])
def login_init():
    data = request.json
    user_id = data['user_id']
    challenge = user_manager.initiate_login_v2(user_id)  # Returns plaintext challenge
    return jsonify({"challenge": challenge})

@app.route('/auth/login/verify_v2', methods=['POST'])
def login_verify():
    data = request.json
    user_id = data['user_id']
    hmac_response = data['challenge_response']  # HMAC from client

    session = user_manager.complete_login_v2(user_id, hmac_response)
    return jsonify({
        "session_id": session.session_id,
        "user_id": session.user_id,
        "expires_at": session.expires_at.isoformat()
    })

Frontend (JavaScript)

npm install cryptologin-client

import { createClient } from 'cryptologin-client';

// Initialize the client
const client = createClient({
  baseURL: 'https://api.yourapp.com/v1',
  timeout: 30000
});

// Registration (user provides master_secret)
async function register(masterSecret) {
  // SDK derives user_id automatically
  const userId = await client.register(masterSecret, {
    name: 'John Doe',
    email: '[e-mail]'  // Optional metadata
  });
  console.log('Registered:', userId);
}

// Login (user provides master_secret)
async function login(masterSecret) {
  // SDK handles everything:
  // 1. Derives user_id
  // 2. Gets challenge from server
  // 3. Computes HMAC locally
  // 4. Sends HMAC to server
  const session = await client.login(masterSecret);
  console.log('Logged in:', session.sessionId);
}

// Usage
const masterSecret = 'my-super-secret-passphrase-min-32-chars';
await register(masterSecret);
await login(masterSecret);

That's it. The SDK handles all the cryptography. You just pass the master_secret.

---

⚠️ The Brutal Truth: Trade-offs

I'm not going to sell you a fantasy. CryptoLogin is not for everyone.

What You Lose

❌ No "Forgot Password" flow - If the user loses their master_secret, they're locked out forever. The server can't help because it doesn't know the secret.

❌ No email-based recovery - Since we don't store emails, there's no way to send recovery links.

❌ User responsibility - Users must store their master_secret securely (password manager, hardware key, etc.)

What You Gain

✅ Zero breach risk - If your database is leaked, there's nothing to exploit
✅ No password hashing costs - No CPU-intensive bcrypt/Argon2 on every login
✅ Simplified compliance - No password storage = no PCI-DSS/GDPR headaches for credentials
✅ True user sovereignty - Users own their authentication completely

Who Should Use CryptoLogin?

✅ High-security applications - Financial apps, healthcare, enterprise tools
✅ Privacy-focused products - Where users demand zero-knowledge architecture
✅ Developer tools - Where users are technical enough to manage a master_secret
✅ Decentralized apps - Where server-side secrets are an anti-pattern

❌ Consumer apps with non-technical users - If your users will forget their password, this isn't for you
❌ Apps requiring email recovery - If you need "Forgot Password", stick with traditional auth

The Bitcoin Analogy

CryptoLogin works like a Bitcoin wallet:

"Not your keys, not your crypto."

"Not your master_secret, not your account."

It's the ultimate trade-off: Absolute security vs. Convenience. You choose.

---

📊 Performance & Testing

Test Coverage

✓ tests/crypto.test.js (18 tests)
  ✓ deriveUserId (5 tests)
  ✓ computeHmac (5 tests)
  ✓ isValidUserId (4 tests)
  ✓ generateChallenge (4 tests)

✓ tests/client.test.js (8 tests)
  ✓ constructor (4 tests)
  ✓ session management (4 tests)

Test Files  2 passed (2)
     Tests  26 passed (26)

Performance Benchmarks

Operation	Time	Notes
deriveUserId	~150ms	PBKDF2 with 100k iterations
computeHmac	~1ms	HMAC-SHA256 is fast
Full login flow	~200ms	Network + crypto

Note: The 150ms for deriveUserId is intentional. It's a security feature, not a bug. Slow key derivation makes brute-force attacks expensive.

---

🎯 Real-World Demo

I've deployed a live demo where you can test CryptoLogin right now:

🔗 Live Demo: https://erabytse.github.io/cryptologin-website/demo_v2.html

Try it:

1. Enter a master_secret (minimum 32 characters)
2. Click "Register"
3. Click "Login"
4. Watch the HMAC-based authentication in action

The demo connects to a real API endpoint: https://api.docudeeper.com/api/v1

---

🔗 Links & Resources

Packages

• Python SDK (Server): cryptologin on PyPI
• JavaScript SDK (Client): cryptologin-client on npm

Source Code

• Backend (Python): github.com/erabytse/CryptoLogin
• Frontend (JavaScript): github.com/erabytse/cryptologin-client
• Demo Website: github.com/erabytse/cryptologin-website

Documentation

• Website: https://erabytse.github.io/cryptologin-website/
• API Docs: See README on GitHub repos

---

🤝 Contributing

CryptoLogin is open-source under the MIT License. Contributions are welcome!

Areas where we need help:

• 🧪 More test coverage
• 📚 Documentation improvements
• 🔌 SDKs for other languages (Rust, Go, PHP)
• 🎨 UI/UX improvements for the demo

---

💬 Final Thoughts

Authentication doesn't have to be a compromise between security and usability. With CryptoLogin, we've proven that you can build a system where:

1. The server knows nothing about the user's secret
2. Authentication is cryptographically proven via HMAC
3. Database breaches are harmless because there's nothing to steal
4. Integration is trivial thanks to well-designed SDKs

Is it for everyone? No. But for the right use case, it's a game-changer.

The future of auth isn't about building better honeypots. It's about removing the honey.

---

If you found this useful, give the repos a ⭐ on GitHub and share it with your network. Let's build a more secure web, one zero-knowledge system at a time.

Questions? Drop them in the comments. I read everything.

---

Built with ❤️ by erabytse

Reinventing Authentication. One Secret at a Time.

A quiet rebellion against digital waste.