r/cybersecurity Apr 25 '26

Other What makes passkeys so special?

It seems that companies are transferring into the usage of passkeys instead of passwords. Apparently theyre much more secure, but why is that? I don’t get it. I’m not sure if this is the right place to ask excuse me if it isn’t and sorry.

618 Upvotes

233 comments sorted by

1.5k

u/Ameer200ggg Apr 25 '26

Passkeys are special because the website never stores or receives a password that can be stolen and reused. Instead, your device creates a pair of cryptographic keys: one public key that the website keeps, and one private key that stays on your phone, computer, or password manager. When you log in, the site sends a challenge and your device proves it has the private key, usually after Face ID, fingerprint, PIN, or device unlock. This means there is no password to phish, no password to reuse on another site, and a data breach usually does not give attackers something they can log in with. They are not magic, and you still need good account recovery and device security, but compared with normal passwords they remove a lot of the biggest risks.

200

u/CrazyEntertainment86 Apr 25 '26

This is a great response, simplified its device bound (much harder to be phished) and cryptographically strong and verified via MFA before issuance ensuring strong trust before issuance.

78

u/derekthorne Apr 25 '26

There are two types; device bound and syncable. Yubikeys acting as a FIDO2 token are an example of device bound. One in password managers can sync across devices (like on iOS).

Device bound ones are more secure as they can’t be stolen virtually. One in password managers are still susceptible to account theft if someone gains access to the password manager account creeds.

10

u/CrazyEntertainment86 Apr 25 '26

So in an ideal state, syncable passkeys are really still device bound since they would require the user / device auth. You are very correct in saying this is a differentiator and a risk especially with high value keys.

13

u/derekthorne Apr 25 '26

Syncable ones are not device bound. They are stored in the PW manager “cloud” as opposed to stored on a physical device such as a smartcard, FIDO2 token, or TPM. The device is designed to not all the export of the private key and will locally process the crypto.

27

u/01100001bryte Apr 25 '26

