Team Menu Makers – Feedback Needed on Our Login System (Security + UX Best Practices)

[Ramesh-kumawat]

Discussion Type

Product Feedback

Discussion Content

Hi everyone! 👋
We are Team Menu Makers, a student development team working on an app that requires a secure and user-friendly login system. We want to make sure our design follows industry standards, so we are looking for feedback from experienced developers.

✅ What We Have Implemented So Far

Email + password login

Password hashing using bcrypt

Token-based authentication with JWT

Basic role-based access (user/admin)

Input validation on both frontend and backend

Secure user storage (no plain-text passwords)

Error handling for invalid login attempts

❓ Where We Need Help

1. Security

Should we switch from bcrypt to Argon2 for password hashing?

Best way to securely store and rotate JWT refresh tokens

Recommended strategies to prevent brute-force attacks

Should we implement rate limiting or account lockout?

2. System Architecture

Should authentication be separated into its own microservice?

Suggestions for a clean folder structure for auth modules

Best practices for managing secrets (environment variables, vaults, etc.)

3. User Experience

Should we add password strength meters?

Is two-factor authentication worth implementing at this stage?

Tips for making the login process simple and intuitive

📘 Tech Stack

Node.js / Express

JWT

PostgreSQL

TypeScript + Vite (frontend)

🙏 Why We’re Asking

We (Team Menu Makers) are required to gather feedback from real developers as part of our weekly learning and design improvement task.
Your advice will help us improve security, optimize our architecture, and write better documentation.

[suman-ac]

Hi Team Menu Makers 👋
You’ve built a solid foundation so far. Here’s some focused feedback that may help strengthen the next iteration of your login system:

🔐 Security

bcrypt → Argon2id is a good upgrade since it’s more resistant to GPU-based cracking.

Store refresh tokens in HTTP-only Secure cookies and use token rotation with server-side invalidation.

Add IP rate limiting + short temporary lockouts for repeated failures. Avoid long lockouts to prevent DoS issues.

Store secrets in a secured vault (AWS Secrets Manager, Vault, Doppler) instead of plain .env in production.

🏗️ Architecture

Keeping auth inside the main backend is fine at this stage. A microservice only makes sense if your app grows significantly.

Suggested structure:

src/
modules/auth/
controller.ts
service.ts
routes.ts
utils.ts

🎨 UX

A password strength meter (zxcvbn) is a simple improvement.

2FA (TOTP) is a great addition if time allows — it’s realistic and easy to justify.

Keep the login UI minimal: clear error messages, “show password” toggle, and simple flows.

Overall, you’re on the right path. These adjustments will help elevate your system closer to real-world production standards. Let me know if you'd like help formatting this further or adapting it to your team’s documentation.

[Ramesh-kumawat]

Thanks a lot for the helpful feedback! 🙌
We’ll be adding these improvements in future versions, including switching to Argon2id, using HTTP-only cookies for refresh tokens, implementing rate limiting, and improving our auth folder structure. We also plan to add a password strength meter and possibly 2FA later on.

Really appreciate your guidance — it will help us refine our login system!

[simiranjeet]

Looks great so far! One additional tip:
Use a library like zod or yup for schema validation.
This ensures you validate:
• email format
• password length
• SQL injection protection
• no empty fields
Also, log all failed authentication attempts (without storing credentials).
It helps track suspicious activity.
Keep going — you’re on the right path!

[Ramesh-kumawat]

Thanks for the tip! We’ll definitely look into using Zod for schema validation to make our input checks more consistent and safer. We also plan to start logging failed login attempts so we can track suspicious activity without storing sensitive data.

Appreciate the guidance — this will really help us tighten our authentication flow! 🚀

[nitin0793]

From a UX point of view, here are suggestions: • Add a password strength indicator — users understand instantly how secure their chosen password is. • Provide show/hide password toggle to reduce login frustration. • Error messages should: ◦ avoid revealing details (“incorrect email or password” is safer) ◦ be friendly and helpful • Consider adding optional 2FA using an email OTP — it’s simple and adds huge security value. Your UI decisions will directly affect user trust, so keep it clean and intuitive.

[mainalim]

Thanks for the helpful feedback! I agree that adding a password strength indicator, a show/hide password option, and clearer error messages will improve the user experience. The suggestion for optional 2FA with email OTP is great—I’ll definitely explore adding it. I appreciate your insights and will work on applying these improvements!

[jatinder-sondh]

Thanks for the UX suggestions! We’ll be adding a password strength indicator and a show/hide password toggle to make login easier. We’ll also improve error messages to be clear but safe, and we plan to explore optional email OTP 2FA for added security.

Your advice will definitely help us make our login system more user-friendly and trustworthy! 🚀

[mecodeatlas]

Thanks for posting in the GitHub Community, @Ramesh-kumawat!

We're happy you're here. You are more likely to get a useful response if you are posting your question in the applicable category, the Discussions category is solely related to conversations around the GitHub product Discussions. This question should be in the Programming Help category. I've gone ahead and moved it for you. Good luck!

[MUKILAN0608]

