Let's talk about (safer) authentication: The good, bad, and the ugly!

Everything you should know but are afraid to ask!

How secure are passwords?

The simple answer is that they are as secure as

Complexity and length

The longer and more complex the password, the better. The chart below shows how long it takes to crack a password using current hardware.

Passwords, to be safe, are not meant to be memorized or easy to type. A secure password is supposed to be a freaking nightmare to type in by hand or transmit by voice. Therefore, password managers and their respective plugins should do password storage and insertion into authentication forms.

The password manager should generate every password—no exceptions, no passphrases, and nothing that sounds remotely like a natural human language. Every password manager worth its salt comes with a password generator. Use it.

The password manager-generated password should be as lengthy as the remote system supports. But, of course, you will never see it, so go for 128, 256, and 512-character passwords just because you can. If the remote system supports longer passwords, use them. Why would you want to be closer to the unsafer number of characters if you could be further away?

Password managers are also complex to trick into giving credentials to the wrong site. Using a password manager along with manual clipboard operations (meaning using “copy” and “paste” instead of having them associated with the domain name) breaks an essential link in the security chain: sites should be cryptographically identified by their SSL certificates before the software decides to use the user's credentials.

Users are terrible guardians of secrets and are easily fooled into giving them away.

Pick a good password manager, and you are halfway to having a secure password system. I use Bitwarden, but there are plenty of good options (like 1Password) and terrible ones (like LastPass). Choose wisely.

Hardware vaults, biometrics and security keys

One of the best ways to ensure the user never sees a password is to generate and store it on hardware devices. These come in all shapes and forms, but the main concept is that secret tokens/keys are generated on a secure device that requires physical manipulation (touch or biometric readings) to make a secret available. Secure hardware enclaves may come in the form of computer components built into computers; that's the case with the Apple T1 chip.

Secure hardware is not a replacement for maintaining a safe computer platform. A compromised system will always act as a gateway for the information, regardless of it having been generated on a segregated secure platform. Likewise, having a touch or biometric sensors on the event toolchain does not prevent the data from being captured once used on a compromised system. While it may delay a critical security event of data disclosure, it will not stop it from happening when the user utilizes the secure device.

The end user's ability to keep a secret

Can you keep a system safe from malware? This is the hard part of the security dilemma. It is, in fact, very hard for most users (and companies alike) to keep their systems healthy and safe, and as long as passwords have to go thru an insecure operating system, they will be grabbable by bad actors.

There are strategies to keep systems relatively safe, like immutable file systems and only running signed code from known origins; however, these are only simple to implement with some significant limitations on what users can do on their working systems.

The site's ability to keep its part of the secret

All the site has to keep safe is a hash that validates the user password. If the password is strong, it will take millions of years to crack. While this is important to keep weak passwords safe, it's irrelevant for strong passwords in real-world scenarios.

While I assume no site stores the original user passwords, we all know this may be false. Unfortunately, some creative site engineers can come up with terrible ideas and implement bad practices.

Multi-factor authentication

Multi-factor authentication (MFA), encompassing two-factor authentication, or 2FA, along with similar terms, is an electronic authentication method in which a user is granted access only after successfully presenting two or more pieces of evidence (or factors) to an authentication mechanism:

MFA protects resources from being accessed by an unauthorized third party that has been able to discover or replicate a single authentication factor.

A third-party authenticator (TPA) app enables two-factor authentication, usually by showing a randomly generated and frequently changing code to use for authentication.

Regardless of how many authentication factors an authentication process has, if the machine from which the access is granted is compromised, the authentication process becomes irrelevant. Once the authentication process is successfully concluded, the attacker can steal session tokens (to use on another machine) or even use the device to further the security breach in the background.

HOTP

Sequential-interactions-based one-time password (HOTP) is a computer algorithm that generates a one-time password (OTP) using the number of previous interactions and a shared secret as the sources of uniqueness.

While the world thought this was a good idea as an additional authentication factor, the whole concept of having a symmetric shared secret is, in fact, a terrible concept, worst than having asymmetrical secrets like passwords/hashes.

