Authentication is essential. Every couple of days we hear about vulnerabilities being exploited. Unfortunately, there is much less talk about the human factor in the most of these attacks. And when it comes to humans using software systems, the first question is always: who that human is. And are they really who they claim to be?
The process of verification that an entity is really who it claims to be is called authentication. If it gets broken, we have spoofing. Let’s see how to do the first right, to avoid the latter.
There are several – namely 3 primary and several secondary – methods, also called factors, of doing authentication:
To harden the authentication process, several methods can be combined. But when combining them, it is important to use different means from the method categories above. Which in this context we call factors.
A good example is using an ATM: the card itself is possession-based authentication, while the PIN is knowledge-based. Another example is using a security token, where the code displayed by the token is possession-based, while the password used to access the token is knowledge based.
Paying in a shop with an NFC mobile device requiring biometrical unlocking combined with location-based authentication uses even 3 methods (possession-, biometrics- and location based). On the other hand, using a credit card online with only the 3-digit CVV to secure it is not multi factor authentication. In this case all the required data is knowledge-based and to make it worse all of them can be obtained from the same card.
Also, using SMS messages as the second factor is not a good idea despite it being very widespread. It is vulnerable to SIM swap attacks, where the SIM is reported stolen or damaged by the attacker as discussed earlier. Also, the SMS architecture itself is not secure and the messages can be spoofed easily. This is why NIST removed its recommendation for SMS as part of a multi-factor authentication process.
One of the most obvious and common authentication methods is using a password.
The problem with password authentication is twofold. On one hand passwords must be strong enough to withhold the various cracking attacks. On the other hand, human psychology requires easy to remember passwords. Otherwise, they will end up on a post-it note on the side of the screen. When security is too hard, people will find a way to go around it by either breaking the system or abandoning it. Finding a solution easier to use is often the easiest.
For this reason does NIST not recommend changing the passwords periodically, only in a case of a breach.
There is a distinct difference between a password being cracked or stolen. In the former case the only protection as the user is choosing a strong password. The latter can be avoided by being vigilant.
Make sure you protect yourself against social engineering and generally against having your credentials abused.
But why is it important to have a strong password?
To understand this question, you must understand how the authentication passwords are stored, and how they are cracked.
Passwords are usually stored not in clear text. They are stored hashed instead. Hashes are fixed length combination of bytes which describe the authentication password without storing it. The main advantage of hashes is that the hash calculation process is one-way. This means that the authentication password cannot be reproduced from the hash easily. The only way attackers can do it backwards is to try various passwords and compare whether the newly calculated hash matches the one in question. In addition, algorithms for hash calculation are designed to be slow. In average they are configured to allow only around 10 tries per second. This speed will not slow down authentication considerably but will put on the brakes against brute force attacks. To make the hashing algorithms even nicer, they are designed to be adaptable. As the technology evolves, and faster hardware is available, good hashing algorithms can be made to calculate even slower. This is especially important as cheap specialized hardware is abused to break passwords. Such specialized hardware is widely available since the same kind of computation is necessary to hash passwords as for image processing (e.g., computer games) and mining crypto currency. As you can guess, GPUs are of great help here.
Attackers are usually not trying to crack all the authentication passwords; they stop after a given time or after they cracked a given number or percentage of passwords. Therefore, it is important to have an authentication password stronger than most other users have in the system. This way there is a better chance that they stop the cracking process before they crack your password.
Of course, this is not the case if an attacker is targeting you. But in this case, they are trying to gather information about you through all kind of channels: social media, observing you, or even going through your garbage. They hope that your authentication password can be guessed from the data collected about you in one way or the other.
Despite all the problems, password-based authentication is still the most widespread. A shift towards biometrics is already on the way, but until then, we recommend using password managers, which are a convenient way of generating and handling different and strong passwords all over your accounts. This way you only have to remember one single password that protects the rest.
As a developer your job is to protect the passwords of your users. Password management is an essential task in all systems that do authentication. Best practices include hashing (no plaintext storage!), using appropriate hash algorithms (slow ones that are moreover adaptive in speed), and using salting (adding a unique value to the input of hashing for each password) + peppering (adding a server-wide secret to hashing in a similar way as salting).
And at the crossroad of the user and developer viewpoint there is password policy. It is an enforced guide to choosing satisfactory passwords. There are some interesting trends here: according to the NIST guidelines, a password should be at least 8 characters long, should support Unicode characters, but also there should be no periodic expiration (!), as well as no mixed character sets should be enforced (!).
Bottom line: authentication is one of those topics where the conflict between security and usability is tangible. Simply put, when you push security over a certain limit, it breaks. And the reason behind is the principle of psychological acceptability: the fact that your users are human beings and they simply cannot accept overly complicated solutions. Keep it simple, but secure!
Users can make many mistakes. But developers can do so as well. Take a look at our courses to see how we can give you a hand in avoiding the common security pitfalls and mistakes to make your systems more secure, and at the same time protect the user from its own mistakes.