From passwords to passkeys

Posted on | 2044 words | ~10mins

Before we talk about passkeys, let’s talk about something we are more used to: Passwords. Passwords have always been around. When you create an account, you define one username, one password, you confirm it, provide some more details and your account is created. For a long time, it has been more than enough for most users.

Then, banks started building internet banking solutions, we started buying small things online, we paid for subscription services like e-mail providers with credit card, we started declaring our taxes, and more and more we became dependent on tech to solve daily life things.

Online payment services also started growing. We started using PayPal to pay for things, which stores our credit card information and transfers the money to sellers. While all of that sounds amazing (and it is, come on, who has time to go to the bank nowadays?), it also came with downsides: Scams, phishing and money theft.


In Brazil, to combat scam attempts and fraudulent transactions, banks started to develop two-step authentication methods. Bradesco provided TAN Cards (in Portuguese) around 2009. It was a card containing 70 numeric combinations. For every transaction you make, you need to type one of them, which was randomly requested. After most combinations were used, the bank issued you a new card, and the cycle repeats.

Itaú came up with another solution called iToken, also around the same period. It’s a device (also in Portuguese) that randomly generates numeric combinations every 20~30 seconds, and you use those to confirm your online tasks. Since combinations are never repeated, the device also has a lifespan. After a couple of years, the limit was reached, and a new iToken was provided by the bank.

That was a very helpful solution in Brazil. Every time money was being sent out of your account, that code was requested, which would help the bank to make sure you are you.

However, if there’s one pillar in Brazil that always works no matter what and who is governing the country, it is scammers and their creativity. Scammers created very convincing apps to trick people into giving these codes, sometimes even all 70 of them.

As we can see, even though two-step authentication improved banking security by a lot, it is still prone to errors. Human beings can be tricked, phones can be stolen, and the list goes on. Also, all of that happened in an era before smartphones were as popular as they are today, which made these two security models very proprietary, and not reusable on other online websites.

A lot of that changed when Google got into it.


Back on September 20th, 2010, Google launched Google Authenticator for Android, iPhone and BlackBerry (yes, BlackBerry). On February 10th, 2011, two-step authentication on Google Accounts was also provided to general customers. Basically, the phone would be responsible for generating number combinations, just like physical devices were doing before, in a way that can be implemented by any developer, making the standard more popular across online services.

Users would also be instructed to generate backup codes to make sure login is possible. If your device breaks, or you can’t receive a call or an SMS due to lack of phone signal for example, you would still be able to get access to your account. I remember carrying these codes on my wallet to avoid getting locked in case anything happens.

Google made two-factor authentication more popular and standardized. Over time, more and more websites were implementing it. From bigger ones like Google, Microsoft, eBay, Twitter, Facebook to smaller ones, such as online forums, and many more. On top of that, in 2014, FIDO Alliance released U2F (Universal 2nd Factor) specifications. It allowed companies to design authentication devices, bringing more convenience to people, since they could use just a “pendrive” to authenticate across the web.


Nowadays, several solutions are available. Most big techs offer single sign on solutions, such as Google sign-in, Facebook Login, sign in with Apple, and so on. That delegates the task of creating a secure environment to big companies, since they would already perform all necessary checks and validations to allow you in beforehand.

If you prefer to stick to normal username/password flows, while authentication apps are still widely used, some companies opted for other flows, like sending a magic link to your email address to confirm you are the one accessing the page. PayPal might send an app notification before proceeding, and as always, although insecure, SMS containing authentication codes are still being sent for that purpose.

While it increases security in a more user-friendly way, authenticating into services can still be a lengthy process. A lot of times I was not logged into the email used to get the link, some services provide you a code, while some require you to click on the URL using the same browser, and so on.

Also, when you opt to use authenticator apps, all services expect you to store the backup codes safely. While doing that for one or two major accounts is no hassle, doing it every time you enable it on a new one will be. With passkeys, if everything goes as planned, all these issues will become a thing of the past.

Passkeys - The future?

Passkey is a new authentication method promoted by the World Wide Web Consortium (W3C) and FIDO Alliance whose goal is to get rid of username and password combination in a more streamlined way. Due to the way it was developed, it’s less prone to phishing attempts and much more straightforward.

Most operational systems are already able to handle it:

  • Windows 10 or above works with Windows Hello.
  • macOS 13, iPadOS 16, iOS 16 or above, it works with iCloud Keychain.
  • On Android 9 or above, you need to use Google Password Manager to switch to passkeys.
  • Linux with compatible browsers such as Google Chrome and Microsoft Edge.

Also, most webkit based browsers are also supported (source):

  • Google Chrome (Android and Apple)
  • Edge
  • Safari
  • Opera
  • Samsung Internet

