Most websites have some way for a user to create an account and log in. With the numerous attacks available to hackers, it’s important for website owners to find ways to protect and log in. With the numerous attacks available to hackers, it’s important for website owners to find ways to protect it’s important for website owners to find ways to protect user credentials. User credentials include a username and password, but a website owner might collect additional personal identifiable information (PII) that should be kept safe from attackers. Before adding a login component on safe from attackers. Before adding a login component on your website, you should follow some basic security standards to protect the login page from attackers.
Always Use HTTPS and Forward Any Traffic That Opens the HTTP Version
Most web hosts offer free or cheap SSL/TLS certificates. These certificates are installed on the web server and protect the login page from eavesdropping and man-in-the-middle (Mitts) attacks. A man-in-the-middle attack is when an attacker is able to eavesdrop on data as it passes the wire. The attacker could launch this attack on a public Wi-Fi network or on a local network such as a corporate office.
With HTTPS, the attacker can still steal data as it passes over a wire, but the content would be encrypted. You should always use the latest cryptographic algorithm, which is always use the latest cryptographic algorithm, which is currently 256-bit. If you use weaker algorithms, the encrypted traffic can be decrypted, and the data read by the attacker.
Return the Same Error When Credentials are Entered Incorrectly
When users enter the wrong credentials, the same error message should be shown regardless if the usemame, password or both are entered incorrectly. Some developers tell the user if the username is wrong, but then show a different message when the password was entered incorrectly. These error message differences tell the attacker which entry is incorrect, and they can assist an attacker in building a list of valid usernames.
With a list of usernames, the attacker can then launch a phishing attack. The phishing attack could be a simple email asking the user to reply with the right password, or the attacker could create a website that mirrors the look and feel of the original and trick a targeted user into entering credentials.
Use an Expiration Date on Password Reset Codes
When you have a login page for your site, you also need a way for users to get a password reminder. Sending a password in plain text in an email is considered bad security, so the alternative is to allow a user to reset a password. The user enters an email address, and then the site sends an email with a link to reset a user’s forgotten password. In the linked URL is a uniquely generated ID that should only be accessible by the user.
The unique ID should be a long, complex alphanumeric value. This value is usually a GUID generated but stored in the database, so when the user clicks the link the system knows which user generated the unique ID value. If there is no expiration on the unique value, then it can be used anytime.
Most users will never reuse the reset password link, but should an attacker gain access to the database, passwords can be reset using the front-end. With the unique ID exposed, an attacker just uses it to reset a targeted user’s password. With the password changed to the attacker’s value, the attacker can now log into the application with the user’s credentials.
Always add an expiration to a password reset link and unique ID. Even if the attacker gains access to the database, the system will block the password reset based on the expiration date. This date should not be too long from the expiration date. This date should not be too long from the initial generation date. Password reset links should expire within 72 hours or less.
Use a One-Way Salted Hash Value for Password Storage
There are several algorithms to encrypt data. The two basic methods are asynchronous and synchronous encryption. When you install an SSL/TLS certificate on your website to encrypt data, you use a public and private key to encrypt and decrypt data. This is asynchronous communication. This type of communication is vulnerable should an attacker crack the private key value. Weak encryption algorithms are susceptible to this attack and communication is vulnerable susceptible to this attack and to decryptions from an attacker.
To avoid vulnerabilities in asynchronous encryption, it’s suggested that passwords should be stored using a one-way hash. Synchronous encryption uses the same key to encrypt and decrypt, which can also be a security vulnerability. However, add a salt to the mix and the password is much more difficult to crack.
A salt is a random extra number of characters concatenated to the user’s password. After adding a salt, the password is then encrypted and stored in the database. Should an attacker gain access to the encryption key, they would still be unable to brute force a user’s password if they don’t have the salt value as well.
When working with one-way hashes, the only way to identify if a user’s password was correctly entered is to encrypt it with the salt value and compare the value with the one stored in the database. If they match, the right password was entered. If they don’t, then the user entered an incorrect password.
Add Two-Factor, If Possible
Two-factor authentication (2FA) adds one extra layer of defense against phishing or cracked passwords. If an attacker gains access to a user’s password, 2FA stops successful login attempts by requiring a code either sent to the user’s phone or email.
Social engineering allows an attacker to hijack a SIM card, but it’s much easier to phish user credentials than it is to trick the phone company into changing SIM card configurations. 2FA stops a lot of attacks, and it’s highly effective against phishing. Should a user fall victim to a phishing attack, the attacker would still be unable to log into the website.
The right login procedures and security standards protect your users from many of the common web attacks. Even if it isn’t the website owner’s fault when users fall for a phishing attack, proper security standards protect the user’s account. With better user protection, a website owner can avoid leaking PI I to attackers and losing respect and trust from customers. Carry on!