The security company Veracode has uncovered at least one of the following vulnerabilities in nine out of ten applications. They are the most common, but also the easiest for developers to fix, gateways for attackers in authentication processes:

Weak password rules

Surprisingly, there are still quite a few applications and websites that allow weak passwords. This is because developers are trying to find the right balance between security and user-friendliness. However, with a minimum length of only five characters, password security is clearly not given enough importance. As a result, many end users continue to use passwords such as "123456" or "password". This gives attackers access to user accounts and many corporate data breaches can often be traced back to just such a password. Developers should therefore ensure that passwords have at least eight characters, contain alphanumeric characters, have a mixture of upper and lower case letters and must not contain the user name or the company name. To detect compromised passwords, developers can use the API of 'haveibeenpwned', for example.

Lack of two-factor authentication

Two-factor authentication (2FA) has become one of the most important application security measures and yet many developers do not use it. 2FA can be implemented in many different ways: RSA tokens, code generators like the Google Authenticator or one-time codes sent to the end user via SMS. It only becomes complicated when both users with admin rights and users without admin rights log into the application using the same authentication method. A conventional 2FA is often not sufficient for applications of this type. It is advisable to run administrative functions, such as user account management, via a separate application that is secured with an even stronger authentication method.

Lack of precautions against user enumeration

If login attempts fail, applications often return error messages such as "Username does not exist" or "Invalid password". User enumeration describes the systematic exploitation of this circumstance. This is because the error messages contain information that allows conclusions to be drawn about whether an account with the corresponding username exists or not. And so the attacker is one step closer to his goal. User enumeration can be avoided by developers introducing a single generic error message instead of different ones, such as "If our system has found your account, you will receive an email shortly".

Lack of encryption for password resets

Vulnerabilities can also arise when resetting passwords. The two main reasons for this are weak security tokens and the fact that many applications send the password to the end user by email. Developers are often unaware that Base64 encoding does not automatically guarantee encryption. Therefore, if a security token based on Base64 is used during the password reset process, it can be decrypted relatively easily. In the second step, cyber criminals can then change the end user's password by adding a new email address and thus gain access to the account.

Another vulnerability can arise from sending passwords to end users via email. Sending confidential data by email carries an extremely high risk. Passwords could be stored in databases in a way that is easily accessible to intruders without adequate encryption, for example through salting or hashing. Most frameworks today have integrated functions that have already been tested for security. Developers should therefore generally use the functions already available in the framework instead of programming their own password reset functions.

In general, developers should therefore first ensure that they check the four most common vulnerabilities described and, if necessary, rectify them as best they can before the penetration test is carried out. In most cases, this can be done without much effort, leaving development teams more time to work on more complex vulnerabilities.