Firefox support is also on the way, according to the forum.

If you use Android 14 (coming soon), iPadOS or iOS 17, you will also be able to use 3rd party password managers to store and sync your passkeys.


Nowadays, biometric authentication has become more and more popular. Motorola Atrix 4G was the first Android device with fingerprint reader, using a custom API. Google officially standardized fingerprint reading starting with Android 6.0 (Marshmallow). Apple first released Touch ID on iPhone 5S in 2013, and made its way to MacBooks three years later, in 2016.

This information is important because the base of passkeys relies on widespread biometric authentication being available. Today, most phones are either capable of scanning faces or fingers in a secure way, allowing the passkey standard to be built on top of that.

How it works

Passkeys work with asymmetric cryptography. Basically, every time you subscribe to a new website, a pair of private and public keys will be created. Private keys are sensitive and should never be stored by the service. They are kept safe and private on your device. Public keys on the other hand, are sent to the server, and used to make sure you are the one making operations. Google illustrates well how the process works, and you can check the video here. In a simplified version, here’s the process:

  1. User creates an account and chooses to use passkeys to login.
  2. The service needs to provide some information, for instance, which domains are allowed to use that key. That avoids users from being tricked into using the right key in the wrong website.
  3. The device generates a pair of keys, one public and one private.
  4. Public key is sent to the service in any form. This information is not sensitive, which means there’s no need for a special process to transmit them safely to the server.
  5. Private key is kept on the device, and protected by a biometric lock (face or finger). Also, some services like Google and Apple are able to sync your keys between devices, avoiding data loss in case of hardware theft or failure.

Now that we know how the process works, let’s discuss a bit about pros and cons.



Passkeys are safer. When the device generates one, the domain related to the service is bound to the key. That means, if someone creates a phishing website simulating to be from PayPal, for example, the device would not list that passkey as an option to be used, since the domain used when generating the key won’t match with the website opened by the user.

On top of that, they are protected by biometric authentication. That means only you (or people you register biometry on the device) would be able to use your credentials.

Compatibility across multiple operational systems

Passkeys can be used across OSs. If you have a MacBook and an Android phone, you are still able to log in on your MacBook via phone and authenticate safely into your device. That means you are not blocked from logging in only on devices you own, and you don’t need to have all devices from the same manufacturer:

Safari QR code example

By scanning the QR code above, your phone connects to your computer via Bluetooth and does the authentication safely. The same also works across other Systems, like iOS and ChromeOS, Android and Linux, and so on.


Like I mentioned above, the long-term goal for passkeys is to allow cloud backup for private keys, and syncing across devices. It means that if you create a passkey on your iPhone, it can be used on your MacBook and iPad for example. The same also applies across multiple Android devices, and on the long-term ChromeOS and Windows will also support such functionality.

Third party password managers can also be used. I, for example, use 1Password for passkeys syncing. All my keys are backed up on the cloud and shared across Apple and Android devices I own.


Although passkeys are amazing and very robust, there are some negative points about using it.

More and more tied to big techs

When opting for passkeys, by default, native password managers are used. That means, we delegate the task of syncing and backing up keys to Google, Apple and Microsoft by default. While for most use cases that’s not a big of a deal, that takes autonomy from users in the long term. If your account is suspended for any reason, so will be your ability to log into services using passkeys.

That problem can be circumvented by using 3rd party password managers. Then, you maintain the autonomy over the keys with capabilities to sync them between devices, with some compromise on usability.

However, most password managers don’t support cross-device sign in at the moment. That’s a feature I hope to see coming soon.

Lack of options to export keys on your own

As of now, there’s no standard for exporting passkeys. If you switch from your Android to iPhone for example, all keys must be revoked and regenerated. Not only that, there’s no practical way to, like we do with password managers, maintain your own copy of passkeys exported somewhere.

My approach to passkeys

To start, due to the issues with possibility of account suspension and loss of access to data, I would not recommend the use of passkeys with default password managers. While integration is a huge plus, lack of autonomy over data is not a compromise I’m willing to make. Therefore, I’m sticking to 1Password, which is a password manager I already use and like.

On top of that, I’m keeping a hybrid usage of it for now. Since cross-device login isn’t supported at the moment, I’m not getting rid of username/password combinations, but I’m slowly enabling passkeys for some services I use, such as GitHub, Adobe and Google.

With the services above I’ll evaluate how safe it feels to use it, and if I see any room for data theft. Even though I love 1Password for example, a security feature it doesn’t have on desktop OS is to always demand a biometric check before authenticating you into the service you use, which can be a security compromise in my perspective.