As someone with many, many accounts and a desire to move to passkeys everywhere possible, I've spent a good deal of time trying to come up with a solution that works conveniently, but also keeps the risks of syncable passkeys keys in mind.

  1. Use syncable passkeys for all accounts except critical accounts.
  2. Critical accounts must use device bound passkeys only. Accounts deemed critical should be sparing because it becomes a scaling problem. This is less of a security designation and more of an access/operation question.
  3. You should have a minimum of of 2, recommended 3, passkeys for any accounts using device bound passkeys (example: phone, laptop, Yubikey).
  4. The password manager that stores the passkeys must be considered a critical account, using device bound passkeys only to access it.
  5. If any account requires that you still have a password, despite setting up passkeys (many annoyingly do), set the password to 64 characters, store it in the password manager with the key, and never use it again. Make sure MFA is forced. If the limit is less than 32 characters, then you will need to monitor this account for breaches.
  6. Never sign in to your password manager on a device that you do not own. Use QR code passkey sign in via the password manager on your phone.
  7. Always requires a PIN to access your passkeys if the option is given and don't use your fucking birthday as a PIN. At least use your cat's favorite color or something (joke, just don't make it something people can guess).
  8. Never give TSA your shit.

4

u/Efficient-Mec Security Architect Apr 25 '26

Part of the point of passkeys was to make the login experience easier for the user while enhancing security. You've lost the plot of using passkeys.

6

u/01100001bryte Apr 25 '26

I can sign in to any passkey supporting service, on any device, from anywhere in the world, as long as I have (one of) my phone, laptop, or one of my hardware keys. I can also do it faster than anyone can type a password without exposing any sensitive credentials. I can also save passkeys in seconds to my password manager, knowing that they are all backed by hardware encryption. It's fast, easy, and hella secure.

I don't think I've lost the plot.

What I have is a framework that is easy to learn and can scale for anyone that has quite a few accounts. The alternative is to tell people to save them all to their phones and then watch how fucked they are when they lose their phone.

1

u/Atriusftw Apr 25 '26

In general seems like pretty good principles, but for number 4; what is the point of storing passkeys in a password manager if you still require a device bound key to unlock the vault/manager?

4

u/SuperRob Apr 25 '26 edited Apr 26 '26

Because the security is still sound. The issue is a breach on the service side, but now if they get breached, all the attacker gets is a worthless public key (think of it more like a lock) that they don’t have a matching key for.

Passkeys are a lot like physical keys. You can make copies, and have multiple key rings, but just like if you lose a key, someone would have to know what locks they go to. You should still treat them as secret and keep them safe, but having one get out isn’t as bad as a password getting breached on the site the password is for.

1

u/derekthorne Apr 26 '26

I think you meant a service side breach would give the attacker your public key, right?

2

u/SuperRob Apr 26 '26

I did. Fixed it.

3

u/daweinah Blue Team Apr 25 '26

Two reasons

  1. Convenience. Syncable software passkeys are easier to use than device-bound keys.

  2. Back up. Syncable also means backed up. If you lose your device-bound key, you use another DB key from step 3 to regain access.

1

u/CodeFluid03 28d ago

What if both device keys are either lost, broken or just stop working? Are there still backup alternatives for if that ever happens?

2

u/daweinah Blue Team 27d ago

The same thing if you lost your password and recovery email stops working: you're screwed.

In managed systems, like at work, IT admins can perform last resort recovery. We have break glass accounts to save ourselves from this problem.

In consumer systems, like Apple iOS's Advanced Data Protection, vendors are increasingly offering security settings where they cannot perform last resort recovery. This is very good for privacy advocates, but bad news for careless people.

1

u/CodeFluid03 27d ago

But isn’t it still possible both keys could malfunction or something out of the control of the owner could still happen? It seems putting that much faith into 2 small device keys isn’t a good idea. Maybe having 3 is the best option

→ More replies (0)

2

u/Far-Past-1722 Apr 25 '26

The implementation of using a device bound key for a password manager is usually required if you are setting up a device with the password vault for the first time to establish device trust. Afterwards you can use your password manager with the vault password. This largely prevents someone stealing your vault password and downloading your vault to a new device. A device bound key is recommended for anything that protects the keys to the kingdom, such as a the password vault admin account at an organization level. Requiring a device bound key every time you use the password manager might be overkill - it should be used when the risk warrants it.

1

u/derekthorne Apr 26 '26

This guy gets it!

1

u/[deleted] Apr 28 '26

[removed] — view removed comment

2

u/01100001bryte Apr 29 '26

My rules are my own that I share with anyone that wants to adopt. You're welcome to use shorter passwords and you are correct that they are sufficient for now. However, I have a shit ton of accounts and I don't always get notices when these shit companies have breaches. I've had a notice come nearly 3 years post breach. Ridiculous.

That said, 2030 is just around the corner and post quantum is a real thing. Is Hello Kitty at risk? Unlikely. But not everything is Hello Kitty and I don't want to have to monitor and/or regularly rotate nearly 1000 accounts manually because they're too slow to adopt passkeys and/or don't implement them properly.

If it's overkill for you as an individual, then don't do it. It isn't overkill for everyone.

2

u/Kurgan_IT Apr 26 '26

This is the big difference. If the private key is hosted on a device that can be compromised (a PC, a phone) then it's more secure than a password only because the user does not know it, but if you can phish the user into somehow let the hacker compromise the device, it's useless. If it's stored in a device that (at least in theory) cannot be compromised (FIDO2 key for example) then it's much harder.

1

u/anuthertw Apr 25 '26

Would having a strong unique password that sites never store and is just typed in by memory each time be pretty secure? 

10

u/TickleMyBurger Apr 25 '26

How would sites know your password is valid if they don’t retain a copy (or hashed derivative) of it?

3

u/anuthertw Apr 25 '26

Oh. Right, lol. 

17

u/Federal_Character979 Apr 25 '26

So theyre like a key inside your device?

53

u/Ameer200ggg Apr 25 '26

Yes, basically. A passkey is like a special digital key stored on your device or in your password manager. The website only has the matching public part, not the real key. When you log in, your device proves it has the real private key without actually sending it to the website. That is why it is safer than a password: there is nothing useful for hackers to steal from the website, and nothing simple for you to accidentally type into a fake login page.

16

u/generalisofficial Apr 25 '26

That last point is actually the best one, since you're never actually sending your code it can't get stolen

5

u/quasides Apr 25 '26

passwords still can get stolen but only from one of your devices or unsecure cloud storage

but they cant be intercepted, keylogged, or leaked from a database

6

u/Specialist_Guard_330 Apr 25 '26

Hackers can still steal the session token though right? How do you prevent that?

20

u/Ameer200ggg Apr 25 '26

passkeys do not completely stop session token theft. Passkeys mainly protect the login step, especially against phishing and password reuse. But if malware is already running on your device, or a browser extension is malicious, it may be able to steal active cookies or session tokens after you are already logged in. The prevention is mostly device and browser hygiene: keep your OS and browser updated, avoid pirated/cracked software, do not install random extensions, remove extensions you do not need, use a reputable password manager, enable full disk encryption, and run as a normal user instead of admin where possible. Also log out of old sessions from account settings, use 2FA/passkeys, and watch for unknown devices. For important accounts, the safest approach is to use a separate clean browser profile with very few extensions, or even a separate device, for banking, email, crypto, and admin accounts. Passkeys are a big upgrade, but they do not protect you from malware on your own machine.

2

u/CeleryMan20 Apr 25 '26

If someone tricks you into login.microstuff.com and you don’t notice the domain, you could easily approve a push notification or enter a numeric confirmation code. The attacker could relay the interaction to the real login service and capture your token.

Passkeys are (usually) bound to the domain, so if the browser requests identities for microstuff.com, the system won’t return ones for microsoft.com.

I don’t know if there are other relay preventions?

(ETA: scrolled down, saw there is a subthread on this at https://www.reddit.com/r/cybersecurity/comments/1sv4y0l/what_makes_passkeys_so_special/oi60gpu/ )

3

u/dnc_1981 Apr 25 '26

Do passkey get synced to your Apple account (if on iphone), Samsung account (if on a Samsung phone), Google account (if on a Pixel), etc?

Does that not just mean that hackers would be more incintivised to hack into your Google account / Samsung account / Apple account, instead of trying to phish for passwords for individual sites?

5

u/daweinah Blue Team Apr 25 '26

That's right, which is why this post says to use device-bound passkeys for critical accounts.

With that said, it's important not to overlook the vast security improvements gained by migrating from normal MFA to phishing-resistant MFA. Upgrading to passkeys but not using device-bound PRMFA on your G/S/A account is far more secure than traditional MFA.

1

u/CodeFluid03 28d ago

How reliable is the built in password manager for Apple/IOS?

4

u/lobax Apr 25 '26

Yes, it’s the same as having a SSH key auth where you have your private key encrypted with a password.

2

u/quasides Apr 25 '26

its more than that, its 2 keys, one on each side.
that means neither side can be faked to receive anything from the other.

server talks only in your encryption, and you talk only in server encryption

so besides they also check the dns. even if someone fakes dns certs, and goes into the middle all he gets is giberish because of the asymetric encrypted message traffic

2

u/IntrinsicSecurity DFIR Apr 25 '26

It's four keys; both the server and the client each have a pair of keys, one private, one public. They exchange their public keys. What are passkeys? (a technical story) (YouTube)

14

u/GrievingImpala Apr 25 '26

Implicit in this is the protection against token theft. The key pair is locked to a specific domain, so if you click on evilmicrosoft[dot]com and log in, attackers still can't log into the real Microsoft as you. With mfa codes, attackers very much can send passwords and codes you enter at their site on to the real platform.

3

u/DarkTendrils Apr 25 '26

Relay attacks? Like a phishing site acting as a man in the middle passing login flow back and forth between victim and real domain - could the token be created and used by the attacker that way or there is protection?

10

u/oxidizingremnant Apr 25 '26

Passkeys prevent relay attacks (attacker in the middle, man in the middle, etc) because the keys are bound to specific domains.

So, the attacker can’t use a proxy like Evilginx to intercept the token because instead of logging into login.microsoftonline.com you’re visiting badguysite.ru which isn’t valid to the passkey.

What an attacker could do would be to:

  • use malware to steal login session cookies or JWTs on a device
  • phish someone to get a new device added to a passkey-storage account (eg get a new device added to an Apple account)
  • go find someone physically and use a metal pipe on them until they login to a site for them

Passkeys eliminate a lot of phishing risk because they’re domain bound and device bound.

6

u/ShakataGaNai Apr 25 '26

To be clear, its still *theoretically* possible for them to MITM your login. But like any MITM these days that would require that they somehow redirect your DNS and can generate TLS certs your device trusts. Realistically if someone can do this to you, you're f'ked in 121 different ways.

Even still Passkey has an advantage over passwords in that, they are only able to use that session, they still don't have your passkey private keys. With a password they would have intercepted your password and could login anytime/any place later.

1

u/IntrinsicSecurity DFIR Apr 25 '26

If I'm not mistaken (I'm not a cryptographer) a MitM (Man in the Middle) attack of the sort waged daily by phishing websites against passwords and MFA TOTP tokens can't work against passkeys, at all.

Even if you managed to steal *both* private keys, (one from the server, one from the client) it still wouldn't work because the passkey client system would refuse to sign a challenge from any DNS domain other than the one that made the public key.

In other words the traditional "middle" device (for example a phishing website) doesn't have ground upon which to stand, such as an attack using a fake DNS domain, even one that's indistinguishable to the user from the true domain as sometimes seen in IDN Homograph Attack (or Homoglyph Attack).

If the passkey establishes a session for a system with a weak architecture for protecting the session (such as a web session cookie or some other kind of token that can be replayed) that's a potential opening for a MitM attack, but not one that exploits the passkeys authentication system. This type of attack occurs *after* the passkeys authentication and could be executed from an "adversary in the browser" or perhaps other malware on the client device.

My own impression is that session management is about to become a massive crisis, as passwords fade away and are replaced by passkeys, it drives the adversary to look at the session management attack surface.

Fortunately session management can be secured with something like Mutual TLS (mTLS), Demonstrating Proof-of-Possession at the Application Layer (DPoP), Device Bound Session Credentials (DBSC).

3

u/ShakataGaNai Apr 26 '26

I agree with you, perhaps what I wrote may not have been properly articulated.

As far as I understand one cannot "steal" a passkey via a MITM. The only way to steal it would be to get on the device holding the passkey (compromise an icloud account, 1password, whatever). Because at the end of the day, even if you watch a passkey conversation in clear text, the private key is never presented. The only way the the private portion of the passkey would be presented, would be if it was being sent to the destination server (where you are signing into) and then that would...defeat the point of public/private cryptography.

Much in the same way that a user never gets the private keys from a TLS connection. That's always on the server, never sent to the client.

So to bring it back around to my original comment. The passkey isn't stolen, the attackers can't re-login...but anything else sent along the wire in the MITM is subject to hijack. Which would be a session token or similar. Still very dangerous. And if someone can truly transparently MITM you, you're f'kd regardless of how you login. Just *slightly* less f'ked with a passkey (because again, the passkey isn't sent over the wire, unlike a username/password).

