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.
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.
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.