Your login page is a prime target for hackers as it stands between the internet and sensitive data. Most web applications permit users to access accounts and view sensitive information, making your login page the primary defense against potential threats. As a result, your login page is the gateway defense between the user’s personally identifiable information (PII) and the open internet. 

If your login page lacks proper security, you might be making the following five mistakes:

Mistake 1: Not Identifying Users vs. Bots

Every login page request entails distinct features, some of which can be fabricated while others are harder to falsify. Recognizing whether a page request comes from a bot or a real user is crucial for fraud detection, allowing specific threats to be halted before multiple authentication requests are made.

For instance, an attacker could automate authentication requests on your login page and run brute-force attacks. Thus, identifying whether a request originates from a bot or a real user reduces your risk.

The user’s browser sends data like a user agent and cookies with the request, but these elements can be mimicked. Basic bot attacks do not have a user agent value that matches a real browser, and the bot won’t send a valid cookie. However, advanced bots send these values to your login page to bypass fraud detection and imitate human users.

Solution 1: Implement Bot Detection

One way to defend against this attack is to use Fingerprint’s bot detection solution to probe different aspects of a web request to identify if the request is from a bot or a user. In addition, the sophisticated Fingerprint JavaScript engine uses several unique identifiers, and it can link a user to a specific device to stop duplicate user signups and block botted requests.

Mistake 2: No Multi-Factor Authentication (MFA) Implemented

Web admins should implement multi-factor authentication for any web application that stores sensitive information. Check with applicable web app compliance because MFA might be a compliance requirement to protect users from account takeover. Even if MFA is not a compliance requirement, it eliminates many login page authentication issues.

Most developers believe that MFA requires them to find a way for users to receive a personal identification number (PIN) via text messages to their smartphones. However, developers can use various methods to send users a secondary authentication PIN. The basic principle of MFA is that only the user should have access to a PIN sent to a device or account, reducing the chance of account takeover when combined with a password.

Solution 2: Require MFA at Login

A secondary PIN can be sent to the user’s smartphone via SMS or email, or an authenticator app can generate the PIN, eliminating the need for the system to do so. Implementing an MFA solution requires minor coding and authentication workflow changes but greatly reduces fraud risk and prevents bots from performing brute-force attacks using stolen credentials.

Mistake 3: Not Limiting Login Attempts

Attackers purchase extensive lists of compromised user accounts and passwords and use automation tools to test these credentials against your login page. They do this to verify the accuracy of the user account and password, gain access to the user’s account, or steal user data or money.

Brute-force attacks operate by sending automated authentication attempts to your login page. Without limitations, an attacker could potentially make thousands of authentication requests in a short period or continuously send authentication requests until a match is found. Your login page should detect excessive requests, and several measures can be taken to inhibit this behavior.

Solution 3: Prevent brute-force attacks

The primary method to stop automated authentication requests is using a CAPTCHA service. You can require the user to solve the CAPTCHA initially or after several failed authentication attempts. 

Implement Device Intelligence

However, if you’re looking for an authentication method that doesn’t add extra steps for trusted users, consider utilizing a device intelligence solution that works in the background authentication unique visitors. You can only require challenge steps for visitors that have been identified as suspicious visitors. 

Use Third-party Denial-of-Service (DoS) Protection

Third-party denial-of-service (DoS) protection also detects rapid authentication requests, and it will block further attempts. This strategy can be used with a Device Intelligence to block more sophisticated attacks. If too many requests are made, the system can return a server 429 status message, which is the appropriate response for many requests.

Identify Failed Authentication Attempts

A third strategy is to lock a user account after too many failed authentication attempts. While this is useful, it should not be the only defense. Locking user accounts stops attempts on the user but does not stop an attacker from continuing with other accounts. Device intelligence, request limitations, and account lockouts should be used together to prevent brute-force attacks.

Mistake 4: Not Hashing Stored Passwords or Using Vulnerable SHA-1 and MD5 Hashing Algorithms

Developers are not hackers, so they often take missteps in dealing with security in their applications. One common misstep is the way passwords are stored in the application database. 

At worst, developers store passwords in plaintext, which is a severe security flaw and leaves users vulnerable to credential theft and the company to compliance violations. In addition, users commonly use the same credentials across multiple sites, so developers should take necessary precautions to protect users from account takeover after a breach on your application.

Solution 4: Hash and Salt Passwords

Hashing passwords is the best practice, but developers must remember that hashing is not encryption. OWASP advises that passwords should not be encrypted, but rather hashed. Hashing is a one-way algorithm, meaning it cannot be decrypted with a key like symmetric or asymmetric encryption. The only way to determine the plaintext value from a hashed string is using dictionary attacks.

Using Salt with Hashing and Defending Against Rainbow Tables

Salt should be used with hashing. User passwords are vulnerable to dictionary attacks by just hashing passwords, often using rainbow tables. However, the attacker needs the password and a random salt value. Therefore, the salt should be different for each password and appended to the end of the user’s password before hashing. Adding a random salt to a password before hashing makes it much more challenging to determine the user’s password, but it should always be different for every hash and can be stored in the same database as the hash. 

So, having a unique salt for every hash does not allow an attacker to feasibly run through a list of passwords and create a rainbow table of possibilities for every dictionary term and randomized salt value.

Using the Correct Hashing Algorithms: SHA-2 and SHA-3

Finally, the type of hashing algorithm you use is essential. SHA-1 and MD5 are cryptographically insecure. These two algorithms are vulnerable to collisions, which means that two different passwords result in the same hash. They are also computationally susceptible to dictionary attacks using current computing power. 

The hashing algorithm you use should resist brute-force dictionary attacks and collisions. SHA-2 is the typical choice, but SHA-3 is available. SHA-3 is considered more secure by some experts, but it takes more computing power and can affect the performance of your application.

Mistake 5: Using Only One Security Strategy, Not All Five

Remediate these five mistakes on your web application, not just one. By implementing all five remediation strategies, your risk dramatically drops. In addition, being the reason for a user losing their data and password causes irreparable damage to brand reputation, so security should be a priority for any business.

Solution 5: Implement All Five Security Recommendations

Hashing passwords, using CAPTCHA, and implementing MFA can be done in-house without third-party tools, but detecting bots and automated authentication requires more sophisticated tools. Fingerprint Pro helps developers quickly detect duplicate users, and when paired with the bot detection solution, it can also detect bots.

Try out our demo or get started for free.