Team Menu Makers has implemented a solid authentication foundation using bcrypt, JWT, RBAC, and proper validation. Below are key recommendations for improvement:

Security

bcrypt is acceptable; design hashing logic to allow future migration to Argon2 if needed.

Store hashed refresh tokens in the database and use HttpOnly, Secure cookies.

Implement refresh token rotation and revocation.

Add rate limiting and temporary lockouts to prevent brute-force attacks.

Use generic login error messages and enable audit logging.

Architecture

Keep authentication within the same backend as a modular component; a separate microservice is not required at this stage.

Follow a clean module-based folder structure for maintainability.

Manage secrets via environment variables and a secrets manager in production.

User Experience

Add a password strength meter.

Consider optional 2FA as a future enhancement.

Keep the login UI minimal, accessible, and non-revealing of account existence.

Your current implementation already aligns well with industry practices. With these refinements, it will reach near production-grade standards.

[Dev-x777]

Hey guys! cool to see students building proper auth systems early on 👏 your setup already looks solid (bcrypt + JWT + RBAC etc), so nice job there.

Some quick thoughts from my side:

Security

bcrypt is fine tbh, but yea Argon2 is kinda more modern and recommended lately (memory hard, better protection against GPU attacks). You can switch if it’s easy right now, otherwise bcrypt still acceptable.

Refresh tokens should NOT sit in localstorage. Better in httpOnly cookies, and rotate on every refresh. Keep a DB table to blacklist/track old tokens.

Definitely add rate limiting. Account lockout after like 5–7 failed attempts or gradual cool-down helps against brute force.

IP throttling + captcha after too many retries could be nice later.

Architecture

Microservice only if you expect scaling later. For now monolith auth module is fine, simpler to maintain.

Separate auth into its own folder with:

/auth
/controllers
/routes
/services
/middleware
/utils

Keeps things clean.

Secrets → .env, but not committed. If production later use Vault/AWS Secrets/Cloud KMS.

UX

password strength meter? good idea, users get clarity.

2FA maybe later, once you have a stable userbase. Adds friction now but huge trust factor.

Keep login form simple as possible, avoid too much data entry.

Overall you're going in the right direction. Good work!
Would love to see how you implement refresh token rotation later.

Keep it up Menu Makers 🚀

[abhi3114-glitch]

Great work so far, Team Menu Makers! Your implementation already covers many important security fundamentals. Here's my feedback on each of your questions:

---

Security

1. Bcrypt vs Argon2

Stick with bcrypt for now. Here's why:

• Bcrypt is battle-tested, widely supported, and perfectly secure for most applications
• Argon2 is theoretically better (won the Password Hashing Competition in 2015), but the practical difference is minimal for a student project
• When to consider Argon2: If you're handling extremely sensitive data (financial, healthcare) or if you want to learn cutting-edge tech

Recommendation: Use bcrypt with a cost factor of 12-14. If you want to impress evaluators, mention you considered Argon2 and explain the tradeoffs.

2. JWT Refresh Token Storage & Rotation

Best practices:

// Store refresh tokens in database with metadata{userId: "123",refreshToken: "hashed_token",expiresAt: Date,deviceInfo: "User-Agent string",createdAt: Date,lastUsed: Date}

Rotation strategy:

• Issue a new refresh token every time the old one is used
• Invalidate the old token immediately
• If an invalidated token is reused → security breach detected, revoke ALL user tokens

Storage:

• HttpOnly, Secure cookies (best for web apps)
• localStorage (vulnerable to XSS attacks)
• Store access tokens in memory (short-lived, 15 mins)
• Store refresh tokens in HttpOnly cookies (longer-lived, 7 days)

3. Preventing Brute-Force Attacks

Multi-layered approach:

// Option 1: express-rate-limit (simple)importrateLimitfrom'express-rate-limit';constloginLimiter=rateLimit({windowMs: 15*60*1000,// 15 minutesmax: 5,// 5 attemptsmessage: 'Too many login attempts, please try again later'});app.post('/login',loginLimiter,loginController);

// Option 2: Account-level lockout (more sophisticated)// Track failed attempts in database{email: "[email protected]",failedAttempts: 3,lockedUntil: Dateornull}// Lock account after 5 failed attempts for 30 minutes// Reset counter on successful login

Best approach: Combine both!

• Rate limiting by IP (stops automated attacks)
• Account lockout by email (stops credential stuffing)
• Consider CAPTCHA after 3 failed attempts

4. Rate Limiting Implementation

YES, absolutely implement it! Use:

• express-rate-limit for API rate limiting
• express-slow-down to gradually slow down repeated requests
• Redis for production (scales better than in-memory)

---

System Architecture

1. Should Auth Be a Separate Microservice?

For your project: NO. Here's why:

Monolith is better when:

• You're a small team (fewer moving parts)
• Learning fundamentals (microservices add complexity)
• Limited deployment resources
• Simpler debugging and development

Consider microservices when:

• You have 10+ developers
• Different teams own different services
• You need independent scaling (auth separate from business logic)

For your case: Keep auth as a module within your monolith, but structure it cleanly (see below).