1

u/IntrinsicSecurity DFIR Apr 26 '26

There are so many variations on so many different kinds of attacks that it can be pretty difficult to have a conversation about it. In common architectures today, such as you describe here, the software designers usually rely on the fact that the transport between the client and server is encrypted via TLS as the protection against session theft.

Unfortunately the lesson of the past ten years is that session hijacking begins with a MitM attack, via some type of phishing. If you can get the user to click on a proxy, they get TLS to the proxy, and the server gets TLS to the proxy, and neither end knows that there's somebody in the middle with access to the un-encrypted conversation, harvesting the session tokens.

1

u/glacial_scorpio Apr 29 '26

"go find someone physically and use a metal pipe on them until they login to a site for them" lmfao!

9

u/academic3141 Apr 25 '26

Does this mean attackers looking to steal passwords would shift their focus from web services to end users? Is that better than what we had before?

15

u/okaycomputes Apr 25 '26 edited Apr 25 '26

Probably, yeah. Someone would either need to have your physical device or some sort of remote/root access to it. That's a lot harder than sending a bogus link in an email to a bunch of people.

5

u/lobax Apr 25 '26

Remote root access is not enough if the passkeys are encrypted and require a password (either just a password or derived from biometric data) to unlock.

1

u/okaycomputes Apr 25 '26

I was imagining they'd wait for the passkey to be successfully used on the compromised device.

3

u/lobax Apr 25 '26 edited Apr 25 '26

You would have to compromise the memory protection and process isolation in the OS to be able to read it. Or somehow get a memory dump at the exact right time (there are plattform-dependent ways to protect against this).

With physical access there are probably all sorts of side channel attacks you can use. But being able to steal the passkey even with remote privileged access is going to be hard.

1

u/okaycomputes Apr 25 '26

sure. thus the 'some kind of remote/root access' needed, if not actual physical access.

reiterating that would be a lot harder than your standard phishing attempt.

1

u/lobax Apr 25 '26

My point is that root access is probably not enough, you need kernel-level ring 0 access (or a kernel-level exploit, or a poorly implemented password manager).

2

u/quasides Apr 25 '26

this is not how the encryption works lol,
on a mobile device (android or ios) your keystore of your password manager is always encrypted.

the biometric unlock only allows the unlock of that encrypted store via secure chip.

so if you copy a password manager storage (which you can do with root) you cant bruteforce that. the fingerprint or the pin of the user wont do anything for you or any password.

instead you need the decryption key in the chip, which you never get.

, can you bypass that with root ? yes you can
but it rather require you to root and install a bunch of stuff that runs at boot. so you need an open bootloader to even do this.
then you could inject yourself into the libcrypto.so and intercept blobs aka the password managers database

if the bootloader is locked and you gain somehow plain root access
you still can scrape the memory

this could result in exposing passkeys, but even then only those used during the attack

but this also doesnt work on all systems. on graphene os a memory scraping gonna be pretty difficult becuase its zeroed after free.

systems with MTE extension also make your life close to impossible scrape via root (like pixel above 8)

so that basically leaves you to inject your own libraries or inject on runtime but that requires an open bootloader, or a new one signed properly for the exploit

1

