The world of Passkeys

August 22, 2023

Hello there y’all.

This blog was planned to be written about a month ago and, after reading my “Next up” summary, I remembered the reason why: I’ve assembled a group of friends and joined an AML/CFT (month-long) Hackathon where we came in 2nd place (🎉)! Can you guess what was the main tech of our team’s solutions???

Have you guessed it already??




.<I am going to save you some scrolling>




So, maybe more about the (month-long) Hackhaton in another blog post… so let’s get into the World of Passkeys.

After all the research, reading, and studying I did about the topic, and after building a P2P passkeys validation Ruby app (for the hackathon), I define passkeys as a public/private key pair, used to implement a challenge based authentication.

Its main goal is to replace passwords for user authentication, or at least to reduce the over reliance on passwords, while providing a more secure (compared with passwords) technology for authentication.

Under the hood, it uses public key encryption, so in order to authenticate, instead of providing your username and password to a website, the user and the website do what I like to call the “public/private key encryption dance”!

    If you are around tech for long, it is very likely that you've heard about ‘public key encryption’. The “dance” has the following moves:
    1. User goes to a website and identify itself
    2. Website sends a text back to the user
    3. User encrypts that text with its private key and send it back to the website
    4. Website tries to decrypt it with the user’s public key
    5. And voilà!

So, if I ‘tell’ a website that I am Helio, and I sign a piece of text that can (only) be decrypted with Helio’s public key, then the website accepts for a fact that I am Helio! Voilà!

If it quacks like a duck and it signs a digital signature, using a public key encryption algorithm, with the private key of a given duck, then it is that one instance of a 🦆 (aka The 🦆 test!)

So, in the World of Passkeys, signing up for a website means you (actually your Browser and your OS) create a public/private key, send the public key along with the sign up info (Name, email, username…) to the website, and store the private key (along with other metadata) in your Apple/Microsoft/Google account, protected using your device biometrics.

And during the sign in, you (and your browser and your OS) and the website and do the public/private key encryption dance I’ve mentioned above! Each one of ‘you’ doing a little bit of the dance plus your device biometrics validation.

So, in the world of passkeys, the important authentication information is not your password, it is your private key.

If your private key gets leaked, then your account is exposed.

But given your private key is now stored behind your device biometrics (touchID or faceID) you are protected with an extra layer.

Also, another interesting point is that websites now only store public information [your sign up info (name, username, email) and your public key], no bad actor will go after every single website you have an account on anymore… They will have to go after Apple/Microsoft/Google, which is the entity ‘you are trusting’ to store your private key.

So, this sums up what I’ve wanted to cover in this article!

Before I go, here is the Passkeys Iceberg I’ve used in a meetup talk about not too long ago!

Passkeys Iceberg

Passkeys is a really broad talk and technology stack! There is plenty to study!

Disclaimer: the pentagon labeled ‘This talk’ refers to the amount of content I was talking about during my meetup presentation, which serves as analogy about this blog post! ;-)

If you have any questions or comments, hit me up on or by .

Or just say hi , if you liked it!