Questions about passkeys and eliminating passwords

[xrunner]

I've been reading and researching this for a few days. However I still can't seem to understand all the ramifications of starting to use passkeys, i.e. first with Google. I need an interactive platform with smart people who understated it so I'll ask here. Most of what they present are simple scenarios that do not have any odd things happen, and that is not how the real world works.

First Scenario

I understand what a passkey is but what I do not understand is the more arcane things that a day to day user would be confronted with in several circumstances. Let's say I set up a passkey on my computer "A". So now I can log in to Google on A with no password. Good so far. Now I have a computer "B" and I also set up a passkey on it for Google and it works.

In theory, at this point, do I still need a password for Google? I've been reading that passkeys would eliminate passwords. So what happens if I buy a new computer "C" and want to log in to Google. How would I set up a passkey initially on it without a password to begin with? Does some information come from either computer A or B from my Google account to help set up computer C?

Second Scenario

Go back to the set of two computers A and B. What if computer B which has a working Google passkey gets it's MoBo destroyed by a surge and the entire MB and CPU is destroyed. Isn't the passkey on my end stored in the TPM module or CPU? If I buy a new motherboard how do I get the passkey to work on it again without logging in to Google with my password which I thought the passkeys would eliminate?

It just seems to me that the Google password can not be eliminated at all, thus how are all these passkeys eliminating that password?

Here's an article that says passwords will be eliminated -

Do passkeys replace passwords?

Yes, passkeys are meant to replace passwords. Although still in the transition phase, more companies are gradually adopting them. By eliminating the need to memorize passwords and reducing user friction, passkeys are expected to replace traditional passwords faster than we might expect.

https://www.passkeys.com/passkey-vs-password

If it was eliminated, as I keep reading "Passkeys will eliminate passwords", then how does a new device get a passkey? I do not want to start using passkeys until I understand these types of scenarios. I'm sure any answers I get will lead to more questions.

Thank you.

[Halcyon]

I'm not sure that any services are at the stage where hardware keys have completely replaced passwords. Most still use keys as a method of multi-factor authentication (in addition to the password). In cases where users elect to simplify the sign-in process using only a passkey, the account would still have a password that can be used as a fallback method in instances where the key is lost etc...

[xrunner]

I'm not sure that any services are at the stage where hardware keys have completely replaced passwords. Most still use keys as a method of multi-factor authentication (in addition to the password). In cases where users elect to simplify the sign-in process using only a passkey, the account would still have a password that can be used as a fallback method in instances where the key is lost etc...

Thanks Halcyon, that's what I was leaning towards thinking myself but I was convinced I just wasn't understanding it. I do not see how the password can be eliminated yet. Especially if you get into trouble with a multitude of issues we all encounter with computers and the ways they can fail.

Speaking of Google now - sure I can set up passkeys but in the end if I buy a new PC or other device and I need a new passkey for it, then I have to set it up somehow by logging into Google and requesting the device have a passkey. To log in I have to use my password and two-factor auth. How the password eventually gets eliminated I do not know ...

 

[Halcyon]

So with online services such as Google, the device itself really doesn't matter. I use a Yubikey for my Google Workspace account, and I just login as normal from any device, even ones I haven't use before.

[SiliconWizard]

Yes, hardware keys have not replaced passwords at this point. They are used as an additional security measure (multi-factor).
Another example of use: on github, you can add a key to "secure" your account (I think this has become mandatory now, but possibly additional means of authentication are possible, didn't check). I use a hw key. github generates a "token" to access your account (and it's essentially just a password), the token is time-limited. To renew it, you need the hw key. But while the token is valid, you don't need the hw key.

I have a couple Feitian keys.

[abeyer]

My 2c on passkeys is that they're a clear security win for "the plebeians" who default to using the same "abcd1234!" password for their email, porn sites, and bank accounts, and who are mostly entirely stuck within some tech giant walled garden already.

But if you're comfortable using a password manager and keeping it securely backed up yourself, then passkeys are at best a marginal benefit, and likely to get you more locked in with a vendor than you should want to be, unless you jump through considerably more hoops than is necessary to just do a password manager.

So my answer would be: If you already use a password manager, probably just stay where you are and don't change anything. If you don't, look at that first and see if it's a fit. Only if not, consider passkeys.

[xrunner]

Yes, hardware keys have not replaced passwords at this point. They are used as an additional security measure (multi-factor).

I still do not know how they can say passwords will be eliminated. I'm guessing then that a biometric will be the requirement eventually to eliminate all passwords?

[radiolistener]

I still do not know how they can say passwords will be eliminated. I'm guessing then that a biometric will be the requirement eventually to eliminate all passwords?

While the idea of eliminating passwords might sound like removing them entirely, in reality, passwords are still present - they’re just stored securely inside a hardware security chip and never leave the device (should be...). This is achieved through asymmetric cryptography, where a private key is stored securely in the chip and a corresponding public key is shared with the service. The private key is used to sign or decrypt data, while the public key is used only to verify signatures or encrypt data for the key holder.

