Best Practices For User Account, Authorization And Password Management


For a user, providing personal details on any app or website is always a matter of concern. And for a developer it even trickier to manage all that securely. As if something goes wrong, it’s the users’ data that fall at a big risk.

Thankfully, Google Cloud Platform (GCP) is there to save us all. It offers numerous tools that will help you make good decisions around the creation, secure handling, and authentication of user accounts (in this context, anyone who identifies themselves to your system — customers or internal users). Even if you’re responsible for a website hosted on Google Kubernetes Engine, an API on Apigee, an app using Firebase or another service with authenticated users, this article will provide you with best practices that will ensure you have a safe, scalable and a usable account authentication system.

1. Make a habit to hash the passwords

Passwords are dearer to any user. One of the most important rules for account management is to preserve the sensitive information of a user, among which password is of high importance. Plaintext passwords are a big no-no. It’s very easy for a hacker to crack a simple text password, which is why almost all site now asks for a password with a combination of letters, symbols, and numbers. Code your site in such a way that it stores a cryptographically strong hash of the password that cannot be reversed — created with, for example, PBKDF2, Argon2, Scrypt, or Bcrypt. Try to salt the hash with a value unique to that specific login credential and avoid using deprecated hashing technologies such as MD5, SHA1 and under no circumstances should you use reversible encryption or try to invent your own hashing algorithm.

2. Its ok to allow third-party identity providers

If you want to rely on a trusted external service to authenticate a user’s identity, it is all okay. Third-party identity providers like Google, Facebook and Twitter are commonly used providers whom you can make use of. You can even implement both an external identity provider and your existing internal authentication system, side-by-side, using a platform such as Firebase Auth.

Password Management

3. Split user identity and user account

First of all, they are not the same. Remember, your users are not an email address or a phone number. Neither are they a unique ID provided by an OAuth response. Your users are the culmination of their unique, personalized data and experience within your service. Even though you design a fine working user management system, it will have a low coupling and high cohesion between different parts of a user’s profile.

By separating both the concepts the entire process of implementing third-party identity providers will become simplified, allowing users to change their username and linking multiple identities to a single user account. In short, it will help you have an internal global identifier for every user and link their profile and authentication identity via that ID as opposed to piling it all in a single record.

4. Allow them to link multiple identities to a single user account

Majority of users go for the Google sign-in option in a website to log in, without understanding the fact that this could create a duplicate account. Similarly, a user may have very good reason to link multiple email addresses to your service. So, if you properly separate user identity and authentication, it will be much easier for a user to link several identities to a single account.

For that, your backend will need to account for the possibility that a user gets part or all the way through the signup process before they realize they’re using a new third-party identity not linked to their existing account in your system. This is most simply achieved by asking the user to provide a common identifying detail, such as email address, phone or username. If that data matches an existing user in your system, require them to also authenticate with a known identity provider and link the new ID to their existing account.

5. Allow long or complex passwords

NIST has recently updated guidelines on password complexity and strength. Since very soon we all will be using a strong cryptographic hash for password storage, a majority of issues will resolve there itself. The hashes always produce a fixed-length output no matter what the input length is, so there is nothing wrong with your users using long passwords. If you must cap password length, only do so based on the maximum POST size allowable by your servers. This is commonly well above 1MB. So you can allow your users to use literally any characters they wish in their password, be it Klingon, Emoji or control characters with whitespace on both ends, you should have no technical reason to deny them.

6. Avoid imposing unreasonable rules for usernames

A lot of sites ask for usernames longer than two or three characters, asking them to block hidden characters and prevent whitespace at the beginning and end of a username. But its good to some extent. Don’t go overboard with a long list of requirements. Not asking for enough restrictions may be a shortcut for developers but may put a user at risk and he/she may simply leave. Or the best way is to assign them usernames. Provide them a user-friendly username after performing a dictionary scan on any randomly generated string to ensure there are no unintended messages embedded in the username. These same guidelines apply to auto-generated passwords.

7. Give them the freedom to change their username

Allowing users to mess with credentials may not seem a good idea, but long-term users of your system will eventually come up with a good reason to use a different username and they likely won’t want to create a new account. You can honor their request by allowing aliases and letting your users choose the primary alias. You can apply your business rules here and either allow them to change their username per year or prevent a user from displaying anything but their primary username. Don’t forget to inform your users about the risks before detaching an old username from their account or else you can forbid unlinking old usernames entirely.

User Account

8. Let them delete their accounts

Leave the user-deactivation to them. A user must have the option to either deactivate or close an account permanently and delete all personal data. Provide them this freedom with specific guidelines on data retention. A common solution to avoid compliance and hacking concerns is to let users schedule their account for automatic future deletion. As data breach can occur even from the closed accounts.

9. Set session length

You might have come across various sites that display ‘Session expired, log in again.” The reason for this is high-level security. It is done to ensure users are who they say they are and will also double-check based on certain events or behaviors. When your service does expire a user session or requires re-authentication, prompt the user in real-time or provide a mechanism to preserve any activity they have unsaved since they were last authenticated. It becomes very frustrating when such a thing happens after filling up a long form.

10. Use 2-Step Verification

Consider the practical impact on a user of having their account stolen when choosing from 2-Step Verification (also known as 2-factor authorization or just 2FA) methods. SMS 2FA auth has been deprecated by NIST due to multiple weaknesses, however, it may be the most secure option your users will accept for what they consider a trivial service. Offer the most secure 2FA auth you reasonably can. Enabling third-party identity providers and piggybacking on their 2FA is a simple means to boost your security without great expense or effort.

11. Switch from sensitive to case insensitive

Users do forget usernames and passwords and if in that there are complicated factors like case-sensitivity it will complicate furthermore. Keep usernames fully case-insensitive. Smartphones represent an ever-increasing percentage of user devices. Most of them offer autocorrect and automatic capitalization of plain-text fields. Preventing this behavior at the UI level might not be desirable or completely effective, and your service should be robust enough to handle an email address or username that was unintentionally auto-capitalized.