“Banking grade” authentication often means a weak OTPTECHNOLOGY
This post shows what goes on underneath the user interface of most authenticator apps. Far too often these are based on weak One Time Passwords (OTPs). OTPs are an outdated way of authenticating users and can be a serious liability for your IT security. For mobile user authentication, nextAuth provides a far superior security solution and does not require any special hardware at the server.
Assessing the security of an authentication solution can be challenging as a non-expert. Many different technologies exist and the marketing machine of your vendor will always boast being the best choice. Nonsensical terms are coined, ranging from a bunch of off-topic certifications, “banking grade”, “military grade” (and, for the kicks of it, associated Defcon levels) to “unhackable”. In this post we will focus on “banking grade”, OCRA and One Time Passwords (OTPs).
“Banking grade” security has no specific technical meaning, as it simply refers to whatever a bank is willing to use. Since some banks still use username-password, your website probably already uses “banking grade” authentication. Similarly, the OCRA (Open Authentication Challenge Response Authentication) standard does not imply strong authentication. In practise you will most often end up with this:
The above solutions are examples of One Time Passwords (OTPs), i.e. the six or more digits you need to input in your browser to prove that it is you. Nowadays, you will get a nice looking app, where the OTP might even be hidden from the user interface, making it more convenient for users. But security-wise you are stuck with an outdated authentication technology from the early 2000’s.
|Slide 1/3: Enter your username to the remote server.|
|Slide 2/3: The remote server executes a challenge response protocol with your mobile and gets back a 6 digit OTP.|
|Slide 3/3: The remote server verifies the OTP and you are logged in.|
Second factor does not necessarily increase security
Some solutions boast to provide two factor authentication, by verifying a PIN or fingerprint (or even follow the so-called risk-based approach based on location, available networks, the device being rooted or not …). Typically the verification of this second factor is done on the user’s mobile, as a way to unlock the OTP generation. Thus you being able to login to a remote server only depends on the OTP being correct or not.
|Slide 1/3: Confirm with your second factor on your mobile.|
|Slide 2/3: If correct, you get logged in.|
|Slide 3/3: An attacker enters username and then a random OTP (he does not need your second factor). For a correct OTP, he gets logged in.|
Issues with One Time Passwords (OTPs)
The biggest advantages of OTPs are that these 1) are not choosen by a user, and 2) can only be used once. This makes OTPs immume to a wide range of attacks on passwords going from password guessing to phishing. OTPs do not suffer from phishing in the strict sense, because users cannot disclose long term credentials. However, with real-time phishing tools, attackers trick users to disclose valid OTPs.
But compared with passwords, OTPs also have some shortcomings. Firstly, OTPs is more susceptible to brute force attacks — trying all possible values until you get in. Secondly, OTPs require secure hardware at the server — the server needs the shared secret key to verify the OTP.
The probability of getting a 6 digit OTP correct is one in a million. This may seem low, but compare this with the probability of winning the jackpot in a national lottery scheme, which is ten to a hunderd times lower. Hackers trying to get in to your system, might not care for which account they get in. So, even if an OTP is only valid for 30 seconds and your server blocks users that try too many OTPs in a short amount of time, a hacker can simply try the same OTP for all your users. This means that the more users you have, the more likely it is for a hacker to get the OTP for one of them correctly.
OTP uses a cryptographic Message Authentication Code (MAC) function, where both the server and the mobile share a key. This key needs to available* at the server, because the server needs this key to compute the OTP on its side for comparing it with the received OTP.
This makes the server a very interesting target, since the attacker getting hold of these keys, can impersonate all these users. In banks this is solved by installing very costly Hardware Security Modules (HSM). These HSMs ensure that the keys will never leak from the server. However, this is typically not done by providers of “banking grade” authentication since this would drive up the total cost of ownership to unacceptable levels.
nextAuth goes beyond
nextAuth has the same advantages and none of shortcomings of OTPs over passwords. nextAuth uses public key cryptography, where the server has public keys and the mobile the corresponding private keys. This can be best compared with handwritten signatures. You, and only you, can put your signature (private key). Everbody can verify your signature against a reference signature (public key), for example the one on your ID card. In our case, the server can verify that you are the one authenticating, but only you can authenticate.
nextAuth provides true two factor authentication, whereby the second factor (PIN, fingerprint, faceID) is verified at the server in zero-knowledge. Because verification is done at the server, one cannot bruteforce, or bypass, the second factor on the mobile. Moreover, since verification happens in a zero-knowledge fashion, the server does not learn the second factor. As a result, the server also does not need to store it, further adding to not requiring secure server storage.
Because nextAuth uses proper public key cryptography, you do not need to worry about a brute force attack. The probability of an attacker getting in by trying all possible values is 1/2128, which no amount of tradional computing is able to do in the foreseeable future.
The server only stores public keys, which are of no use to an attacker getting hold of these. This means that with nextAuth, you do no need secure storage on the server. It futher means that even if your server gets breached, you do not need to have all your users reset their credentials.
One Time Passwords (OTPs) are a weak form of authentication and an outdated solution. For mobile user authentication, nextAuth provides a far superior security solution and does not require any special hardware at the server.
|Secure against guessing of credentials||Yes||Yes||No|
|Secure against phishing||Yes||
|Brute force security**||128 bit||20 bit||
|Requires secure hardware (server)||No||Yes||Yes***|
* this means that the key needs to be stored in cleartext or in a recoverable form at the server. The common practise for storing passwords, i.e. hashing and salting, cannot be used because hashing is a one-way function, making it impossible to recover the key.
** a higher number means more secure (logarithmic scale). For example, a brute force security of 20 bit means for a random guess the probability of being correct is 1/220 or one in a million. Passwords are thus on average 250 times more secure against brute force attacks than one time passwords.
*** assuming a proper hashing and salting strategy at the server. The attacker getting hold of the database with hashed and salted passwords can do an offline bruteforce attack (with a average probability of 1/228). Through the use of specific password hashing functions at the server, one can make the offline bruteforce attack slightly harder. To conclude, it is not directly game over from the moment an attacker gets hold of the database, as is the case for one time passwords, but you should still change your password as quickly as possible.