This architecture improves usability and security from the user’s perspective, but it's important to acknowledge some limitations:
1) Asymmetric cryptography is generally more vulnerable per bit of key length than symmetric algorithms like AES-256. So, while strong, it’s not inherently stronger than traditional password-based symmetric encryption.
2) The protection mechanisms of hardware keys are usually implemented in closed-source chips using proprietary firmware. This creates a trust issue: users have very limited visibility or control over how the private key is protected. There is legitimate concern that such chips may include backdoors for government access, which could potentially be abused by state actors or cybercriminals.

As for biometrics, while often marketed as a secure alternative, they come with significant drawbacks. Biometrics are not secrets - they can be very easy copied, faked, or leaked, and once compromised, they cannot be changed like a password. From a privacy standpoint, the push for biometric authentication appears to serve not just security, but also mass surveillance and data collection, often by organization with fascism ideology and bad intentions.


Given the relative ease with which data can now be extracted from supposedly secure chips, I would be cautious about placing too much trust in hardware security keys. They may be suitable for everyday use cases where the risk of compromise is acceptable, but I wouldn't rely on them for scenarios requiring high-assurance security.

As for biometrics, I would strongly advise against their use. Biometrics do not offer true secrecy - instead, they expose personal identifiers that, once compromised, cannot be changed. This makes them particularly valuable to malicious actors, who may exploit them for criminal activities or as part of broader efforts to enable surveillance and support authoritarian control structures.

Just keep in mind that if you choose to use biometrics, it’s relatively easy for attackers to steal and reuse that data to impersonate you. More importantly, unlike passwords, you cannot replace your fingerprints, iris patterns, or other biometric traits once they’ve been compromised. As a result, a hacker who obtains your biometric data could potentially exploit it for the rest of your life.

Moreover, if someone gains access to your biometric data - for example, your fingerprints, they could deliberately plant them at a crime scene or use them during the commission of a criminal act. In such a case, it may be extremely difficult for you to prove your innocence, especially if the biometric data was previously used casually, such as to unlock a phone or access a service without proper legal or forensic safeguards. Biometric misuse can thus lead not only to identity theft, but also to false attribution of criminal activity, with potentially serious legal consequences.

[Halcyon]

My 2c on passkeys is that they're a clear security win for "the plebeians" who default to using the same "abcd1234!" password for their email, porn sites, and bank accounts, and who are mostly entirely stuck within some tech giant walled garden already.

But if you're comfortable using a password manager and keeping it securely backed up yourself, then passkeys are at best a marginal benefit, and likely to get you more locked in with a vendor than you should want to be, unless you jump through considerably more hoops than is necessary to just do a password manager.

So my answer would be: If you already use a password manager, probably just stay where you are and don't change anything. If you don't, look at that first and see if it's a fit. Only if not, consider passkeys.

My only comment here is physical keys have the advantage of being phishing resistant, are stored separately to the credentials in your password vault, and require physical access to use. I use hardware keys for all my really important stuff, such as control over my domain and DNS records, access to my Google Workspace account, and access to my password vault itself.

But like data, always have a backup. Whether that's a second key, or a different method of unlocking your account(s) in case your key is lost or fails. Most vendors won't help you if your MFA method is unavailable.

[abeyer]

My only comment here is physical keys have the advantage of being phishing resistant, are stored separately to the credentials in your password vault, and require physical access to use.

Sure, but passkeys and discrete hardware tokens are orthogonal. Most passkey users don't have the hardware, and you can use a hardware key without using passkeys.

[xrunner]

Yesterday I went ahead and set up a passkey for Google for two Windoze PCs. Wasn't a clumsy process and now I just type my Windoze PIN to log in to Google.

I got several Linux Mint PCs I'd like to try it on but I'm still investigating how that would work i.e. what do you type to log in to Google once the passkey is set up ...   

[Infraviolet]

On Linux Mint, look at KeePassXC, it can store TOTP codes as an alternative to using Google's TOTP authenticator app on a phone. Once you've set it up you just open KeePassXC and choose the option to copy the TOTP, then paste this in to the login field in the browser. KeePassXC generates the right TOTP  code for the time, so long as you keep your PC's clock accurate to about +/-30 seconds of the true time.

But all things considered, a "something you know" password combined with "something you have" is always a better solution than a "something you have" alone.

There's an article here about the issues with the passkey concept, https://www.dedoimedo.com/life/passwords-passkeys.html  , particularly in that for the kinds of database breaches where passwords get leaked, a passkey is even more dangerous because unlike a password which the server can store in a hashed form, the server has to keep to hand an unencrypted version of the passkey's initial secret, from which the server can then derive the present time's TOTP code to check against a supplied TOTP code.

[Halcyon]