TOTP

Time-based one-time password (TOTP) is a computer algorithm that generates a one-time password (OTP) that uses the current time (instead of the number of interactions like HOTP) and a shared secret as the sources of uniqueness.

Security experts believe TOTP is safer than HOTP since there is a limited time window to abuse the collected one-time password. If the shared secret has been disclosed by one of the parties, the entire window of opportunity argument is irrelevant.

Algorithms (HOTP / TOTP) and sample code

Both the authenticator and the authentication candidate compute the TOTP (resulting from the shared secret combined with the current time) value and compare the results.

Some authenticators allow values that should have been generated before or after the current time to account for slight clock skews, network latency, and user delays.

TOTP uses the HOTP algorithm, replacing the counter with a non-decreasing value based on the current time. Python implementation of both HTOP and TOTP is pretty simple to read in code.

FIDO Universal 2nd Factor (U2F)

Developed by Google and Yubico, and support from NXP, with the vision to take private/public key crypto to the masses. One of the parties has a (secret) private key (the end-user), and the website has a public key, allowing the recipient of the messages to verify and unencrypt authentication dialogs.

The asymmetrical nature of the (private/public) keys (and corresponding cryptography) makes it miles better than HOTP/TOTP. Messages are processed and stored in an autonomous device (a hardware key / secure chip enclave), and the user cannot view, extract or copy a private key to save their life.

A physical action (like touching the device) is required to prevent unassisted operations. In addition, keys can be revoked if stolen, lost, or if a user loses access privileges to the system, and multiple keys can be registered with services.

Sadly some companies have rather disastrous implementations of security standards. Most notable, and because it affects me directly, Microsoft Azure Active Directory has a rather poor implementation of FIDO u2f (and even worse if talking FIDO2) that is only semi-functional on Windows devices. See https://learn.microsoft.com/en-us/azure/active-directory/authentication/fido2-compatibility.

Note that Apple security enclave has been available on the latest version of MacOS, iOS, and iPadOS for many months. Likewise, Youbico keys have supported the protocol for years. So you can use either the apple t1 chip and keychain with Safari/Firefox or a Youbikey to authenticate with Google and Cloudflare without issues on current operating system versions. I use both all the time on the same system.

While I cannot grasp why they need Chrome (on Mac) to make FIDO u2f somewhat functional on the platform when you can use any other browser on any other system, there is no lack of examples of other browsers working on the Apple ecosystem. The same applies to Firefox and Linux (that I drive daily) to authenticate myself with no passwords on multiple systems, including AWS. Unfortunately, of all the notable global providers, Microsoft is the only one lacking a working, universally usable cross-platform (most basic FIDO U2F) implementation for Azure AD.

FIDO2 passwordless authentication

“Passkeys” if you are trendy, “webauthn” if you are not into surfing the latest wave of jargon, take the FIDO u2f elements to new heights by aggregating multiple authentication factors in a single operation.

Use a security key, camera, or fingerprint/voice reader (something you have) and an optional PIN (something you know) combined with an action (touch or look at) to create the required provisioning for the secure platform to perform the authentication operation.

When correctly implemented, it's a beautiful experience that mixes the best of all security approaches with convenience and ease of use. It is the best user experience in authentication procedures and the easiest. There is no avenue to phishing or social engineering approaches to trick users (well, a hammer and a knee may convince them to provide access to a third party).

You can test the full FIDO2 experience on the Youbico site (even without a Youbico key, using Apple implementation if your Mac/phone/ipad has a fingerprint reader or FaceID) at https://demo.yubico.com/webauthn-technical/registration. It's magic like it should be. Unfortunately, we have failed to deal with the “authentication” problem for far too long.

Protocol and sample code

https://www.w3.org/TR/webauthn-1/

https://fidoalliance.org/developers/

https://developers.yubico.com/WebAuthn/

https://developers.yubico.com/SoftwareProjects/WebAuthn-FIDO2/WebAuthn-FIDO2Server_Libraries/