AI Prompts for Implementing Authentication

Implement [signup/login] for [framework]. Security
requirements (non-negotiable):
- Hash passwords with bcrypt or argon2 (never plain, never
  fast hashes like MD5/SHA). Use an appropriate cost factor.
- Never log or return passwords or full tokens.
- Use constant-time comparison for secrets.
- [For sessions] use secure, httpOnly, sameSite cookies.
- [For JWTs] short-lived access tokens + refresh tokens,
  and explain where each is stored.
- Generic error on login failure ("invalid credentials"),
  never revealing whether the email exists.
Explain each security decision and any tradeoff.

Is the authentication code an AI just wrote for you actually secure, or does it only look secure? This is the question that should make you pause before shipping any generated auth. Authentication is the one area where "it works" and "it's safe" are dangerously different. Code that logs users in successfully can still store passwords insecurely, leak tokens, or leave sessions open to hijacking — and none of that shows up in a quick test. AI prompts for implementing authentication need to demand security explicitly, because the working version and the secure version look identical until someone attacks them.

Quick-Start (Copy This Right Now)

Here's an auth prompt that builds security in from the start:

Implement [signup/login] for [framework]. Security requirements (non-negotiable): - Hash passwords with bcrypt or argon2 (never plain, never fast hashes like MD5/SHA). Use an appropriate cost factor. - Never log or return passwords or full tokens. - Use constant-time comparison for secrets. - [For sessions] use secure, httpOnly, sameSite cookies. - [For JWTs] short-lived access tokens + refresh tokens, and explain where each is stored. - Generic error on login failure ("invalid credentials"), never revealing whether the email exists. Explain each security decision and any tradeoff.

What this does: It names the specific security requirements that generated auth skips by default — proper hashing, no leakage, constant-time comparison, safe error messages — so you get code that's secure, not just functional.

⚡ Pro tip: The line "generic error on login failure, never revealing whether the email exists" prevents user enumeration. If your login says "no such email" for unknown addresses and "wrong password" for known ones, an attacker can discover which emails are registered. One consistent message closes that hole.

Understanding the Variables

Each requirement in that prompt closes a specific, well-known attack vector.

Password hashing is the foundation. Passwords must never be stored in plain text, and they must be hashed with a slow, salted algorithm like bcrypt or argon2 — not a fast hash like MD5 or SHA-256, which attackers can brute-force at billions of guesses per second. The slowness is the point. Generated code sometimes reaches for fast hashes, which is a serious flaw.

No leakage covers logs, responses, and error messages. Passwords and full tokens should never appear in logs (which get shipped to monitoring tools) or in API responses. This leaks constantly in generated code that logs the whole request object for debugging.

Constant-time comparison defeats timing attacks. Comparing secrets with a normal equality check can leak information through how long the comparison takes. Constant-time comparison always takes the same time regardless of input, closing that subtle channel.

Cookie flags and token storage determine session security. httpOnly cookies can't be read by JavaScript, defeating a class of token-theft attacks. Where you store JWTs (memory, cookie, localStorage) has real security tradeoffs the model should explain.

⚠️ Common mistake: Storing passwords with a fast hash like SHA-256 or, worse, no hash at all. Fast hashes are designed for speed, which is exactly wrong for passwords — it means an attacker who steals your database can crack them quickly. Passwords need deliberately slow, salted hashing (bcrypt, argon2, scrypt). Always verify which algorithm generated auth code actually uses.

Step-by-Step: Building Secure Authentication

Follow this loop for auth you can trust.

Step 1 — State the security requirements first. Lead every auth prompt with the non-negotiable list above. Security named up front produces secure code; security as an afterthought produces afterthoughts.

Step 2 — Ask the model to explain its choices. Require a rationale for each security decision. If it can't explain why it chose bcrypt over SHA-256, that's a signal to look closer.

Step 3 — Run an adversarial self-review. After generating, ask the model to attack its own code:

Review this auth code as an attacker. List the top 5 ways to compromise it — credential attacks, token theft, session issues, enumeration — and fix each.

What this does: It reframes the model from author to attacker, surfacing vulnerabilities it wrote past the first time. This step catches a genuinely large share of auth flaws.

