From Passwords To Web Authentication Secer's Blog - 记录互联网安全历程与个人成长经历

Today we will take a look at authentication in web-applications. One of the most important security measures. Authentication can be tricky: Technically it is the process of verifying that you are who you claim to be and in practice we rely on three factors in order to verify that you are who you claim to be.

To verify that, the three factors that can be used are:

Something you know (a secret, like a passphrase)
Something you have (like a Hardware-Token)
Something you are (like biometric data) {discouraged for a reason}

The most common authentication type in web applications is a Knowledge-based authentication: The username-password-combination. In most cases, you can only proof, that you posses a certain web identity. This is the first obstacle. Authentication as seen today doesn't mean "verified identity". I can create an account named [email protected] with a specific password. Knowing that password still doesn't proof that I'm Batman. It only proofs that I'm (most likely) the legitimate owner of this web-identity (although of course, someone could have stolen/guessed/brute-forced/{...} my password).

Knowledge based authentication has a big weakness: Humans.

Humans aren't good at generating and remembering good passwords and we (the InfoSec community) have also given them the wrong advice (alphanumeric, special chars, 8 character length at min,...) for a long time, see here for an example of this.

The worst habits are:

Weakness: Really weak passwords like 123456 or other passwords, that are easily guessable or in a dictionary.
Reuse/Recycling: Why waste a good password, right? Reusing a password across multiple services makes it easy to compromise your other identities if one of those services gets breached. One of my profs used to told me, the easiest way to obtain passwords is to open a legitimate service (like a "Online Bookmark Saver") and just wait for the people to register (oh and of course - save the credentials in plain text ;-)).

So a good password according to the new rules is:

Used once.
Quite long. How long? Well that depends. I would recommend a minimal length of 12 Characters if you choose a random password and 22+ if you choose a passphrase

Regular changing is not so important, unless a service gets breached. So the best approach at the moment is an approach like in this XKCD comic (the bottom one):

XKCD: Password strength (https://xkcd.com/936/)

Biometric

The problem with biometric authentication is, that you cannot change who you are (at least the characteristics we are using - I don't want to break your enthuisiam if you try to change yourself). So if your fingerprint gets breached and you use it for authentication, you will have a problem.

Nevertheless I see biometric as a valid second factor.

Something you have

"Something you have" could be hardware token, a One Time Password Token/App, a X509 Client/Personal certificate and so. While those are usually pretty strong, there are other problems with that:

You can lose it
Cross-platform compatibility is a hassle
You need to store/keep it in/on a safe place/device
It's not universal - not all services accepts them

The password safe - a solution?

Lots of utilities were created to help you with your password. The most common one is the password safe. It stores your passwords encrypted with one master password. Basically it is "Something you have" (the password safe file) combined with "Something you know" (the master password).

You set most password managers up the same way. First, you create a master password that's meant to be the only password you have to remember going forward and it is hugely important that you make this master password very hard to remember and impossible for an attacker to guess. Then commit it to memory.

That's the hard part. Once you've committed that master password to memory, the password manager does everything else for you. It stores credential pairs when you enter them into websites, so you never need to manually enter them again, and it makes it easier to change your existing passwords, so you can update all the times you used "password789."

Managers offer a random password generator tool in which you can control things like the length and number of special characters you want. And password managers can store lots of data, not just login credentials. They're a good place to keep things like credit card numbers and insurance information too.

So far, so good.

There is a downside with password managers: They still use a "shared secret" instead of a cryptographic function for the authentication process. Yet, you mostly don't know the shared secret any more.
This is - seen from the point of view of information security - unsatisfying. Even if the secret has a high entropy and therefore is considered 'secure', it still is sent to the Authenticator in plain text for verification. This makes the procedure
vulnerable for man in the middle and other attacks.

Other protocols already came over that by using another scheme for Authorization, for example Challenge-Response Schemes.
In a Challenge-Reponse Scheme, the password is not sent in clear text to the Authenticator:

If a client wants to authenticate, the server sends a Challenge to the client. This could be a random number or a time-stamp combination.
The client applies a crypthographic Hash-function H on the concatenated String of challenge and password, e.g. H(c + p).
The resulting Hash H' is sent to the server, who does the same thing and compares both values.

In this example a derivation of the key is still sent over the network, but not in plain text which is already a significant improvement.

A different approach is Public Key cryptography. In Public Key cryptography every participant has two keys: A public key and a private key. The private Key is never sent over the network, it is used to sign a message or decipher it. In contrast the public key is used to encipher messages and verify signatures.

While HTTP over TLS allows client authentication with x509 certificates, this method has never prevailed among end users. It is to complicated to use and not hassle-free for endusers.

In a PKI (Public Key Infrastructure), there is more then just the Keypiar to take care of:

Initial Trust: PKI relies on a "Chain of Trust", at the time this is done via 'Root Certificates', a bundle of certificates built into the OS/Browser/Trust-Store/...)
Identity verification and singing: The identity of the certificate owned has to be verified
Certificate lifecylce: A certificate has a limited life span and needs to be renewed after that
Revocation: If a private key is lost, the associated certificate needs to revoked
...

This is where webauthn comes in: webauthn takes away all those things from the user and let the browser handle that. In contrast to a client authentication via TLS, which is done on OSI layer 5 (Session layer), the webauthn is done on top of Layer 7 (Application Layer, in this case HTTP) inside the HTML code.
Webauthn can be used as single authorization factor or as second factor. WebAuthn defines abstract identifier interfaces, so that the browser can make use of different authentication factors (password, fingerprint, end so on).
This is the beauty of WebAuthn - it makes a secure, expandable authentication easy for developers and users. The browser takes care of storing the private keys secure and also handles the user authorization process.

You can find a simple, real life example of the Usage of WebAuthn here: https://github.com/apowers313/webauthn-simple-app

Since after the authorization most likely the Web-App will still rely on Sessions, it is not as secure as TLS Client authentication, which is (implemented correctly in the App) resistent against Session Stealing.

If you want to learn more about that topic, I will hold a talk about that topic at the Vienna DevFest, on 24th and 25th of November 2018 at the TU Vienna.