There is no question that passwords expose users to attack and replacing them is the goal. FIDO is all about Fast IDentity Online – secure authentication without the need for passwords. But FIDO has some obvious vulnerabilities which need to be considered and are covered in more detail in part 3 of this series of blogs.
Here, in part two of our 3 part series, our Chief Crypto Officer, Dr Michael Scott, highlights the outdated practice of ‘passwords’ and how they are simply not fit-for-purpose in today’s online world
In the first part of this series we considered two-factor authentication, how it’s a concept that has been used for hundreds of years and why sometimes, actually, it’s not enough when it comes to protection. Today we consider the setting where a client wants to log-in to a service via their Internet browser, not necessarily using two factor authentication.
The method in most common use is the well-known Username/Password mechanism. Via an enrolment process the client agrees a Username+Password combination with a server. For each client the server stores these in a file, known as the password file, or more generally as a credentials database; one entry per client. As a nod to improving security, it is actually a hash of the password that is stored in the file, and when the client logs in, their password is first hashed and then compared with the hashed value stored in the database. So passwords are not stored “in the clear” in the credential database.
An obvious weakness of this mechanism is that we literally hand over our password to the server. But what if they aren’t the real server – we just gave away our password! That false server is the equivalent of the Mafia’s false ATM machine described in the first part of this blog. In the computing world we call this a phishing attack.
Username+Password is clearly a one-factor method of authentication (the username can be assumed to be known – typically an email address). An attacker just needs to steal (or guess) your password. But actually the most common and devastating attack is the equivalent of the “mechanical digger” attack outlined in the first part of this blog series. The attacker crashes into the server and steals the credentials database! OK, the passwords are hashed, but this provides very little protection as it’s not difficult to run through a dictionary of common passwords and find hits against stored hashes. The only protection against this is for clients to use much more complicated passwords which don’t appear in dictionaries, which they can’t remember and have to write down, making themselves more vulnerable to a password-stealing attack.
Clearly Username/Password is no longer fit for purpose. We need something better. In considering an alternative, first we should take a walk around the whole problem to make sure we have identified all of the potential weak points and back doors. The aim should be that an attacker is at all points faced with at least two problems to solve.
For Internet Authentication, we identify three main security concerns; first of all the “front door” of client access. Secondly, there is the “back door” of server integrity. Thirdly we need to insure that the “side door” enrolment mechanism is also secure.
The front door issues are the ones most focused on. For 2-factor authentication a client should have to present two or more disjoint pieces of information in order to gain access. Typically these should be two of “what they know” - a memorised PIN or password, “what they have” - some much larger piece of stored data, and “who they are” - a biometric.
Sometimes less rigorous consideration is given to the back door’s security. What about that smash-and-grab attack on the server that steals the credential database? And just how safe is the service’s enrolment process?
One obviously good idea is for the client to never just hand over their credentials to the server. It would clearly be better if the client could prove that they have possession of legitimate credentials, without actually handing them over, or indeed revealing anything about them. This apparently intractable problem has an elegant solution – it’s called a Zero-Knowledge Proof (ZKP) – and is a very useful piece of cryptographic magic. Any solution to the authentication problem should include some kind of ZKP.
Another piece of the solution is already in place. It is not hard for a server to prove its legitimacy if it uses the PKI (Public Key Infrastructure), as every major service does. To the client, this manifests as a URL starting with “https://”. In this case, the full URL is automatically checked by your browser for its legitimacy. So if you see https://www.amazon.com/ with typically a padlock symbol next to it, you can be sure you have arrived at the right site.
On the other hand, one thing we can never completely protect against is client stupidity. They may go to the wrong place like http://www.amazzon.com and spend their money there. It’s not easy to stop them. They may tell you their password if you ask them nicely. They may let you log-in to their banking app. They may give their full credit card details over the phone. Wait a minute, I’ve actually done that…
Let’s look at enrolment. Security here depends on how client credentials are formed. As long as the client chooses their own credentials and sends the associated verifier up to the server, then there isn’t much of a problem. Problems only arise when a server needs to issue credentials to clients, as an agile attacker may try and steal them. For example, when my bank issues me with a new ATM card, they send the card by post, and an associated one-time PIN, also by post, a few days later. This is clearly good practise, and sets an attacker the two problems of intercepting two postal deliveries. We need to be just as careful in an Internet environment. For a recent example of an attack based on poor enrolment practises, see https://www.zdnet.com/article/chinese-hacker-group-caught-bypassing-2fa/
To avoid credential stuffing (botnet), phishing, password spraying, man-in-the-middle and replay attacks without confusing end-users, consider our multi-factor PIN based solution, visit MIRACL for more details.
Dr Michael Scott is Chief Crypto Officer at MIRACL, one of the pioneers of Pairing-based Cryptography and the “S” in the widely used BLS and KSS families of elliptic curves. Following a distinguished career of almost 30 years at Dublin City University and an active consultant to both public and private sector, his unmatched depth in knowledge is drawn not only from his academic expertise - he’s published over 100 highly cited papers – but his genuine love of cryptography and the science behind this.