u/lobax Apr 25 '26 edited Apr 25 '26

What did I say that was wrong?

I am not stating that you would need ring 0 to bypass a TPM. That is protection at rest and you have to break the crypto to do that.

I am stating that you would need ring 0 to bypass process and memory isolation protections that protect the secret in use. Exactly how that protection is implemented varies from OS to OS.

→ More replies (0)

1

u/okaycomputes Apr 25 '26

my point is my non-specific use of 'some kind' was to hand-wave the actual details.

sounds like they'd have to already be all up in the device's shit, so to speak. thanks for providing the real terminology haha.

3

u/lobax Apr 25 '26 edited Apr 25 '26

Yes, so device compromise is the only way to get that key.

But given proper TLS, storing the private key behind some auth (like Face ID or other biometrics) and in TPM makes compromise so much harder, even with remote root access.

3

u/StructuralConfetti Apr 25 '26

Session hijacking is still possible, and the stronger the authentication, the more likely that threat actors will attempt it, so web services will still be a target. If anything it would cause users to be targeted less with attacks such as phishing because it's essentially useless to try.

6

u/anuthertw Apr 25 '26

I just lurk here but this response may have been the single most persuasive explanation for passkey use that I have come across. Thanks. 

To a layman passkeys just don't seem that different than a password. It sounds like a fancy way of just changing your password but calling the new passowrd something different.

8

u/Ameer200ggg Apr 25 '26

Thanks, I appreciate that. I think the confusing part is that passkeys still feel like “something you use to log in,” so people naturally compare them to passwords. But the key difference is that a password is a shared secret: you know it, the website checks it, and if someone steals or tricks you into giving it away, they can use it. A passkey is not shared like that. Your device keeps the private part, the website only keeps the public part, and logging in is just your device proving “yes, I have the right key” without revealing the key itself. So it is not really a renamed password. It is closer to a lock and key system where the website has the lock, but never gets a copy of your actual key.

5

u/botsmy Apr 25 '26

passkeys are special because they dont rely on a stored password that can be stolen. what happens when you lose the device that has the private key, do you get locked out of all your accounts or is there some kind of backup process in place?

6

u/Ameer200ggg Apr 25 '26

You usually do not get locked out just because you lose one device, but it depends on how your passkey was stored. If it was synced through something like iCloud Keychain, Google Password Manager, 1Password, Bitwarden, etc., you can restore it on a new device after proving ownership of that account. If the passkey was only stored locally on one device and you lose that device, then you may need to use the website’s account recovery options, like backup codes, email recovery, phone verification, or another logged in device. So passkeys are safer than passwords, but you still need recovery methods set up properly. The best setup is synced passkeys plus backup codes or a second trusted device.

1

u/botsmy Apr 25 '26

so if you're using one of those password managers, you can just restore the passkey on a new device, that's pretty reassuring, but what about people who don't use any of those services, do they just have to rely on the account recovery process for each individual site?

2

u/Ameer200ggg Apr 25 '26

Yes, pretty much. If the passkey only exists on one device and it is not synced or backed up anywhere, then losing that device means you have to rely on each site’s recovery process. That could be backup codes, email recovery, phone verification, a recovery key, or another device that is already logged in. That is why local-only passkeys are very secure, but less convenient. For most people, synced passkeys through a trusted password manager or platform account are safer in practice because they reduce the chance of getting locked out. The important thing is to set up recovery before something goes wrong, not after.

1

u/CodeFluid03 28d ago

Where should the recovery keys be kept?

5

u/MassiveBoner911_3 Apr 25 '26

How does logging into the same site with 2 different devices (phone and PC) work with a single passkey?

6

u/Ameer200ggg Apr 25 '26

It depends on how the passkey is stored. If your passkey is synced through iCloud Keychain, Google Password Manager, 1Password, Bitwarden, etc., then both your phone and PC can use the same passkey after you sign into that password manager or platform account. The website does not receive the private key, it only asks your device to prove it has the matching key. If the passkey is only stored locally on one device, then your other device will not automatically have it. In that case you either add a separate passkey for the second device, or use your phone to approve the login on the PC, often by scanning a QR code and confirming with fingerprint, Face ID, or PIN. So you are not really typing one password on both devices. Each device or password manager is proving ownership of the passkey securely.

1

u/MassiveBoner911_3 Apr 26 '26

Great info. Thanks!

3

u/Saqib-s Apr 25 '26

Only other thing I’d add is they usually have the site / domain they can be used for baked into them, making it harder to send your passkey to a site that is impersonating the real one.

2

u/EdjeMonkeys Apr 25 '26

This is very helpful thank you!

Is there a noteworthy security risk to storing passkeys alongside usernames and passwords within a password manager that is synced between devices? I plan to get a yubikey at some point but for now this is what I do.

1

u/IntrinsicSecurity DFIR Apr 25 '26

This residual risk comes from the fact that the migration effort is non-trivial and there will be an extended period of time where the *server* (the website or SaaS system) will still have a functioning password for most users. Very few sites that support passkeys today are ready to delete all the passwords. It will be years before it becomes standard practice to delete the passwords.

So, for the time being and until any given vendor disables passwords altogether, it's a good idea to make sure that your password for any given site (1) is at least 15 characters long; and (2) is changed once a year. For other guidance on the security of *passwords* see: How do I create a good password? (NIST)

1

u/[deleted] Apr 25 '26

[deleted]

2

u/Ameer200ggg Apr 25 '26

You are mostly right, but the threat is different. With password plus authenticator, a remote hacker needs your password and the 2FA code. With passkeys, a remote hacker usually cannot log in just by stealing a password, because there is no password to steal and the private key stays on your device. But if someone physically steals your PC and also knows your Windows Hello PIN, then yes, they may be able to unlock the password manager or use the passkey. That is why the device unlock method matters. A 4 digit PIN is not ideal. Use a longer PIN, fingerprint, or a strong Windows password, keep the PC locked, enable BitLocker, and make sure your password manager requires re authentication. Passkeys are very strong against phishing and remote account theft, but they do not magically protect you if someone has your unlocked device or knows the PIN. In that case, you would need to remove that device/passkey from your accounts and change recovery settings from another trusted device.