2. Recommended Folder Structure

src/ ├── modules/ │ ├── auth/ │ │ ├── controllers/ │ │ │ ├── authController.ts │ │ │ └── tokenController.ts │ │ ├── services/ │ │ │ ├── authService.ts │ │ │ └── tokenService.ts │ │ ├── middlewares/ │ │ │ ├── authenticate.ts │ │ │ └── authorize.ts │ │ ├── models/ │ │ │ ├── User.ts │ │ │ └── RefreshToken.ts │ │ ├── validators/ │ │ │ └── authValidators.ts │ │ ├── routes/ │ │ │ └── authRoutes.ts │ │ └── tests/ │ │ └── auth.test.ts │ ├── users/ │ └── menu/ (your core business logic) ├── config/ │ ├── database.ts │ └── jwt.ts ├── utils/ │ ├── errorHandler.ts │ └── logger.ts ├── middlewares/ (global) │ └── errorMiddleware.ts └── app.ts 

Key principles:

• Separation of concerns: Controllers → Services → Models
• Feature-based structure: Group by feature (auth, users, menu) not by type (all controllers together)
• Easy to scale: New features = new folder in modules/

3. Managing Secrets

For development:

# .env file (NEVER commit this!)JWT_SECRET=your-super-secret-key-min-32-charsJWT_REFRESH_SECRET=another-secret-keyDATABASE_URL=postgresql://user:pass@localhost:5432/db

For production:

• Use environment variables in your hosting platform (Vercel, Railway, AWS)
• Better option: Use a secrets manager:
  • AWS Secrets Manager
  • HashiCorp Vault
  • Doppler
  • Infisical (open-source)

Best practices:

// config/env.tsimportdotenvfrom'dotenv';dotenv.config();exportconstconfig={jwt: {secret: process.env.JWT_SECRET!,expiresIn: '15m',refreshSecret: process.env.JWT_REFRESH_SECRET!,refreshExpiresIn: '7d'},database: {url: process.env.DATABASE_URL!}};// Validate required env vars on startupif(!config.jwt.secret)thrownewError('JWT_SECRET is required');

---

User Experience

1. Password Strength Meter

YES, implement it! Users create weak passwords otherwise.

Easy implementation:

// Use zxcvbn libraryimportzxcvbnfrom'zxcvbn';conststrength=zxcvbn(password);// Returns score 0-4 (weak to strong)

Frontend feedback:

• Show real-time strength indicator
• Suggest improvements ("Add a number", "Use symbols")
• Require minimum score of 2 or 3

2. Two-Factor Authentication (2FA)

For a student project: OPTIONAL, but impressive if done right.

When to implement:

• You have extra time
• Want to showcase advanced skills
• Handling sensitive user data

Simple 2FA options:

• Email OTP (easiest - use Nodemailer)
• SMS OTP (use Twilio - costs money)
• Authenticator apps (TOTP using speakeasy library - most professional)

Implementation tip:

// Make it optional, not mandatory// Users can enable it in settings{userId: "123",twoFactorEnabled: false,twoFactorSecret: null// Store TOTP secret if enabled}

3. Simple & Intuitive Login Tips

UX best practices:

• Clear error messages ("Invalid email or password" - don't specify which)
• "Remember me" checkbox (longer refresh token)
• "Forgot password?" link (implement password reset via email)
• Social login options (Google, GitHub OAuth - nice to have)
• Loading states during login
• Auto-focus on email field
• Show/hide password toggle
• Don't use CAPTCHAs unless necessary (bad UX)

---

Additional Recommendations

Security Checklist

• HTTPS only in production
• CORS configured properly
• SQL injection protection (use parameterized queries)
• XSS protection (sanitize inputs, use helmet.js)
• CSRF protection for state-changing operations
• Log security events (failed logins, token refreshes)

Testing

// Write tests for auth flowsdescribe('Authentication',()=>{it('should login with valid credentials',async()=>{// Test implementation});it('should reject invalid credentials',async()=>{// Test implementation});it('should lock account after 5 failed attempts',async()=>{// Test implementation});});

Documentation

Create an AUTH.md file explaining:

• How authentication works in your app
• Token lifecycle (access + refresh)
• Security measures implemented
• How to test the auth system

---

Priority Roadmap

Must Have (Do Now):

1. Rate limiting on login endpoint
2. HttpOnly cookie for refresh tokens
3. Password strength validation
4. Proper error handling

Should Have (Next Sprint):

1. Account lockout after failed attempts
2. Password reset via email
3. Refresh token rotation
4. Input sanitization

Nice to Have (If Time Permits):

1. 2FA with authenticator app
2. Social login (OAuth)
3. Password strength meter
4. Session management dashboard

---

Resources

• OWASP Authentication Cheat Sheet
• JWT Best Practices
• Node.js Security Checklist

---

Great job so far, Team Menu Makers! Your current implementation is solid. Focus on the "Must Have" items first, then add the "Should Have" features. Don't over-engineer—shipping a working, secure product is better than a perfect one that's never finished.

Feel free to ask follow-up questions! Good luck with your project!