Why Your AI-Generated Auth Flow Is Probably Broken (Part 4)

Auth is the part of your app where "close enough" gets you owned. It's also the part LLMs are worst at, because the mistakes look identical to the correct version until someone actually attacks them.

Here's what we find during audits.

The password hash that isn't

We see this a lot:

import crypto from 'crypto';

const hash_password = (password) => {
  return crypto.createHash('sha256').update(password).digest('hex');
};

That is not a password hash. That is a fingerprint. It has no salt, no work factor, and it can be reversed with a rainbow table older than the developer who wrote it.

Passwords must be hashed with a slow, salted, memory-hard function. Anything else is a database dump waiting to be posted on a forum. OWASP, Password Storage Cheat Sheet

Use bcrypt, argon2, or scrypt. Nothing else.

Session cookies with no expiry

response.cookie('session_id', session_id, {
  httpOnly: true,
});

No secure. No sameSite. No maxAge. That cookie lives forever, travels over HTTP, and is happy to be sent along with a cross-site POST.

The version you actually want:

response.cookie('session_id', session_id, {
  httpOnly: true,
  secure: true,
  sameSite: 'lax',
  maxAge: 1000 * 60 * 60 * 24 * 30,
  path: '/',
});

"Magic link" endpoints that are actually admin bypasses

If your magic-link endpoint accepts an email in the query string and logs that user in without any token verification, you don't have a magic link. You have a "log in as anyone" button.

The rule

The token in a magic link must be:

• Single-use
• Time-limited (15 minutes is fine, 24 hours is not)
• Bound to the email address it was issued for
• Verified server-side against a hashed value in your database

Password reset without invalidating sessions

When a user resets their password because they think they were hacked, and your app doesn't invalidate every other session for that user, they are still hacked.

What to actually do

1. Use a real auth library. Don't write it yourself and don't let an LLM write it for you.
2. Rotate session IDs on privilege change (login, password change, email change).
3. Rate limit login, signup, and password reset endpoints per-IP and per-account.
4. Log every auth event. You will need it during the incident.

Auth is one of the three things we always check first during a Fortivibe audit. The other two are billing and file uploads, for the same reason: they're where money and data actually leave the building.