12 best practices for User Account Security, authorization and password management, and best practices for Password Management

12 best practices for User Account Security, authorization and password management, and best practices for Password Management

Account Management, authorization, and password management are often tricky. For many developers, the account management function is a secret and won't attract enough attention. For product managers and users, the final product experience often exceeds expectations.

Fortunately, Google cloud platform (GCP) provides some tools, this allows you to make better decisions on product creation, security processing, and user account authentication (any person registered in your system-consumer or internal user. No matter what system you are responsible for, the WEB site deployed on Google Kubernetes Engine, the API service on Apigee, the application using Firebase, or any service that includes user authentication, this article provides best practices to ensure that you have a secure, scalable, and available account authentication system.

1. Hash the password field

The most important principle for account management is to securely store users' sensitive information, including users' passwords. User Data is sacred and must be properly processed.

Do not store plaintext passwords in any case. In your service, you need to hash the password and cannot decrypt it. For example, you can use PBKDF2, Argon2, Scrypt, or Bcryp to create a password. The hash value is the result of adding salt to the user's unique logon credential. Do not use outdated hash processing technologies such as MD5 and SHA1, and should not use decrypted algorithms or try to invent hash algorithms under any circumstances.

Assume that the system you designed will eventually be leaked. Ask yourself, "If my data is leaked today, will the security and privacy of my users be threatened when I use my services or other services they use? What can we do to mitigate the potential harm caused by such data leaks ?"

Another thing to consider: when a user provides you with a password, if you can generate a user's plaintext password at any time, your implementation is problematic.

2. Try to allow third-party authentication

Third-party authentication providers allow you to rely on a third-party trusted service to authenticate the user's identity. Google, Facebook, and Twitter are usually available providers.

In addition to existing internal authentication systems, you can use a platform (such as Firebase authentication) to access a third-party authentication service. Firebase authentication has many advantages, such as simpler management, smaller attack portals, and cross-platform sdks. Through this list, we will propose many advantages. For details, refer to the case study.

Firebase authentication.

3. differentiate between user identity and User Account

Your user is not an email address. They are not phone numbers. They are not the unique ID provided by the OAUTH response. Your users are the exclusive aggregation of personalized data and experience in your services. A well-designed user management system has low coupling and high cohesion between different parts of users' personal data.

The separation of user accounts and certificates will greatly simplify the process of implementing third-party authentication providers, allow users to change their usernames, and link multiple identities to a single user account. In fact, it may be helpful to provide an internal GLobal IDEntifier for each user and link its configuration file and Identity Authentication identifier through this ID, rather than aggregating all of them into one record.

4. Allow multiple identities to be associated with a single user account

Users who log on to the service using their usernames and passwords may log on using Google Sign-In later. They do not know that this will create redundant accounts. Similarly, for some reason, a user in the service may be associated with multiple email addresses. If the user identity and authentication information can be correctly separated, it is easy to link multiple identities to the same user.

Your backend needs to consider that users may register through some or even all channels, but they do not realize that new third-party identities are not associated with their existing accounts in the system. The simplest implementation is to require users to provide a common detail for identification, such as an email address, phone number, or user name. If the data matches existing users in the system, they are required to authenticate known identities and associate the new IDs with existing accounts.

5. Do not reject long passwords or complex passwords.

NIST recently updated its guidelines on Password Complexity and strength. If you are (or will immediately) using a high-strength hash algorithm to save the password, many problems will be solved. No matter how long the input content is, the hash algorithm will generate a fixed-length output, so users can use their favorite long password. If you have to limit the password length, you should only consider the maximum POST size supported by the Service. Strictly speaking, this is usually greater than 1 M.

The hash password consists of a small part of ASCII characters that everyone knows. Even if not, it is easy to convert binary data through Base64. With this in mind, you should allow users to use characters in their passwords at will. If someone wants to use the kilin, emoticon, and control characters in the password and add white spaces at both ends, you should have no technical reason to reject them.

6. Do not impose unreasonable rules on user names.

Some websites or services require that the user name contain no less than two or three characters. Invisible characters are not allowed, and spaces are not allowed before and after the user name. However, some websites require a minimum length of 8 characters and only seven (bit) ASCII letters and numbers are allowed.

Strict user name restriction on the website may bring convenience to developers. However, in some extreme cases, user requirements may discourage some users.

In some cases, the best way is to specify the user name. If this problem occurs in your service, make sure that the specified user name is easy to remember and easy to tell. The ID of a combination of letters and numbers should avoid symbols that are not easily recognized visually, such as "Il1O0 ". We also recommend that you perform dictionary scans on randomly generated strings to ensure that no information is accidentally embedded in the user name. This principle also applies to automatically generated passwords.

7. allow users to change their usernames

In the legacy system or any platform that provides email accounts, it is very common that users are not allowed to change their usernames. There are many good reasons to not automatically release the user name for reuse, but the long-term users of the system will give a good reason to use different user names, and they may not want to create new accounts.

You can allow aliases and allow your users to select the primary aliases to meet users' desire to change their usernames. You can apply any business rules required on this function. Some organizations may only allow you to change the user name once a year, or prevent users from displaying anything except the primary user name. The email supplier may ensure that the user is fully aware of the risks before separating the old user name from his/her account, or may completely prohibit the old user name from being disconnected.

Select the appropriate rules for your platform, but make sure they allow your users to grow and change over time.

8. Allow your users to delete their own accounts

A considerable number of services have no self-service means for users to delete their accounts and related data. There are many good reasons for users to permanently close their accounts and delete all personal data. These issues need to be balanced based on your security line and compliance needs, but most regulated environments provide specific guidance on data retention. A common solution to avoid compliance and hacker attacks is to allow users to plan their own accounts for automatic deletion in the future.

In some cases, you may need to delete your data in time according to your requirements. In the event of data leakage, You can greatly increase your exposure to data leakage in "closed" accounts.

9. make a conscious decision on session Length

Session length is often ignored in security verification. Google has made some efforts to ensure user behavior and perform dual checks, mainly based on some events and behaviors. Users can further enhance their security step by step.

Your service can have a clear reason to maintain the session, instead of opening up the non-critical analysis for an indefinite period of time. However, there should be a threshold for you to enter a password, or a second factor or other user verification.

Determine how long the user should authenticate and determine whether the user is inactive. If a password is reset, You need to verify the identity of all active sessions. If a user changes the core aspect of the configuration file or when they perform sensitive actions, they should be prompted for authentication or a second factor. Consider whether it makes sense not to allow logon from multiple devices or locations.

When your service user session expires or requires repeated authentication, the user is prompted in real time or a mechanism is provided to protect any activity to save the unsaved final verification. The user entered the form and submitted it for a while and found that all their input had been lost and they had to log on again, which was very frustrating.