Strong Client Authentication for Client/ Server Apps
Most client-server applications today, even if they provide encryption and server-to-client authentication with TLS and a server digital certificate, still use “username/password” for client-to-server authentication. In some cases, this may be strengthened to some extent through adding “2FA” (second factor authentication), consisting of an SMS message or typing in some numbers from an OTP token. Both SMS and OTP schemes have been broken, and most hackers know how to do this.
First, password authentication is totally broken. There are so many ways it can be compromised it should be considered as no authentication at all. A trojan horse malware can capture everything you are typing (including your username and password). It doesn’t matter whether the password is echoed back to you with asterisks – the malware captures the keystrokes from your keyboard. This can be relayed to a hacker in ways that are difficult to detect or stop (e.g. as outgoing web connections).
Any password-based scheme requires a “username/password database” on the server (to compare what the user types against). A hacker can gain access to the server and download this database and attack it at his leisure at very high speed. This is called “mass credential harvesting”. It does not help to add timeouts between tries during normal login or drop the connection (or block the user) after a certain number of failures – the hacker has access to all usernames and passwords. In some cases that database may be protected to some extent via “hashing with salt” – this does not stop the hacker, it just slows him down a bit. There are several billion username/password credentials that have been harvested in this manner, for sale on the darknet today.
One of the main problems with passwords is users must create and manage them. Users are notoriously bad at this. Anyone can download a list of the 10,000 most common passwords – some 30% of all passwords in use on the Internet can be found on this list. People use passwords that are easily guessed, are too short, are used for too long and on multiple sites, and then forget them (requiring a secure way to create a new password).
Strong Client Authentication (SCA) is a completely different approach that involves no password. It depends on a “cryptographic challenge”. When they connect via TLS, the server sends its server certificate to the client. The client validates that certificate then extracts the server’s public key from it. This is used to encrypt a short random string. The result of this is sent to the server as a challenge. Only the server has the private key needed to decrypt the challenge. If the challenge response is the same as the random string used to create the challenge, this is accepted as proof of identity for the server.
Normally, the client responds with username/password via the TLS encrypted channel. With SCA, the crypto challenge above is repeated, with roles reversed. Each user is provided with a private key and a corresponding client digital certificate (one unique to them). After server to client authentication, the client sends their client cert to the server. The server validates this certificate and extracts the user’s public key from it. A new short string is encrypted by the server with the user’s public key. The result of this is sent to the client as a challenge – only they have the private key needed to decrypt the challenge. If the user responds with the random string the server chose, that is considered proof of the user’ identity.
No password is required or used. If the user’s key material is kept in a hardware token (certified by FIPS 140-2) there is essentially no known attack against this. Someone can be capturing every stroke of your keyboard, watching over your shoulder, capturing every byte going between you and the website, and they still will not be able to assume your identity with access to your private key.
Unfortunately, all current browsers do a poor job of using client certificates, so Sixscape has provided a way (SixToken) to securely obtain key material on a smartphone (via our Identity Registration Protocol) and then use your phone to perform SCA to provide authentication (as well as transaction authorization if needed). The user “unlocks” their private key using a biometric (fingerprint, iris scan, etc.) This provides very strong, yet simple to use, cryptographic authentication at low cost.