BitWarden is also a very decent cross-platform password manager. I use the paid version ($10/year) so I can store file attachments (backup config files, certificates etc...). There is a free tier as well.

[EEVblog]

So with online services such as Google, the device itself really doesn't matter. I use a Yubikey for my Google Workspace account, and I just login as normal from any device, even ones I haven't use before.

I use Yubikey (multiple for redundancy) for a ton of stuff where security matters, and Google Authenticator for other 2FA stuff including this forum.
I agree that we aren't really at the stage of hardware "passkeys" "just work". My Yubikey NFC doesn't work with my phone password app at the moment and it's annoying.

[EEVblog]

But like data, always have a backup. Whether that's a second key, or a different method of unlocking your account(s) in case your key is lost or fails. Most vendors won't help you if your MFA method is unavailable.

I have three Yubikeys for redundancy and have set up all three on systems that use it.

[gmb42]

On Linux Mint, look at KeePassXC, it can store TOTP codes as an alternative to using Google's TOTP authenticator app on a phone. Once you've set it up you just open KeePassXC and choose the option to copy the TOTP, then paste this in to the login field in the browser. KeePassXC generates the right TOTP  code for the time, so long as you keep your PC's clock accurate to about +/-30 seconds of the true time.

But all things considered, a "something you know" password combined with "something you have" is always a better solution than a "something you have" alone.

There's an article here about the issues with the passkey concept, https://www.dedoimedo.com/life/passwords-passkeys.html  , particularly in that for the kinds of database breaches where passwords get leaked, a passkey is even more dangerous because unlike a password which the server can store in a hashed form, the server has to keep to hand an unencrypted version of the passkey's initial secret, from which the server can then derive the present time's TOTP code to check against a supplied TOTP code.

You're confusing TOTP (RFC 6238) which does share the secret with both server and client in a form that must be available for use as required, i.e. it may be persisted in an encrypted form but must be decrypted to actually use and PassKeys that are built on WebAuthn which uses a private\public key pair where the private key can be held in a secure enclave (device bound) or, for PassKeys, can be shared, apparently securely, amongst client devices.

[JohanH]

Passkeys are more similar to pgp/gpg email encryption (uses the exact same technique with keypairs), but in a much more usable format. With a hardware key, it's becoming the best solution there is.

Still, TOTP is pretty good and I use it on all sites and services that allows it. It's better than a simple password, even if you store the TOTP code in the same password manager. But even better if you have the TOTP code on a separate device, such as your phone (such as Google Authenticator; but I prefer independent software, such as Aegis), and best if it's on a hardware key.

[shapirus]

BitWarden is also a very decent cross-platform password manager. I use the paid version ($10/year) so I can store file attachments (backup config files, certificates etc...). There is a free tier as well.

It can also be self-hosted.

[ve7xen]

On Linux Mint, look at KeePassXC, it can store TOTP codes as an alternative to using Google's TOTP authenticator app on a phone. Once you've set it up you just open KeePassXC and choose the option to copy the TOTP, then paste this in to the login field in the browser. KeePassXC generates the right TOTP  code for the time, so long as you keep your PC's clock accurate to about +/-30 seconds of the true time.

You can store TOTP keys alongside passwords, but it's not really a great idea for high value stuff. It's not really a second factor anymore if compromise of your password database is all you need to gain access. Still better than no TOTP at all, and it does help protect against credential stuffing attacks. This is worse than Passkeys for sure.

There's an article here about the issues with the passkey concept, https://www.dedoimedo.com/life/passwords-passkeys.html  , particularly in that for the kinds of database breaches where passwords get leaked, a passkey is even more dangerous because unlike a password which the server can store in a hashed form, the server has to keep to hand an unencrypted version of the passkey's initial secret, from which the server can then derive the present time's TOTP code to check against a supplied TOTP code.

There is much wrong with this article, both technical and social, but the fundamental idea that it seems to miss is that the vast majority, and by that I mean like 99.999%, of account compromises are from two forms of attack: password reuse (credential stuffing) and phishing. Nobody short of the NSA is 'hacking your phone' and breaking into the secure enclave to recover your Google passkey. Passkeys solve both of these problems in a way that is also a win for usability for most users. This is a huge win for the average user who doesn't want to deal with even password managers, let alone a separate authenticator app. Regardless of how much you try to educate users, they aren't going to 'behave right' on their own, they need systemic help.

We are finally, after almost 50 years starting to use public key cryptography for user authentication, and that is a fantastic improvement.

For best security it would be a second factor, which is generally not an option in the implementations I've seen, but for most users it's going to be an improvement over what they are using today. For highly technical users you may reasonably consider proper use of TOTP and passwords (use a password manager, never reuse passwords, keep your TOTP keys on a separate device and outside your password manager) as slightly more secure, but you're own your own to avoid phishing. But for the average user, passkeys are a huge boon for security against the actual threat model they face.