Managing secrets: an era ending with passkeys

I'm hesitant: shall I add a question mark to the end of the title? Like:

Managing secrets: an era ending with passkeys?

How does that look like? What message does it send? Is it true? Can it be true? Let me take you on this journey.

In the beginning there was the password

A username and password combination to solve the problem of access.

You choose both the username and the password. Seemingly, you are in control. It's your responsibility to keep it safe, and honestly, you have/had no control over the "other side": how does the portal you just registered on stores your password.

It was a gamble.

Worst case scenario - ever: your credentials (you username and password) are stored as plain text in a database or in a flat file.

Impossible you say? Well, history has proven otherwise.

One step up on the ladder was that an encryption mechanism was introduced on the "other side": at least your credentials were not immediately "reusable".

How about your end?

Using the same password everywhere: convenience over cautiousness.

Back then, who would have thought that someone can (and will) actually connect the dots and by hacking just a single vulnerable website opens the gates to compromise all of your other online accounts.

Come on, it's just one password, I can remember it!

Many have taken the whole journey: from capturing passwords on post-its to keeping unique passwords in a password manager.

The game of usernames

Meanwhile, all sorts of games started in the username space:

• pick your own username
• your email address becomes your user name
• we give you a unique (human friendly) username
• we give you a unique ID
• you don't even need to have a username

The key problem remained the same: you have no control over the "other side": all those portals spanning across perhaps tens of years of technological debt (and advancements), it's still a gamble: you never know when and which site will get compromised.

Furthermore: you - or even the owners responsible for those services - would never find out if their services were ever compromised.

Two factor authentication to the rescue

Okay, so you have a username and a password. How about adding one more "step", an extra layer of protection to the game: not convenient, but promises an extra level of security: a time sensitive, constantly changing element.

Very smart, could work you say.

How does this setup looks like these days?

Well, if you ask me: I have a password manager tool, a database where I store all of my passwords. But not the 2FA codes.

Since the whole idea behind the multi-factor authentication step (aka MFA, or also referred to as 2FA) is to have a "second factor", ideally on a separate device, this device can be your mobile phone.

For me, it makes sense to separate the two - physically too:

• a password database with all the usernames and passwords (and URLs), and
• a separate database just for the 2FA codes.

This way, if one of those gets compromised, a separation still exists between the passwords and the codes.

Inconvenient? Super complex? No, not really. I can live with this setup.

Some cool solutions along the way

There are many, but let me focus on just a few of them for now:

Hardware tokens (aka "fobs")

Instead of getting the one time codes in an SMS (SIM hijacking, or SIM swapping anyone?) why not having a dedicated device that generates the codes, completely isolated from any connected device?

Nice idea, I have used it for many years in big enterprise setups.

Security keys (aka "hardware security token", e.g. a YubiKey)

Also something that you physically have to have in order to be able to add it as a step during authentication.

Works pretty well, offers a unique perspective on the fact that your secure private key never leaves the device.

Magic links

One of my favourites, what a great idea!

Given that you have an email address and a mailbox - that you protect in every possible way - why not use it as a receiver of a temporary value that can only be used either within a (short) period of time, or just once.

Well, actually both can be true: you can only use it once, and very often it expires within a certain period of time.

The benefit here is that the "other side" does not have to store any passwords. You still have your account and your username, but no stored password.

Plus, you don't have to store a password on your side either.

A new era begins: passkeys

The concept is nothing new: a pair of private and public keys, generated uniquely.

Your public key is actually sent to the "other side", to the service you are about to log in, however this key is supposed to be publicly accessible, by definition.

Your private key, however is never sent, never leaves your device it's generated on.

Even if the "other side" gets compromised, only your public key gets exposed - which is supposed to be public anyways - and without your private key, it's useless.

So... what's the catch?

While promising, there are a few things that are still in the way:

• Ecosystem dependence
• Account recovery

Passkeys are in most cases tied to the actual device, and its operating system's capabilities of storing and managing them.

Meaning that Apple stores and manages them differently than Google's Android, or Microsoft.

There is a possibility to "sync" between devices, however this contradicts with the original promise: that passkeys are (should be) tied to a physical device's secure element.

Which brings us to the second issue: how can you recover your passkeys in case you lose your device?

The solution here also lies in the option to be able to "sync".

What is your take?

Do you use passkeys extensively?

If yes, how do you manage them - across devices?