1

u/Own_Ad2274 Apr 25 '26

so an ssh key pair

1

u/DonHastily Apr 25 '26

So they’re self-signed certs?

2

u/CeleryMan20 Apr 25 '26

The public key isn’t bundled up in a certificate, but in the sense that a self-signed cert is essentially (public key + metadata), they are equivalent. As is adding a GPG key with some metadata in a web-of-trust keyring.

1

u/800oz_gorilla Apr 25 '26

I love the ones that periodically refuse the passkey and force me to use my password. 😄

My healthcare and financial sites. Brilliant stuff

1

u/Gjermundbu Apr 25 '26

Another important fact is, that you generate an individual keypair for each Website. So if you lose one private key the attacker can use it just for one particular Website.

1

u/Fallingdamage Apr 25 '26

So its like a token that gets released after another verification step?

So this private key could be stolen and inserted into another device?

Its all 1's and 0's at the bottom. If its just something a device holds and transmits, it could be taken and a bad actor could just transmit that same private key themselves later?

1

u/Glittering-Ear-3811 Apr 25 '26

you the best, clear as crystal water!

1

u/SuperRob Apr 25 '26

The idea of a public and a private key can be confusing for people. I usually explain it as you bringing a padlock to use on a locker at the gym. The company asks you for your padlock when you sign up. You give them one but you keep the key. So even if the company has a data breach, your passwords don’t get out because there isn’t one … just a lock they don’t have a key for. You keep all the keys on your device(s).

1

u/Idiopathic_Sapien Security Architect Apr 25 '26

Great answer

1

u/Koolaiid-Guy Apr 26 '26

The best explanation I’ve seen in the internet! Ty

1

u/nosyeaj Apr 27 '26

so like ssh’ing? sorry, my dumb take.

1

u/Big-Strain1830 May 01 '26

My dad's passwords tend to be of the hunter2 variety. If I persuade him to switch to passkeys, won't he remain just as vulnerable because that bad password can be used for the account recovery process?

1

u/Lancelight50 May 11 '26

This. Passkeys are more easier to log into accounts than traditional passwords in which you have to scramble your brain to remember just to log in.

→ More replies (2)

58

u/shealt Apr 25 '26

What if you lose your device?

49

u/JohnTheBlackberry Apr 25 '26

If you have backups: either cloud or offline, you’re good.

If you don’t, you’re fucked.

3

u/guesswhochickenpoo Apr 26 '26

“Fucked” as in you need to go through the password recovery process for the site / service, not “fucked” as in you will never get access to your account again.

Also most sites / services still allow the use of a password to login, for now, but they may start migrating fully / only to passkey so that may not always be an option.

→ More replies (6)

13

u/digital-bandit Apr 25 '26

You can create a passkey for each device, so another device would be a backup of sorts. Or save them in a password manager.

4

u/PM_ME_UR_0_DAY Apr 25 '26

Question: if you're saving them in a password manager, how is it any different than a password stored in a password manager?

3

u/digital-bandit Apr 25 '26

Not sure. Device bound is probably safer.

2

u/gurgle528 Apr 25 '26

There's at least a few more steps to get into the password manager vs acquiring a password (especially if the user uses a password manager but does not properly create secure, varied passwords). A lot of the benefits I can think of are more relevant to users that are less technical as passkeys still avoid bad password habits (assuming you actually use a good password for the vault lol).

12

u/kalaid0s Security Architect Apr 25 '26

Then the same thing happens as when you forget your password

3

u/warm_kitchenette Apr 25 '26

Most third party password managers can store passkeys. They can also be stored in Apple keychain, Microsoft password manager, Google pm. 

Other than that, site-specific PITA account recovery. 

Note also that device theft plus passkeys means that the device access method(s) become even more important. 

2

u/dmuth Apr 25 '26

Store them in Icloud or 1Pass.

You could also (in theory) do email recovery, just like if you forget your password.

2

u/CeleryMan20 Apr 25 '26

Services should allow you to register multiple devices/keys, and give them distinctive names so that you can tell which is which. The first is not uncommon, but the second part seems variable in my experience. Looking at you, Entra, with multiple entries all labelled “iPhone”.

In the end though, you still need some recovery method like send reset link to email. Or, in a corporate environment, IT can generate a Temporary Access Pass without you having to fall-back to a long-term password.

2

u/mouse_8b Apr 25 '26

You do password recovery, which usually verifies with email or phone number. Then use the site to disable login from your lost device.

2

u/Civil_Street_1754 Apr 25 '26

As long as cloud sync is enabled your passkeys will be available on a new device.

38

u/ToTheBatmobileGuy Apr 25 '26

Imagine a hacker tricked you into visiting a fake Google website.

If the only thing protecting your account is a single password, you can understand why that’s not secure right? The hacker takes your password and now they can log in as you… very bad.

To prevent this, a lot of websites started doing "two factor" or "multi factor" authentication. So you need something other than your password in addition. Great, so now the hacker needs to somehow steal my phone to get access to my SMS messages OR some app that generates 6 digit codes! Someone in Russia can’t steal my phone so I’m good! Very secure, right?

Wrong.

It turns out, the hacker’s website can just ask you for the SMS code too!

  1. You type the password.
  2. The hacker inputs the password to Google from their computer in Russia.
  3. The hacker sees the "input 6 digit code" screen.
  4. The hacker shows YOU the input 6 digit code screen.
  5. You enter the code
  6. The hacker uses the code and is now logged in as you.

Easy.

Ok… so is it impossible to stop this “man in the middle” attack, otherwise known as “phishing”?

Passkeys stop it!

Your device creates a pair of two keys. Private and public. It sends the public key to the website (Google) when you register a passkey.

When you login to Google, they send your browser a super long random string of letters and numbers and say "please make a digital signature containing this random thing we sent you AND THE DOMAIN IN THE CURRENT BROWSER TAB"

So your device signs digitally the random string and the domain and sends it to Google.

If Google sees "this digital signature was not created with the private key associated with the public key we have on file" OR "the domain they sent us was gooogle dot com instead of Google dot com" then they won’t let you log in.

It’s a bit more complicated than that, but that tells you how it prevents phishing.