Step 4 — Verify against a known checklist. Cross-check the code against a trusted source like the OWASP Authentication Cheat Sheet. Generated code is a starting point for security-critical work, never the final word.

Step 5 — Never invent your own crypto. If the model writes custom encryption or token signing, stop. Use established libraries. Custom crypto is almost always broken in ways that aren't obvious.

⚡ Pro tip: The "review as an attacker" prompt is the highest-value step in secure auth generation. Models are good at finding vulnerabilities when explicitly asked to hunt, even in code they just wrote. It costs one extra prompt and catches issues a normal review misses.

Pro-Level Variations

For harder auth work, these variations help.

For JWT implementation, be specific about lifetimes and storage:

Implement JWT auth with 15-minute access tokens and 7-day refresh tokens. Explain where to store each on the client and the security tradeoff of that choice. Handle refresh token rotation and revocation.

What this does: It forces the model to address token lifetime, storage, and revocation — the three places JWT implementations commonly go wrong.

For OAuth integration, ask about the specific flow:

Implement Google OAuth using the authorization code flow with PKCE. Explain why PKCE matters and validate the state parameter to prevent CSRF.

For password reset, name the security pitfalls:

Implement password reset. Use single-use, expiring tokens. Don't reveal whether an email exists. Invalidate the token after use and after password change.

A security-conscious developer I know runs the "review as an attacker" prompt on every auth feature and says it's caught missing rate limits, tokens that didn't expire, and one reset flow that leaked whether emails existed — all in code that passed functional testing cleanly.

⚡ Pro tip: Always add rate limiting to authentication endpoints. Login, signup, and password reset endpoints without rate limits invite brute-force and abuse. Prompt for it explicitly — "add rate limiting to prevent brute-force attempts" — because it's rarely included by default.

Troubleshooting Common Issues

Passwords stored with a fast hash. Fix: require bcrypt or argon2 by name, and reject SHA/MD5 for passwords.

Tokens never expire. Fix: specify token lifetimes and require expiration handling. A token that lives forever is a permanent liability if stolen.

Login reveals whether an email exists. Fix: require a single generic error message for all login failures.

Secrets in logs. Fix: explicitly prohibit logging passwords, tokens, and full request bodies containing credentials.

Your Turn

Take your next auth feature, lead the prompt with the non-negotiable security list, and then run the "review as an attacker" prompt on whatever comes back. That two-step habit — demand security up front, then attack the result — catches the gap between working auth and secure auth.

The developers who ship auth they can defend aren't security experts; they've made security requirements a default in how they prompt, and they always verify against trusted sources. PromptABCD is where those requirements live — save your secure-auth checklist prompt, your attacker-review prompt, and your JWT and OAuth variants, then reuse them on every auth feature. Authentication is the worst place to cut corners and the best place to have your security requirements ready to paste. Because with auth, the code that merely works and the code that's actually safe look exactly alike until the day someone finds out they weren't.

The honest framing here is that AI is a genuinely useful starting point for auth but a dangerous finishing point. It knows the standard secure patterns — bcrypt, httpOnly cookies, token expiration — and will apply them when you ask. But it can also confidently produce subtly broken auth that passes every functional test, and you won't know the difference without security knowledge or a trusted reference to check against. Use the model to draft, use the attacker-review prompt to stress-test, and use an authoritative source like OWASP to verify. That three-layer approach gets you the speed of generation without betting your users' credentials on the model getting security right unsupervised.

⚡ Pro tip: For anything beyond a learning project, strongly consider a maintained auth library or service rather than hand-rolled auth, even AI-generated. Established providers have had their security reviewed by many experts over years. Prompt the model to compare "roll your own with these safeguards" against "use an established auth provider" for your specific case — the honest comparison often points toward the provider.

It's also worth being clear-eyed about where the real risk sits. Most auth breaches don't come from exotic cryptographic weaknesses; they come from boring, well-known mistakes — weak password hashing, missing rate limits, tokens that never expire, error messages that leak information. These are precisely the things the security checklist in this guide targets, and precisely the things a functional test won't catch. The good news is that because they're well-known, both the checklist and the attacker-review prompt catch them reliably. You don't need to be a cryptographer to ship safe auth; you need to be disciplined about the handful of mistakes that cause most of the damage. Be disciplined about the boring, common mistakes, and you close off the paths attackers actually use.