Username/Password Authentication (UPA)
Today, most online services (even if they use TLS to provide encryption and server-to-client authentication), still rely on username/password authentication to authenticate the user to the server. This is trivial to crack by various methods:
- A hacker can grab the username/password database from a server, and crack the passwords from it (even if hashed with salt) at very high speed, to harvest potentially millions of login credentials. There are billions of hacked credentials for sale today on the Dark Web.
- A hacker can easily plant a keyboard sniffer on your computer or mobile device that captures everything you type and sends it to the hacker. This can be done via infected email messages or websites, and is very difficult to detect. It sends the captured keystrokes out as valid HTTP messages, that look just like normal browser transmissions.
UPA can be improved somewhat by “2FA” (Two Factor Authentication). There are various forms of 2FA in use today, such as SMS (popular with banking accounts) and OTP (using a physical token or OTP app on your smartphone).
SMS can be cracked by hackers. Some customer of UOB Singapore had his bank account emptied by a hacker who managed to intercept the SMS messages from his bank (using smartphone based malware). NIST recently deprecated the use of SMS for authentication, but backed off temporarily when many people said they could not replace it quickly). There are many hacking sites that show how to hack SMS authentication and provide tools to do it.
OTP tokens depend on running two copies of a pseudo random number sequence. One copy runs in the token or smartphone app, then other on the server. There are various schemes to keep them in sync. The token or app generates a six digit number, which is provided to the server by the user. If the number entered by the user matches the number in the server copy of the pseudo-random number generator, that is considered proof of user identity. Of course anyone could steal the token and authenticate as you (or hack the OTP app via malware on your phone). Worse, RSA Data Security had the algorithm used to generate the pseudo random sequences hacked, and had to replace some 40 million hardware tokens.
Passwords are notoriously difficult for people to create and manage. There is a readily available list of the 10,000 most commonly used passwords. Some 91% of all passwords found “in the wild” are in the top 1,000.
People frequently forget their passwords, so there must be a scheme for recovering a forgotten password (e.g. “three security questions”).
If you have the server generate a random password for you, it is almost always impossible to remember, so it is usually written down (e.g. on a post-it note under your keyboard).
If you have to use passwords on an online system, be aware that almost all of the strength of the password comes from the length of the password (number of characters) not from the complexity (at least one upper case, at least one lower case, at least one digit and at least one special character). The number of passwords that must be tried is proportional to nm where n = character set size, e.g. 26+26+10+10 for the above, and m is the password length. This goes up exponentially with increasing m, and only slowly with increasing n.
So the password t&r54(:A is actually quite weak but impossible to remember, compared to Purple*Hurricane, which is trivial to memorize but billions of times stronger than the short, complex one. Of course if someone is capturing your keystrokes, it doesn’t matter at all how strong your password is.
In general passwords are no longer viable for authentication.
2FA – Two Factor Authentication
Real 2FA is defined to be two independent factors from the three possible kids of authentication factors:
- Something you have – like an OTP token, a phone that can accept an SMS, or a private key
- Something you know – like a password or PIN
- Something you are – biometric identification (fingerprint, face recognition, voice recognition, etc)
The two factors have to be from different kinds of authenticators. Two things that you know only count as one factor. Today many schemes use a password as one factor (something you know), and an SMS or OTP as the second factor (something you have). A few use a biometric as the second factor. If one of your two factors is a password, you really only have one viable factor (password is trivial to hack today). It’s better than just password, but still not very secure.
It is better to get rid of passwords altogether (“passwordless authentication”), and use cryptography. The most common approach to this is Strong Client Authentication with a client certificate during the TLS handshake. This involves each user being issued a client cert unique to them and configuring the web server to either Require or Accept client certs. The server (and every client) must have the root cert of the client cert hierarchy installed (if the cert is not public hierarchy). After the usual Crypto Challenge to identify the server to the client, a second Crypto Challege is done with roles reversed, to authenticate the client to the server.
If a web browser is used for this, all browsers I’ve used do a very poor job of managing client certs. Once they accept a particular cert, they won’t allow you to select another one until you kill all instances of that browser. It would be better if they provided some way to make a browser forget the current client cert, or just to load a new one. None that I’m aware of do this.
Typically a web application must handle Strong Client Authentication by providing a handler for the “client cert needed” request. A list of client certs in the Certificate Store on the client is shown to the user, who can select one. That cert is then uploaded to the server for the second Crypto Challenge. It is not simple to do this, but there are examples online.
Mobile Device Used as an Authentication Token
A better approach is to do away with the browser for authentication and use another device as an authentication token. Your cellphone with an appropriate app on it is an ideal solution (see SixToken). You can do a Crypto Challenge via a push notification to your phone.
You log into the online service with just your userID (e.g. email@example.com). The server looks up your userID in a database (not a username/password database), to get your client certificate. The public key from that is used to encrypt a short string which is sent to your phone via push notification. The app on your phone asks you to approve the request (Accept/Reject). If you accept, the phone asks for your fingerprint, which unlocks your private key, which decrypts the challenge. The result (the original random string) is sent back to the server to authenticate the user (a match with the original string is proof that the user has the private key corresponding to the public key in their client cert).
The use of a biometric (something you are) and a private key in your phone (something you have) is very strong 2FA. NO PASSWORDS ARE INVOLVED.
This avoids the problems with browsers’ poor handling of client digital certificates. Your phone has a good quality fingerprinter reader (or other biometric mechanism) and a fairly good “keychain” to protect private keys. It also supports push notification.
The changes to a web server (or any other online service) are not difficult to do, and users find it very easy and intuitive to use.
Once this is deployed for online service authentication, you can also use it for transaction authorization within an authentication session. For example, anytime you charge something on your credit card, it could send a challenge to your phone to authorize it (“xxx is charging $400.00 to your yyy credit card at zzz store, is this OK?”). This could eliminate most credit card fraud. If you did not make the charge you can prevent it from ever happening. This is better than a notice like “we charged 400.00 to your card, let us know if this was not by you”.
This could also be used on 401K or other retirement accounts that users don’t typically monitor closely. When they get a semiannual summary, they are surprised to find a balance of $0, instead of $400,000. This could completely stop that kind of unauthorized withdrawal. It would be very difficult for a hacker to defraud this system without your phone and fingerprint.
Getting Key Material onto a Mobile Device
One of the problems of this kind of approach is how you get a client digital certificate and private key onto your phone, and your certificate onto the server. You must also register your phone with the push notification provider. SixToken provides a very simple signup scheme that uses IRP to securely request a client digital certificate from any IRP enabled CA and retrieve the certificate. It can also register the phone with our push provider. We have infrastructure that can automate this process easily.