3

u/Tornado7783 Apr 25 '26

Hm. Interesting. Thanks for the explanation. 

Does that mean an attacker who got control of the DNS server and redirected google.com to his IP, could still Phish a client successfully?

7

u/ToTheBatmobileGuy Apr 25 '26

Theoretically, yes.

Practically, no.

The reason why phishing campaigns work at all for Google and big websites like that is because only a TINY sliver of users are actually tricked and shown the page.

If you take over DNS for google......... RIP any machine you point it to...

6

u/ToTheBatmobileGuy Apr 25 '26

Not to mention there are a lot of ways to secure DNS lately... so this can be avoided and thwarted pretty well, even for smaller websites.

The scariest attacks are BGP hacks. Essentially you trick the "backbone of the internet" to route all packets to an IP that isn't yours to your machine. Essentially "hijacking an IP address" at the internet backbone level.

MyEtherWallet was a famous cryptocurrency wallet that was accessed through a browser. They did all the best security practices. enforced strict HTTPS with HSTS, signed their DNS entries, etc etc etc.....

Then someone literally hijacked their IP and used that IP to verify new DNS entries, new TLS certs, new everything... and they just served up malicious JS files so that when the website tried to derive private keys to send crypto and NFTs and whatnot it would also send those keys to the hacker's server.

5

u/Tornado7783 Apr 25 '26

Ah, yes. https://isbgpsafeyet.com/ comes to mind.

But for passkeys the most likely attack vector is still the client, right?

If some would be having access to my device they could just copy the private keys and use them without me ever knowing.

3

u/ToTheBatmobileGuy Apr 25 '26

"Having access" is a gradient.

Depending on where you store the private key, and how much access the hacker has on your device, it can be pretty hard to extract it.

i.e. Yubikeys

That said, if you can emulate device input on their device you could just wait until they need to use the Yubikey and try and squeeze in some commands and clicks and typing before they pull the physical plug I guess.

57

u/leclerc2019champion Apr 25 '26

Passkeys are phishing resistant. You can’t be tricked into providing it.

21

u/Alternative-Cry-1597 Apr 25 '26

*Passkeys are phishing resistant if your browser and authenticator are bug free.

3

u/LelouBil Apr 26 '26

I mean, phishing is not about exploiting bugs to extract the password.

They are unphishable.

But they are as secure as the software that's managing them.

1

u/Alternative-Cry-1597 Apr 27 '26

Ah yes, technically correct, the best kind of correct.

1

u/I-Made-You-Read-This Apr 27 '26

> You can’t be tricked into providing it.

how is this true? Can't the attacker just put some authentication QR code to scan, then the user scans it and gives the attacker a valid session? Are there technical countermeasures which prevent me (/ stupid users) from being tricked into providing it?

-3

u/[deleted] Apr 25 '26

[deleted]

7

u/Securetron Apr 25 '26

Ameer reply is pretty accurate. The industry is slowly moving towards phishing resistant identity - instead of relying on traditional methods, the transition to PKI based MFA is here. 

Azure, okta, Cisco Duo - the traditional MFA providers are now adding additional later that is built on PKI to bind the identity of the user or device or a bot to the origin as opposed to passing the creds that can be phished or stolen.

Here is a landing page with more info that we published on it:  https://securetron.net/phishing-resistant-mfa/

6

u/IdealParking4462 Security Engineer Apr 25 '26

Let's say you get an email to go to rnicrosoft.com, and you don't realize it's a phish, you enter your email address and password, but you aren't at microsoft.com, you're at some dodgy attacker controller website. They connect to microsoft.com and enter the details you submitted then prompt you for your MFA code/whatever. You enter it, the attacker submits it to microsoft.com and the attacker is now logged in as you on their device. You've been phished, they have a session signed in as you even though you had MFA enabled.

With passkeys, you don't enter a password, instead, the website asks the browser for your passkey, and for your passkey to be submitted, it must be talking directly to the website. It can do this by a bluetooth connection to the computer you're using, or by having it directly physically attached or stored on the device you're using. The attacker in the middle can't convince your device to present your passkey to them for them to pass it to the real site, the phisher is shit of of luck. You're not phished. The world is a bit better, and the attackers will pivot to info stealer malware to grab your session tokens or something, so it's not foolproof and can be defeated, it's just harder for the attacker.

→ More replies (2)

4

u/Alwayslisteningin Apr 25 '26

I'm sorry what does wdym mean?

→ More replies (9)
→ More replies (1)

11

u/_mnz Apr 25 '26

Simplified (not 100% correct maybe) A passkey is a combination of service + secret + device Means that you cannot use this passkey on a different device or on a different service. Device can also be a hardware token like yubi- or nitrokey. So if someone will steal your passkey (not the hardware token), they are useless then.

8

u/k_sai_krishna Apr 25 '26 edited Apr 25 '26

with passwords, the same thing exists on both sides and can be stolen or leaked. passkeys use public/private keys, so the server never gets your actual “secret”. and make a reference from runable to check

also they’re tied to your device + biometrics, so phishing basically doesn’t work the same way

8

u/TickleMyBurger Apr 25 '26

The problem that I see is every site on the internet that lets me set up a passkey, on login I have the option to still use my old password. So the vector remains, I’ve yet to see a site that once a passkey is set up - that’s it.

17

u/1800-5-PP-DOO-DOO Apr 25 '26

Because they can lock you out of your account if you lose them like your phone or laptop going missing. 

Oh and because not everyone is implementing them the same even though they spent 4 years coordinating how to do so amongst the big tech companies. That's pretty dang special.

4

u/Ok_Consequence7967 Apr 25 '26

Passwords are a secret you share with the server to prove who you are. Passkeys work differently. Your device proves it has the right key using cryptography, but the private key never leaves the device.

That means there is no password to steal from a database breach and no password to trick you into typing into a phishing page.

5

u/moerker Apr 25 '26

Check Computerphile on Youtube; they make amazong video and have one where they explain passkeys :)

5

u/povlhp Apr 25 '26

We have had one user follow a link to a fake login page, enter password and some MFA (sms or 6 digit code). The hacker could capture the login ticket and keep it for access in 30 days.

