User Accounts Checklist
If you want to roll your own user authentication system, here’s a checklist of things to make it a good experience.
Think of this as a regression test suite that doesn’t break when the test framework needs to be upgraded. It lives at the conceptual level rather than in code.
Signing Up and Logging In
- Email addresses should be usable as login names.
- Do away with separate login names entirely and just use email addresses if you can.
- You’ll need separate login names if you’re building something like Instagram, Twitter, or Imgur – basically, anything where users can interact with each other. You don’t want to expose email addresses when it’s a social product.
- Enforce uniqueness on lowercase email addresses and (if you have them) lowercased login names. (Example:
john.doe@example.com
andJohn.Doe@example.com
should be the same account, not two separate accounts.) - Require email address to be verified for extended/important/sensitive functionality.
- Add a small but significant delay after every failed login attempt to cripple brute force password guessing.
- Changing email address requires verification of ownership of new email address.
Passwords
- Entered passwords should not appear in your server logs.
- Passwords should be one-way hashed, not stored in cleartext, not mangled and easily reconstructed.
- Password hashes should use bcrypt or scrypt.
- Passwords should not have a maximum length requirement.
- Passwords have a minimum length requirement.
- Define and understand how you want your password reset (“forgot password”) feature to work.
- Will you generate and reset the password immediately? It’s simple for you to build and maintain and for users to use, but allows anyone who knows a user’s email address to reset their password and cause them inconvenience.
- Will you verify email address ownership before resetting anything? In this case, you don’t even need to generate a temporary password. Instead, you offer a link with a unique key (not a password) associated with the password reset request to take the user to a self-service password reset page. (This is the better way to go, but it’s more complicated, so adjust your product roadmap and test plans accordingly.)
- If your user demographics or peculiar platform requirements compel you to provide the new password over email, be sure to verify correct entry of the auto-generated password before they’re allowed to enter a new password.
- Any prompt for new password entry after password reset should include password confirmation field for new password.
- New password after password reset should be subject to the same requirements as passwords for new accounts.
Multi-Factor Authentication (MFA)
- When allowing reset of MFA method, perform whatever verification step prior to blanking out the MFA info (whether it’s the TOTP shared secret or an SMS number or something else entirely).
- Prefer app-based MFA over SMS, but offer SMS if possible because it’s better than nothing.
User-Specific Settings
- Keep a setting for user’s timezone. This way, you can display the user’s local time in the app.
Email Communications
- Allow unsubscribe from all non-essential emails (activity notifications, summaries). You still want them to be able to get things like password reset emails or account closures.
- Implement unsubscribe from all marketing emails.
- Implement unsubscribe from certain marketing emails, if you choose to segment this way, so they can receive some but not others.
- Mark users’ opt-in/opt-out status properly in your own database.
- Ensure changes to users’ opt-in/opt-out status carry through to your bulk email provider.
- Verify that your unsubscribe functionality works from end to end.
- Verify that re-subscribe functionality works from end to end. If they unsubscribed previously but now want to hear from you, make sure they can!
- If someone unsubscribes and re-subscribes multiple times, their most recent preference should be their status. Watch out for this in your integration with your bulk email provider.