Authentication:
Authentication can be very discouraging to build as a developer keeping various security features in mind. It is ideal to use or build authentication systems that don’t depend on 3rd party providers at all.
Custom-building authentication systems help you gain confidence in the system as it relies on your database for verification. Google OAuth and Twitter authentication are trusted by a large set of people but it is essential to follow the NIST guidelines which are the prerequisites to any authentication system.
What is encryption and how does it work in securing data?
Encryption is the process of converting plain text or readable data into a coded or unreadable format. It is a security mechanism used to protect sensitive information such as passwords, credit card numbers, and other confidential data from unauthorized access. The encrypted data can only be decoded or read by someone who has access to the encryption key.
Encryption works by using an algorithm to scramble the original data into a ciphertext or a coded message. This ciphertext is unreadable and can only be converted back to plain text using a decryption key. The encryption algorithm uses a complex mathematical formula to convert the original data into an encrypted form. The key used in the encryption process can be a symmetric key, where the same key is used to encrypt and decrypt the data, or it can be an asymmetric key, where two different keys are used for encryption and decryption.
Encryption can be applied to data at rest or data in transit. Data at rest refers to data that is stored on a device or server, such as a hard drive or a cloud-based storage service. Data in transit refers to data that is being transmitted over a network, such as an email or a file transfer.
Encryption can protect data in various scenarios such as securing sensitive business data, protecting personal information, securing online transactions, and ensuring privacy in communication. However, it is important to note that while encryption can protect data from unauthorized access, it is not fool-proof and can be bypassed through various means such as hacking, social engineering, or keylogging.
NIST Guidelines:
User-generated passwords should be at least 8 characters in length.
Machine-generated passwords should be at least 6 characters in length.
Users should be able to create passwords of at least 64 characters in length.
All ASCII/Unicode characters should be allowed, including emojis and spaces.
Stored passwords should be hashed and salted, and never truncated.
Prospective passwords should be compared against password breach databases and rejected if there’s a match.
Passwords should not expire.
Users should be prevented from using sequential characters (e.g., “1234”) or repeated characters (e.g., “AAAA”).
Two-factor authentication (2FA) should not use SMS for codes.
Knowledge-based authentication (KBA), such as “What was the name of your first pet?”, should not be used.
Users should be allowed 10 failed password attempts before being locked out of a system or service.
Passwords should not have hints.
Complexity requirements — like requiring special characters, numbers, or uppercase letters — should not be used.
Context-specific words, such as the name of the service or the individual’s username, should not be permitted.
Hashing
Hashing is one of the best ways to encrypt passwords. Passwords are converted into a very long hexadecimal string and stored in the database making it almost impossible to crack it.
A common hashing technique is B-Crypt where a password is ‘truncated’ meaning it will cut off the password into a short string if it has more than 72 characters. An advanced alternative to B-Crypt is ‘Argon-2’ which is a data-independent memory access mechanism, which is preferred for password hashing and password-based key derivation.
Keep a limit of 64 characters for any password that your user can create in your app to solve this minor problem. You need to keep yourself updated with various password authentication mechanisms and regularly update your users and your app with the best practices available to make your app secure.
Developers store and handle passwords as database sessions or JSON web tokens (more preferred).
Invalidating a JWT:
Say, for example, an attacker gains access to a user account, and if you didn’t invalidate JWT; even after the user changes his/her password, the attacker can still access that account through the entire JWT lifespan.
One way to solve this problem is by keeping the ‘User ID’ and ‘JWT’ stored in one place and once a user changes the password, you verify it by comparing the User ID with the User ID linking to the JWT stored in the database.
If it doesn’t match, then it marks as an ‘Invalid JWT’. One of the crucial factors to be kept in mind in authentication is the fallacy that the endpoints are accessed only by the frontend part. But the untold truth is that anyone can access or hit these endpoints even if they don’t even interact with the front end. When handling password reset over 2 endpoints, be careful as users can send API requests to the second endpoint directly.
To hit the next endpoint, it is essential to have a validation once again to not allow unwanted easy access to an endpoint making your app more secure. Let’s explain this by giving an example. Suppose a user wants to change his/her password, he/she should first enter the previous password that validates with the existing password in the database. If this condition becomes true, then he/she can enter the new required password.
Suppose the user has forgotten the old password, a password recovery email can be sent to the registered email with a link having a token that stays active for a max of 30 minutes. The server knows that it is a valid request enabling the user to change or create a new password.
To handle server-side authentication (basic requirements), we have JavaScript libraries like Yup or Zot where you can write schemas that define properties that help in the validation of passwords.
User Enumeration Vulnerability:
This is a technique where attackers can go to your login page and enter a bunch of usernames to check if they are valid or not. They can check the response from the server and check if the username is taken or not.
Suppose a user enters either the username or password wrong, you don’t tell them which one is wrong. Rather tell them that their ‘credentials don’t match’ making it hard for hackers to crack your passwords. If a user tries to reset the password, send a recovery email and notify them that they can reset their password by clicking on the link sent to their email rather than giving them an opportunity in the app itself. This helps your app get a layer of security in authentication and user data.