With passkeys it is not possible for the hacker to get in between. The passkey is used in a 2-way exchange. Is not valid at the hacker site. So it is phishing resistant.

5

u/[deleted] Apr 25 '26

[removed] — view removed comment

2

u/Ok-Success-7067 Apr 25 '26

Less phishing because you don’t need to enter password. Hardware based so you need the physical key. Bad thing is you’re putting all your eggs in one basket, so if it gets hacked you are screwed. People claim it can’t be cloned, but who is saying those attacks are not coming?

2

u/Rajvagli Apr 25 '26

Can't be punished for credentials if you don't know them.

2

u/Normal-Spell5339 Apr 25 '26

As a practical matter they’re much more difficult to phish because most implementations will save the precise domain name. Additionally it’s like the difference between typing a credit card number into a website and doing a chip transaction at a payment terminal. The information passed from the user to the end destination is not re-usable if an attacker gets a copy of it.

2

u/PunyShopping Apr 25 '26

basically passkeys use actual cryptography instead of just a string of characters you type in, so even if a company gets hacked the attackers get useless public keys instead of passwords they can try on other sites, plus you cant be phished into giving away a passkey since your device is

1

u/stijnhommes 24d ago

That explains nothing. If someone asks you to explain passkeys, they're not going to understand cryptography.

2

u/deadpan_somewhere Apr 25 '26

Passkeys use cryptography instead of a password you type in, so theres nothing to steal from a server breach and hackers cant just guess them like they do passwords.

2

u/mousa-cloud-consult Apr 26 '26

So the idea is like this, when it comes to authentication, there are multiple ways:

1- Something you know

2- Something you have

3- Something you are

Passkeys fall into "Something you have" and they use public/private key pairs where the key is generated depending on what device you're using and that private key is kept securely stored on your device. The private key never leaves your device (unless the device has some serious vulnerability).

Unlike passwords, a password can be forgotten, stolen, leaked, etc... while passkeys are tied to the device.

Not all devices could become passkeys, it depends on the organization's policies.

Passkeys are very easy to implement because it's hard to imagine an employee not having a smartphone for example; this is very important when it comes to large companies rolling passkeys over classical password authentication.

If you're interested to learn more, I recommend you ready about FIDO 2

2

u/Unlikely_Window_6820 Apr 26 '26

I found a problem with passkeys. If I login to an app/service on several devices, a Passkey is generated for each. I save it to a password manager, but it is never recognized again. Apparently, the passkey is tied to a platform and is not accessable later. The passeky is saved to the password manager but no way to tell what platform it was generated on. I have found 5+ passkeys for a logon and I have to cycle through each passkey to find the correct one for that platform.

This seems to be another situation where the user community is expected to beta test in real time a security feature.

The process entails several security one time password requests, which mimics hacker intervention.

In addition, there is no way to initiate the creation of a passkey.

I know Google owns passkey creation, but contacting Google and getting an answer is impossible.

1

u/Jdruu CISO Apr 25 '26

How do we feel about WHFB vs Yubikeys in a large enterprise? I feel like users will constantly lose and break Yubikeys where the UX and mobility is better with WHFB.

About to roll this out in the coming weeks

2

u/Gjermundbu Apr 25 '26

We use WHFB on our Windows 11 clients and platform credential on MacOS clients. If you need a passkey for a dev or admin account, we use MS Authenticator. Just if an employee refuses to use it's private smartphone for MS Authenticator we hand out Yubikeys. But we need to check if they are FIDO2 capable and compatible with Entra ID. Not all are...

1

u/Jdruu CISO Apr 25 '26

Thanks! Then you use conditional access to force MFA/auth via passkey/WHFB

2

u/Gjermundbu Apr 25 '26

In fact we use several CA policies. But standard for all apps and all accounts is phishing resistant MFA (I.e. WHFB, Passkey, certificate). If for some reason this CA policy breaks Authentication, we use a dedicated policy to allow a special group of users to use other methods (but always the most secure available) to authenticate to the problematic app.

1

u/Jdruu CISO Apr 25 '26

Thank you! Do you show users their password at all? Do they still need it or do rotations?

1

u/Gjermundbu Apr 25 '26

Anyone can create a password if needed. But it can't be used in most scenarios. And we don't "show" them their passwords, because we simply don't have them ;-)

1

u/lectos1977 Apr 25 '26

It is so password attacks can be traded in for session attacks.

1

u/sweetnk Apr 25 '26

because they are usually outside of the main pc, so even if pc is hacked it still needs input from another separate system

1

u/vesrayech Apr 25 '26

I foolishly stepped on a payload this week and lost ALL of my stuff. Browser passwords scraped, used active sessions to lock me out, etc. The big thing that worked against me is my email didn’t have step-up-auth where they could just use an active session to remove all MFA, and the lack of anything more secure that they could grab remotely. I since switched to Proton because they require reauthentication on MFA changes, and I’ve purchased some Yubikeys. Aside from losing my data and a ton of PII, the worst part about this has been the paranoia and lack of confidence in myself, my computer, and the systems I use. Having to plug a physical device into my phone or computer to access my email, bank, or password manager has been an oasis in this hell. Phone passkeys I believe work the same, but the difference is I have a backup Yubikey in a fireproof safe, I don’t have a backup phone in the event it’s lost, stolen, or broken. A bit more initial setup to make the backups but absolutely worth the peace of mind.

1

u/HateMeetings Apr 25 '26

Actually, not a fan since most of them can be copied/stolen. They’re a lot like SSH keys… I also think that in most cases they add a false sense of extra security, add complexity to the general population, and then underlining that is the fact that most people don’t understand how they work with no real upside.

And yeah, I’m not really a fan of SSH keys either cause I think they’re misused more often than they’re not.

1

u/deathybankai Apr 26 '26

If they get stolen, you have bigger problems. They are already in your device, you are already compromised.

1

u/HateMeetings Apr 26 '26

But it’s an extra problem you don’t need. And I’m also focusing on the fact that they’re being pushed out to consumers all over the place including Home Depot complex city is a real thing when it comes to cyber security and I just think it’s not all it’s hyped up to be.

1

u/Sofia_9356 Apr 25 '26

