For a user, providing personal details on any app or website is always a matter of concern. And for a developer, it is even trickier to manage all that securely. If something goes wrong, it is the user data and the credibility of the company at risk.
Thankfully, Google Cloud Platform (GCP) is there to save us all. It offers numerous tools which will help you make good decisions around the creation, secure handling, and authentication of user accounts. Even if your website is hosted on Google Kubernetes Engine or another service with authenticated users, no worries. This article will provide you with best practices to ensure a safe, scalable, and usable account authentication system.
Passwords are dearer to any user. One of the most crucial rules for account management is to preserve sensitive information, among which password is of high importance. Plain text passwords are a big no-no. It is easy for a hacker to crack a simple text password. That 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 with PBKDF2, Argon2, Scrypt, Bcrypt, etc. Try to salt the hash with a value unique to that specific login credential. Avoid using deprecated hashing technologies such as MD5, SHA1. Under no circumstances should you use reversible encryption or try to invent your own hashing algorithm.
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 for it. 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.
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 great user management system, it will have a low coupling and high cohesion between various parts of a user’s profile.
By separating both concepts, the entire process of implementing third-party identity providers will become simplified. This allows users to change their username and link multiple identities to a single user account. It will help you have an internal global identifier for every user and link their profile and authentication identity via that ID rather than piling it all in a single record.
Many users go for the Google sign-in option to log in to a website without understanding that this could create a duplicate account. Similarly, a user may have a 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 this, 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, ask them to authenticate with a known identity provider and link the new ID to their existing account.
NIST has recently updated guidelines on password complexity and strength. Since very soon we all will be using a robust cryptographic hash for password storage, a majority of issues will resolve there themselves. 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 generally well above 1MB. So you can allow your users to use literally any characters they wish in their password on both ends. You should have no technical reason to deny them.
Many 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. It is good to some extent. But 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. The best way is to suggest them usernames. Provide them a user-friendly username by performing a dictionary scan on any randomly generated string to ensure there are no unintended words embedded in the username. These same guidelines apply to auto-generated passwords.
Allowing users to mess with credentials may not seem a good idea. But long-term users of your system will eventually find 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. Either permit them to change their username per year or prevent users 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.
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 accounts for automatic future deletion. Data breaches can occur even from closed accounts.
You might have come across various sites that display ‘Session expired, login again.” The reason for this is high-level security. It is done to ensure users are who they say they are. It will also double-check based on some events or behaviors. When your service requires re-authentication, prompt the user in real-time or provide a mechanism to preserve any unsaved form since it was last filled. It becomes very frustrating when such a thing happens after filling up a long-form.
Consider the practical impact on a user account when choosing the 2-Step Verification (also known as 2-factor authorization or just 2FA) method. 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.
Consider the practical impact on a user account when choosing the 2-Step Verification (also known as 2-factor authorization or just 2FA) method. 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.
I love to make a difference. Thus, I started Acquaint Softtech with the vision of making developers easily accessible and affordable to all. Me and my beloved team have been fulfilling this vision for over 15 years now and will continue to get even bigger and better.
A comparison between Flutter and Swift to help you pick the best tool to develop a stunning mobile app for your business.
Develop a time and attendance software for your firm to eliminate the errors caused by an outdated system and streamline important processes.
Discover how to effectively hire and manage MERN stack developers. Learn the advantages of partnering with Acquaint Softtech for your development needs.