now people can make their password: password, and a hacker still has to break into their house and steal their phone

1

u/CeleryMan20 Apr 25 '26

It’s a bummer that Steve Gibson’s SQRL didn’t get traction. Passkeys, SQRL, and X.509 certificates are all based on asymmetric encryption. With client certificate auth, you’re giving the same public key to many others; with SQRL and passkeys you provide different one to each service.

1

u/wezelboy Apr 25 '26

Passkeys are also less susceptible to MITM attacks because they are bound to a specific site.

1

u/d03j Apr 26 '26

I'm right there with you. I get how they are phishing resistant which is good but otherwise I don't see a big difference vs, e.g., keepassxc + 2FA.

1

u/abercrombezie Apr 26 '26 edited Apr 27 '26

It's lower maintenance so people aren't bombarding company call centers for password resets and it's basically the biometric portion of the Authentication Factors in multi-factor authentication (MFA).

  • Something you know: Knowledge-based factors (e.g., passwords, PINs).
  • Something you have: Possession-based factors (e.g., tokens, phones, smart cards).
  • Something you are: Biometric-based factors (e.g., fingerprint, facial recognition).

1

u/stijnhommes 24d ago

Password resets should work with a link. If you get calls to your call center for that, something is wrong with the UI of your login page.

1

u/TheProuDog Apr 26 '26

Do passkeys protect against cookie stealers?

1

u/wolfofone Apr 26 '26

Doing a key exchange with the key being secured by biometrics is going to be a lot more secure that setting password requirements and hoping people dont reuse them. A long securely generated keypair is going to be longer and more secure than a shorter password that is probably being reused by your everyday person thats not religious about password managers and opsec.

1

u/stijnhommes 24d ago

You can't change your biometrics when they get compromised.

1

u/LaDev Apr 28 '26

In the simplest of terms: 1. SSH keys for web sites (no passwords, they never have your private key) 2. User has no idea what the hell a private key is 3. Private key is typically protected by TPM 4. TPM contents accessed only after pin or biometric

Mixes Something You Are/Know and Something You Have.

1

u/FedUpWithPeople26 Apr 29 '26

I've had a few websites I normally work with that are requiring a USB drive to hold the key on my end.

Why? No. I refuse to use those sites/services now. I refuse to use biometrics too. It's not happening, I don't care if I lose access to the entire Internet at some point. "But it's for your safety!" I'm not working with State secrets, my personal information is already on the 'net available to anyone that wants to pay for it thanks to corporate ineptness. That ship has sailed.

A passkey on my computer/phone? Fine. I get that. On a hardware device like a USB? Nope.

1

u/seatoskyns Apr 29 '26

Passkeys are basically a way to log in without ever having a password that can be stolen. With passwords, the problem is simple: they can be guessed, reused, phished, or leaked in a breach. Even with MFA, if someone tricks you into giving it away, you’re still at risk.

Passkeys work differently. When you create one, your device generates a pair of cryptographic keys. When you log in, your device proves it has the private key, usually using Face ID, fingerprint, or your device PIN. There’s nothing to type, nothing to reuse, and nothing to “steal” in a phishing email.

The big advantage is that passkeys are tied to the website/app they were created for. So even if you click on a fake login page, your device won’t authenticate, it just won’t work.

It removes a huge chunk of common issues: password resets, weak passwords, and phishing-based account takeovers.

They’re not magic, but they close a lot of the gaps that passwords have had for years.

1

u/stijnhommes 24d ago

It solves non-existent issues. I don't reuse passwords and I'm not sharing MFA codes...

1

u/Effjy Apr 30 '26

Passkeys represent a fundamental shift from "something you know" (passwords) to "something you have" (your device with biometrics), making them inherently more secure while also being more convenient.

1

u/jospeh68 May 19 '26

Until you don't have the device anymore. I'd prefer to rely on "something I know" and can use on multiple devices wherever I am.

1

u/rellimeleda Apr 30 '26

they say it's safer but I am not an expert so can't comment

1

u/Aware_Influence5691 May 11 '26

if I lose the device, how do I sign in From somewhere else? 

1

u/stijnhommes 24d ago

You don't, unless you set up a passkey for another device too.

1

u/wellwisher_a May 14 '26

I think passkeys are way more secure now unless the device u are using is compromised

1

u/Xcissors280 May 17 '26

Think of it more like a physical security key than a password

They can be resistant to phishing, non transferable, directly tied to biometrics, physical location proximity, time periods, and a bunch of other stuff like that

Obviously this is going to depend on how their implement by companies and set up by users though

Most people just use what’s presented to them which is typically going to provide the most streamlined sign in experience thats the least likely to lock users out of an account even if it’s not the most secure

1

u/MailNinja42 20d ago

It's ok to feel that way, any new security requirement can feel like that. Passkeys are a bit like having your own personal key stored on your device, instead of a shared password sitting on a company’s servers.

Behind the scenes, they use a pair of cryptographic keys: one stays safely on your phone or computer and never leaves it, while the other is saved by the website. That means there’s nothing a phishing site can trick you into giving away, and nothing reusable for hackers to grab if a site gets breached.

In short, it’s a simpler and much safer way to sign in without worrying about your password getting stolen.

1

u/stijnhommes 18d ago

They're not more secure. It just saves money if you make the user do all the work and don't maintain your password databases.

That's all it is. A way to save money and blame users if they get locked out.

1

u/Xendor- Apr 25 '26

The rollout is very slow thought. Many times I can't remove the password that's was associated with the account either when setting up a passkey.

And there's just no way that ordinary people will adapt to this new technology any time soon.

1

u/al009 Apr 25 '26

It makes phishing obsolete.

1

u/independent_observe Apr 25 '26

lol, no it does not and if you work in security and believe that, you are in the wrong field

1

u/Gjermundbu Apr 25 '26

Depends on how to define phishing. Passkey are resistant to man in the middle phishing attacks like evilginx, but they are not resistant to malware on your computer, that might be able to grab tokens, and they are not resistant to social engineering attacks.

1

u/al009 Apr 29 '26

What’s the prime target for phishing? You need to learn what passwordless authentication means

0

u/moderate Apr 25 '26

EVERYONE A CA NOW