[HN Gopher] The cryptography behind passkeys
___________________________________________________________________
The cryptography behind passkeys
Author : tatersolid
Score : 144 points
Date : 2025-05-14 11:22 UTC (11 hours ago)
(HTM) web link (blog.trailofbits.com)
(TXT) w3m dump (blog.trailofbits.com)
| labadal wrote:
| I love passkeys. I love them being on my phone, requiring
| biometric authentication before unlocking. I just hate the vendor
| lock in that comes with it.
|
| Does anyone know the state of the standard wrt this? I know that
| they planned on doing something about it, just haven't kept up.
| hiatus wrote:
| Can you expand on the vendor lock aspect? I have stored
| passkeys in my password manager, so they feel pretty portable
| to me. Is it that each service requires a unique passkey? That
| seems comparable to how each service would require its own TOTP
| seed.
| supportengineer wrote:
| Your password manager came from a vendor. As a thought
| exercise, switch vendors.
| EnPissant wrote:
| Bitwarden exports include passkeys.
| dboreham wrote:
| Have you actually tried exporting a passkey and importing
| it into another manager, then successfully authenticate
| with it?
| coldpie wrote:
| KeepassXC lets you export the private key, which you can
| then back up or import into another KeepassXC instance. I
| have tested this, it works. I even shipped my exported
| private key off to a friend in another state and he was
| able to import it into a KeepassXC instance and log in to
| my account. Presumably another password manager could
| support importing the data, as it's just plaintext,
| though I don't know if any do.
|
| Unfortunately the spec authors think this export feature
| violates the spec and have threatened KeepassXC with
| being banned by authenticating websites[1]. This explicit
| support from the spec authors for client banning makes
| passkeys non-viable to me. The websites I log in to
| should not be able to restrict what clients I choose to
| use to manage my own data.
|
| [1] Spec author writes, " _To be very honest here, you
| risk having KeePassXC blocked by relying parties. ...
| (RPs [may] block you, something that I have previously
| rallied against but rethinking as of late because of
| these situations)._ "
| https://github.com/keepassxreboot/keepassxc/issues/10407
| EnPissant wrote:
| Just having the data exported is peace of mind for me.
| It's trivial to import or convert to another format (even
| if not implemented now), so the worst-case scenario is
| acceptable, especially considering how much better
| Bitwarden + Passkeys are to every other form of
| authentication.
| cyberax wrote:
| BitWarden is OpenSource. I did try importing the export
| using my own hosted BitWarden server, it worked.
| Steltek wrote:
| From the article:
|
| > But how can websites know whether its users are using
| secure authenticators? Authenticators can cryptographically
| prove certain facts about their origins, like who
| manufactured it, by generating an attestation statement when
| the user creates a passkey; this statement is backed by a
| certificate chain signed by the manufacturer.
|
| How many scummy companies trot out "Let me protect you from
| yourself" to justify taking away their users' freedoms?
| yladiz wrote:
| Unfortunately I don't think there's much to help with vendor
| lock in directly (like, you may or may not be able to export
| the private key(s) depending on the tool, and in some cases
| it's definitely not possible like with a hardware key), but any
| website that supports passkeys supports WebAuthn in general so
| you shouldn't have difficulty migrating to another tool if
| desired, although you would need to register again.
| reginald78 wrote:
| Passkeys support an attestation anti-feature, enshrined in
| the spec. This feature can be abused (and will be IMO, why
| put it in the spec otherwise?) to limit which providers can
| access a service. Lock-in is built into the design.
|
| One of the developers already threatened to use it against
| keepass when they built an export feature he didn't agree
| with.
| parliament32 wrote:
| Attestation is probably the best feature of passkeys.
|
| From a corporate compliance perspective, I need to ensure
| that employee keys are stored in a FIPS-compliant TPM and
| unexportable. Key loss is not an issue because we have, ya
| know, an IT department. The _only_ way I can ensure this
| happens is by whitelisting AAGUIDs and enforcing
| attestation.
|
| With these factors I can also get out of the MFA hellhole
| (because I can prove that whitelisted vendor X already
| performs MFA on-device without me having to manage it: for
| example, WHFB requires something you have (keys in your
| TPM) and either something you are (face scan / fingerprint)
| or something you know (PIN), without me having to
| store/verify any of those factors or otherwise manage
| them). Same goes for passkeys stored in MS Authenticator on
| iOS/Android.
| yladiz wrote:
| But most passkey providers don't return attestation data.
| How do you get the data?
| parliament32 wrote:
| Attestation is not provided by the passkey provider
| itself, but the OS.
|
| For example, iOS uses the App Attest service (https://dev
| eloper.apple.com/documentation/devicecheck/prepar...). On
| Android, you get it from Google Play Services (https://de
| veloper.android.com/google/play/integrity/overview) then
| the built in key attest service
| (https://developer.android.com/privacy-and-
| security/security-...). MS Authenticator does all the
| legwork and returns the results to you at sign-in time.
|
| On Windows, WHFB has this built in (obviously). On macOS,
| this comes from Platform SSO
| (https://support.apple.com/en-
| ca/guide/deployment/dep7bbb0531...).
| coldpie wrote:
| This is fine for corporate settings, where the data is
| not owned by the user but by the company. But it's
| completely unacceptable for managing one's own personal
| account. What do I do if I do not trust proprietary
| software to manage my ability to log in to online
| services? How can this be compatible with open source
| passkey providers?
|
| The spec failing to distinguish between these two cases
| is a major flaw and completely kills passkey viability
| for personal accounts until they resolve it.
| WorldMaker wrote:
| Apple has stated very publicly and in multiple
| places/ways that Consumer Passkeys will _never_ include
| attestation data on Apple hardware. That 's not "the
| spec", but it is still currently a big enough moat to
| protect Consumer usage of passkeys away from Corporate
| needs, given most Consumer apps/websites probably want
| iOS/iPadOS/macOS (in decreasing interest) users today.
| coldpie wrote:
| > Apple has stated very publicly and in multiple
| places/ways that Consumer Passkeys will never include
| attestation data on Apple hardware.
|
| I'm interested in reading more about this. Do you have
| some links? I did some quick searching of the terms you
| mentioned and nothing obvious came up.
| WorldMaker wrote:
| Yeah, it's unfortunate we live in an age where searching
| for things is harder and less likely to turn up the
| results from even a couple months ago.
|
| Some quick bits and pieces from my own searching just
| now:
|
| Apple's documentation on Passkey attestation is entirely
| under "declarative configuration", their terminology for
| mobile device management (MDM) corporate tools:
| https://support.apple.com/guide/deployment/passkey-
| attestati...
|
| It is noticeably absent from, for instance,
| AuthenticationServices documentation: https://developer.a
| pple.com/documentation/authenticationserv...
|
| On non-attestation Passkey responses intentionally send
| an empty AAGUID for privacy/Apple's belief in the spec's
| suggestion to send an empty AAGUID:
|
| > iCloud Keychain is one of the few (maybe the only?)
| passkey authenticator that currently follows the spec and
| will use an all-zero AAGUID.
|
| From: https://developer.apple.com/forums/thread/739004
|
| On the technical side of limitations of attestation for
| consumer Passkeys (due to iCloud Keychain sync):
|
| > Passkeys do not provide an attestation statement, as
| the attestation model currently defined in WebAuthn
| wasn't designed with syncing credentials in mind.
|
| > Attestation was designed to attest to a specific
| device, exclusively at the point of creation, with a
| specific set of security properties. It doesn't make
| sense for synced credentials for a number of reasons,
| including syncing to devices with different security
| properties, changes in security properties that happen
| after key creation, security properties of the sync
| fabric, sharing the passkey, or exporting to other
| passkey providers. We're working hard with W3C and FIDO
| to solve these problems.
|
| From: https://developer.apple.com/forums/thread/708982
|
| (I believe some of the problems being solved in that one
| in 2022 is referring to how we got the "uvi" and "uvm"
| extensions to Passkeys, neither of which is in
| attestation data nor attested in any way, and both
| designed for a general semblance of user privacy:
| https://www.w3.org/TR/webauthn-1/#sctn-uvi-extension)
|
| I believe the juiciest quotes I'm looking for are buried
| in WWDC videos and I can't find a transcript search tool
| just yet.
| parliament32 wrote:
| Excellent writeup. This is the true kicker:
|
| > Passkeys do not provide an attestation statement, as
| the attestation model currently defined in WebAuthn
| wasn't designed with syncing credentials in mind.
|
| On _any_ platform, attestation and "syncing" are
| effectively opposites. Either you're getting attestation
| that the auth comes from a secure application and on
| secure hardware (read: non-exportable in-TPM crypto
| material), or not.
|
| As usual, it's a tug-of-war between security and
| convenience.
| eikenberry wrote:
| Attestation is only about security if there are ways for
| people to handle it themselves. Think of them like certs
| where anyone can buy one or get one for free using lets-
| encrypt. I should be able to attest my own keys in a
| similar way. If I cannot then they are not really about
| security but about control and lock-in.
| cyberax wrote:
| > Passkeys support an attestation anti-feature, enshrined
| in the spec. This feature can be abused (and will be IMO,
| why put it in the spec otherwise?) to limit which providers
| can access a service.
|
| The problem is that Passkeys really conflate two separate
| feature sets:
|
| 1. Synchronized password replacements. They _have_ to be
| represented as accessible clear-text to be synced between
| devices, at least during transit. So they can be stolen,
| for example, by malware that scans RAM for keys.
|
| 2. Keys that never leave a hardened hardware devices. Since
| they never leave the device, they can't be synced. But
| they're completely secure.
| lxgr wrote:
| This is largely a problem because the specification does
| not cleanly call these out as two completely different
| feature sets, e.g. via "profiles" or a similar mechanism.
|
| Effectively implementations already do that, and the spec
| could clear things up a lot by clearly defining one
| profile for synchronizing, non-attestation-capable,
| discoverable credentials called "passkeys", and another
| for hardware-backed, non-exportable, attestation-
| supporting ones called something else.
| lxgr wrote:
| None of the common passkey implementations support
| attestation.
|
| Apple doesn't support it at all anymore; Google only
| supports it for non-synchronized credentials (which are
| arguably not passkeys). Bitwarden obviously doesn't either
| (it can't, as a pure software implementation).
|
| > One of the developers already threatened to use it
| against keepass when they built an export feature he didn't
| agree with.
|
| Developer of what? There's no competing software solution
| that supports attestation, and hardware authenticators
| complement software ones, rather than compete with them.
| proactivesvcs wrote:
| https://github.com/timcappalli, "passkeys,
| FIDO2/WebAuthn, and digital credentials @ okta"
|
| Not directly threatening but within that frame of mind:
|
| https://github.com/keepassxreboot/keepassxc/issues/10407#
| iss... https://github.com/keepassxreboot/keepassxc/issues
| /10407#iss...
| supportengineer wrote:
| For me, the only thing that makes passkeys viable is backing
| them up in the cloud and automatically syncing them across
| devices. Otherwise, I do not trust them.
| TechDebtDevin wrote:
| What do you use?
| dboreham wrote:
| Not the parent, but the obvious answer is: a hard token
| (e.g. Yubikey). After all passkeys are just a software
| emulation of the smart card / FIDO2 mechanism that's been
| around for many years.
| crote wrote:
| This doesn't solve the problem, unfortunately.
|
| The issue with hard tokens is that there is only _one_ of
| them. By design, you can 't back up a Yubikey's content
| to a second token. This means that any time you add 2FA
| to a new account, you must have all of your hard tokens
| in your possession to enroll them. This means a "one
| token on your keyring for daily use, one token in a
| safety deposit box as backup" approach isn't possible.
|
| Yubico did propose a potential solution five years
| ago[0], but that proposal seems to have gone nowhere.
| Until something like that gets implemented, FIDO2 (and by
| extension Passkeys) requires some form software
| implementation backed by cloud synchronization to
| actually be usable for the average person.
|
| [0]: https://www.yubico.com/blog/yubico-proposes-
| webauthn-protoco...
| hanikesn wrote:
| It works well enough. When you need to signup for a new
| service on the go, you can add your backup key when you
| get to it. Having the backup key in a safety deposit box
| hardly accessible seems like a non-goal given you protect
| it with a pin with a very limited number of retries.
| bitzun wrote:
| I keep it in a secure separate location in case my house
| catches on fire.
| godelski wrote:
| > When you need to signup for a new service on the go,
| you can add your backup key when you get to it
|
| Good on paper, bad in practice.
|
| Requires you to remember doing that each and every time.
| Incidentally this isn't that different from just grabbing
| your keys like the parent suggested. Only it introduces a
| new variable: time delay. A lot can happen in that time
| and we all know the reality is that even a diligent
| person is going to slip now and then. It surely isn't a
| reasonable expectation for an average person.
| blibble wrote:
| I have three: 1) local usage 2) local backup key 3)
| remote backup key
|
| every few months I swap 2 and 3, and re-enroll any
| missing (kept track of with a spreadsheet)
|
| quite annoying, offline enrollment would be considerably
| better
| lxgr wrote:
| > Having the backup key in a safety deposit box hardly
| accessible seems like a non-goal
|
| It's absolutely a goal, since a PIN doesn't prevent your
| security key from loss, theft, or physical destruction.
| johnisgood wrote:
| I'm not sure if this is satire. You trust the "cloud" and
| whatever does the syncing to the cloud? I definitely don't
| trust anything that "syncs to the cloud".
| paulryanrogers wrote:
| > I definitely don't trust anything that "syncs to the
| cloud".
|
| What if you lose your device? Do you install alternate
| passkeys in a second device? Do you have to do that for
| every site and service?
| johnisgood wrote:
| I use KeePassXC, and I have backups, if that counts, at
| least for passwords/passphrases and TOTP.
| lurking_swe wrote:
| do you have offsite backups?
| jonasdegendt wrote:
| I read their comment to be "I trust myself to lose a
| hardware key, but not a software key that's backed up and
| synced across all my devices."
|
| That's one way to look at it: passkeys are just a more
| convenient form of authentication compared to passwords.
| Although in my mind you're arguably not achieving a whole
| lot considering the security bottle neck is still the same,
| being the login to your password manager.
|
| I use physical Yubikeys so I'm a bit out of the loop here,
| but are there any methods for protecting your root password
| to your password manager in this scenario?
| recursive wrote:
| Probably not satire. He/she doesn't need _you_ to trust it
| for them to use it.
| lxgr wrote:
| Sure, why not? The cloud is just somebody else's computer,
| and if I don't trust that somebody to not take a peek, I'll
| make sure to encrypt my data first.
|
| Many password managers do just that.
| taeric wrote:
| I always ask how you expect to defeat the vendor lock in?
|
| Effectively you have a secret that you are using to
| authenticate yourself. With pass keys managed by a vendor, you
| are trusting that vendor to manage your secret. If they are
| able to give your secret to someone else, then they can no
| longer confirm who all knows your secret.
|
| I'm sure you can come up with a protocol where you can fan out
| access to the secret in a way that requires fanning back
| messages to you. But I don't see any clear way to do so that
| doesn't increase the communication burden on everyone.
|
| I'm also sure smarter people than me can surprise me with
| something, here. But secrets that can be shared historically
| tend to not be secrets for long.
| blibble wrote:
| > I'm sure you can come up with a protocol where you can fan
| out access to the secret in a way that requires fanning back
| messages to you. But I don't see any clear way to do so that
| doesn't increase the communication burden on everyone.
|
| the spec actually supports this, it's called caBLE
| taeric wrote:
| Right, that flow seems somewhat straight forward and is
| roughly what I had in mind with my sentence. It doesn't
| really break you out of vendor involvement, though? You
| both still have to be fully in on the whole flow. Right?
|
| Asked differently, how does this get a vendor out of the
| picture?
| lxgr wrote:
| caBLE is not a specification for transferring secrets, but
| for mediating (temporary) access to them.
|
| But the FIDO alliance is apparently working on that:
| https://fidoalliance.org/fido-alliance-publishes-new-
| specifi...
| jp191919 wrote:
| I use KeepassXC on my PC. Not sure of an app for mobile though.
| vngzs wrote:
| I can register my Yubikeys on account.google.com (and around
| the web, e.g., fastmail.com) as passkeys. If you visit the
| account security page[0] and enable "skip password when
| possible", then you can log in to Google with only a Yubikey-
| backed passkey.
|
| If you have old Google creds on your Yubikey, you may have to
| first remove those creds from your account (because there are
| older and newer protocol choices, and with the old protocols
| enabled Google will not support passwordless login).
|
| Multiple yubikeys are required if you would like to have
| backups; there is no syncing between keys.
|
| For support matrices, see [1].
|
| [0]: https://myaccount.google.com/security
|
| [1]: https://passkeys.dev/device-support/
| zikduruqe wrote:
| I just use a Trezor One (yes, a bitcoin hardware wallet).
|
| I back up my 12 word seed phrase, and then I can restore any
| and all my TOTP/FIDO/passkeys with another one if needed.
| kccqzy wrote:
| I tried setting this up for a non-technical friend who was
| gifted multiple brand new Yubikeys. The goal is to log in to
| Google using any one of the Yubikeys with no password.
| Unfortunately doing so causes Chrome to pop up a dialog
| requesting a PIN for the Yubikey. How did you solve that
| problem?
|
| Searching online I found an answer on Stack Overflow stating
| that a PIN is required in this case:
| https://stackoverflow.com/a/79471904 How did you bypass it? I
| also find it idiotic that it is required. A PIN is just a
| password in another name, so we are back to using Yubikeys as
| the second factor in 2FA rather than a password replacement.
| AnotherGoodName wrote:
| Passkeys need to have two factor to count as a passkey per
| the standard. Otherwise in theory someone could steal your
| key alone and get in (a big risk).
|
| You need to buy a newer Yubikey with biometrics to make
| this work. I assume you have an older Yubikey and Google is
| getting to the standard by asking for a PIN.
|
| I have a https://www.yubico.com/products/yubikey-bio-
| series/ and it works with Google exactly like you want it
| to, no PIN required. It's completely understandable to
| require a PIN if you don't have one of these though.
| AnotherGoodName wrote:
| You can also simply register all your devices individually as
| a passkey and login with any one of them. Part of the point
| of the passkey standard was that you can simply have your
| laptop/phone/etc. act as a Fido2 backed security key in its
| own right. So if you have multiple devices it's pretty easy
| to set them all up as your passkeys.
|
| Eg. My Microsoft desktop, my Google phone, my Apple laptop
| all have passkeys setup individually that allow login to my
| various accounts such as my Google account.
|
| So they aren't at all synced. They are all from different
| vendors but they can all login since i set them all up as
| passkeys. It's easy to do this too. Setup one site for
| passkey login via phone, go to that site on your desktop and
| select "auth via phone passkey" and use the phone passkey and
| then once logged in on the desktop go to account setup and
| select "Create a passkey on this device". The end result is
| you have multiple hardware security keys, namely your phone,
| desktop and laptop.
| xyzzy123 wrote:
| My issue with this is the NxM problem, if you want to do
| this on 10 websites with 5 devices you need to maintain 50
| passkeys.
| AnotherGoodName wrote:
| For myself it's really only the Google/Apple/MS accounts
| i'm using with passkeys so far (and third party sign
| in/chrome password syncing for the smaller sites) so N is
| small right now.
|
| Hopefully better syncing comes soon but i'm ok with the
| current situation for now.
| xyzzy123 wrote:
| It seems like the obvious endgame is most people will use
| very strong auth between their devices and Google /
| Microsoft / Apple and then federate to everything else.
| All other workflows will become niche because it's not in
| monopoly interests to build features that make anything
| else convenient or manageable.
|
| This is where the incentives push and is why we're
| unlikely to see usable or easy passkey sync.
|
| I'm sort of ok with this (it will be a net security
| improvement) but it saddens me a little to see more of
| the web come under centralised control.
|
| Most people won't fully understand the implications of
| this, which will be that the right law enforcement
| request will instantly unlock every service you have
| access to regardless of jurisdiction.
|
| Plus lots of secondary effects relating to fed auth
| providers having increasing leverage over the web in
| general.
| kccqzy wrote:
| The NxM problem is at least better than the other problem
| where a website or app requires at _most_ one passkey.
| WeChat (which is basically required if you need to talk
| to business associates or friends in mainland China)
| simply does not support multiple passkeys.
| recursive wrote:
| This scares me because I could get fully locked out if my
| house burns down or something. I like this property of a
| password manager. This seems to be in direct conflict with
| the design goals of passkeys.
| AnotherGoodName wrote:
| Non-passkey based account access still works. As in i can
| go into my Google/Apple/MS account settings right now and
| in the security tab there's a ton of different options
| you can set.
|
| Backup codes, sms phone recovery, alternate recovery
| email are all there in all of the above.
|
| It's no different to forgetting your password/losing
| access to your password manager is it? As in i've
| literally at points lost access with passkeys (i only had
| 1 at the time) and the way i got back in was very
| straightforward and no different to losing access to a
| password manager. I got an email and typed my old
| password and i got back in and re-setup my passkeys.
| dvngnt_ wrote:
| I've been using keypassxc which supports passkeys. It
| works for github at least
| lxgr wrote:
| Many password managers these days support passkeys and
| can synchronize them in whatever way you use to also sync
| your passwords (i.e. a cloud backend, but also a self-
| hosted Syncthing shared folder etc.)
| godelski wrote:
| > there is no syncing between keys
|
| This seems like a key failure point to me and why I've been a
| tad resistant[0]. If there isn't some form of automatic
| backup then I guarantee I will not have a sync when I need it
| the most.
|
| There is a similar problem even in OTPs. I switched phones
| not too long ago and some OTPs didn't properly transfer. I
| actually lost some accounts due to this, luckily nothing
| critical (I checked critical things but it's easy to let
| other things slip). The problem is that registering a new OTP
| removes the old ones. In some cases I've used recovery codes
| and in others the codes failed. IDK if I used the wrong order
| or what, but I copy-paste them into bitwarden, and I expect
| this is typical behavior.
|
| 99% of the time everything works perfectly fine. But that 1%
| is a _HUGE_ disruption. With keys, I would even be okay if I
| had to plug my main key into a dock to sync them. Not as good
| as a safe, but better than nothing. I feel like we 're trying
| to design software safes like we design physical safes. But
| if you lose your combo to a physical safe you always have
| destructive means to get in. With digital, we seem to forget
| how common locksmiths are. Googling, numbers seem kinda low
| but I'm not in a big city and there are at least 4 that I
| pass by through my typical weekly driving. So it seems that
| this issue is prolific enough we need to better account for
| actual human behavior.
|
| [0] Don't get me wrong, I love them but I'm not willing to
| not undermine them via OTP creds because I need some other
| way in.
| kccqzy wrote:
| I feel sorry for you, but I've also experienced bugs in
| password managers that fail to sync plain old passwords.
|
| I feel like if I must choose between a 99% reliable syncing
| solution, and a non-existent automatic syncing solution
| that requires manual syncing, I would still choose the
| latter for its mental simplicity.
| godelski wrote:
| My point is that we need to address and solve these
| issues. I agree with you, but if we dismiss them then
| they don't get solved. The best algorithms are useless if
| they're too complicated to use and can't fit the reality
| of an average user. Currently they are hard to maintain
| for _technical_ users!
| namro wrote:
| On Android, Keepass2Android developer is working on supporting
| passkeys in the near future
| (https://github.com/PhilippC/keepass2android/issues/2099) but
| I'll be honest, I haven't dedicated enough time learning about
| passkeys to be sure the app will be able to support all
| implementations of passkeys and avoid vendor locking
| completely.
| iknowstuff wrote:
| https://strongboxsafe.com/
| shellcromancer wrote:
| The FIDO Alliance (who wrote the WebAuthn spec with the W3C)
| has a draft specification for a format (Credential Exchange
| Format) and protocol (Credential Exchange Protocol) for
| migrating passkeys and other credentials [1]. I don't think
| this is implemented by any providers yet, but it's being worked
| on.
|
| [1] https://fidoalliance.org/specifications-credential-
| exchange-...
| an_d_rew wrote:
| 1Password integrates with all pass keys on my iPhone, my Mac,
| and my Linux box.
|
| By a far and away WORTH the subscription, for me!
| drdrey wrote:
| doesn't that mean your passkeys are now about as secure as a
| regular password?
| kbolino wrote:
| A passkey is a public-private keypair strongly tied to a
| specific site. Sites never have access to the private key,
| and the key will never be presented for use on the wrong
| site. Those two advantages remain even if the passkey is
| stored in software or synced over the cloud.
| johnmaguire wrote:
| Passkeys are highly phishing resistant in a way that
| passwords are not and are not subject to credential reuse
| (though password managers somewhat solve the first problem
| and almost entirely solve the latter problem.)
|
| In effect, though, 1Password is both something you have
| (the device with 1P logged in, login requires a Security
| Key that you don't memorize) and something you know (the
| master password) or are (typically biometrics can be used
| to unlock for a period after entering the master password.)
| recursive wrote:
| Don't know about you, but my passwords were already secure
| enough anyway.
| SchemaLoad wrote:
| No. The service you are logging in to does not hold the
| keys so they can't be leaked, passkeys do not get reused
| between services, it's effectively impossible to fall for
| phishing attacks with passkeys, and it's effectively
| impossible to fall for scammers trying to get your keys
| since there isn't any mechanism to directly dump the
| private keys out.
|
| Pretty much all the problems related to passwords are
| solved by passkeys, having them synced between your devices
| does not impact that.
| idle_zealot wrote:
| > Does anyone know the state of the standard wrt this?
|
| Exporting/transporting keys seems to be optional on the part of
| implementors, but my solution has been to use Bitwarden, so I
| at least get cross platform keys.
| normalaccess wrote:
| I use Bitwarden to store my passkeys. Syncs to all my devices
| and just works. I have very few issues with it. Also for the
| truly paranoid, you can run the open-source back end on your
| own server if you want.
|
| https://bitwarden.com/passwordless-passkeys/
| joelthelion wrote:
| Are passkeys seeing any traction?
| nixpulvis wrote:
| I don't use them much because I don't have a good way to
| register them and use them across device ecosystems. I use all
| three OSes regularly.
| WorldMaker wrote:
| 1Password and BitWarden both support Passkey sync across all
| three OSes. Though if you are using Android regularly enough
| that may imply you trust Google implicitly enough that you
| probably could also just get away with Chrome Passkey sync
| which I'm told also works on all three OSes today.
|
| _Or_ treat it as an opportunity to try to avoid "vendor
| lock-in"/increase redundancy by _using_ all three to have 3+
| passkeys in every service. Windows 11 can act as useful a
| bridge for bootstrapping all of your keys into a service:
| register for a site first on iOS or Android, use Windows 11
| bluetooth to login via the first passkey, add a Windows
| passkey, and use Windows 11 bluetooth again to add the third.
| (Or some combo of that with the Windows iCloud Passwords app
| and /or Chrome.)
| nixpulvis wrote:
| I guess I'm partially just stubborn because I don't want to
| pay for what should be a cross platform standard.
| coldpie wrote:
| KeepassXC is a good client that lets you handle your data
| how you want. I wrote a pro-Passkey blog post here[1]
| that explains how to do your own syncing, though I later
| discovered Passkeys are explicitly built to support
| proprietary software vendor lock in and had to revoke my
| support. If you are concerned about being able to control
| your own data outside of the big tech ecosystem, I
| strongly recommend avoiding passkeys entirely. It is
| possible for now, but they are not built for that and the
| spec authors are actively hostile to you managing your
| own data.
|
| [1] https://www.smokingonabike.com/2025/01/04/passkey-
| marketing-...
| WorldMaker wrote:
| I also meant to mention that many Keepass clients support
| Passkeys already today. Strongbox on iOS and macOS has
| similar or better integration to 1Password/BitWarden.
| Windows you probably want KeepassXC for now as it isn't
| fully baked in mainline Keepass. I don't know what you'd
| use on Android today, but I'm sure there's at least one
| and probably more on the way.
| lxgr wrote:
| Bitwarden is free, and if you are concerned about these
| terms changing, the excellent self-hosted open source
| server implementation "vaultwarden" [1] supports passkeys
| as well.
|
| [1] https://github.com/dani-garcia/vaultwarden
| throwaway314155 wrote:
| Yep
| andrewmcwatters wrote:
| Passwords and password managers seem good enough to me, and TOTP
| support is everywhere now.
|
| Passkeys just feel like a standard written by large tech
| companies as a flywheel technology to keep me locked into
| whatever hardware and software ecosystem I'm already in since
| seemingly no one besides maybe Bitwarden supports exporting them.
| Which seems pointless, because I don't know of any platform that
| supports importing them.
|
| I am also getting tired of corporate white knight nerds defending
| trillion dollar companies telling me that portability isn't a
| concern.
| advisedwang wrote:
| Password/TOTP does not protect you against phishing. The
| phishing site can forward the password and TOTP you type into
| the real system, gaining your access.
|
| FIDO/WebAuthn/Passkeys protect you against phishing, because of
| the origin binding mentioned in the article. On the phishing
| site, the required credential cannot be generated, and so no
| matter how convincing it is you can't accidentally give them a
| credential to forward.
|
| Phishing is what these systems were trying to defend against.
|
| Now if you were to say that the move from plain FIDO tied to a
| hardware key to passkeys tied to a Google account was a lock-in
| ploy ---- then I might be more inclined to agree.
| jgalt212 wrote:
| > The phishing site can forward the password and TOTP you
| type into the real system, gaining your access.
|
| To me this seems harder to pull off than a fraudulent
| password reset (either via social engineering, or a hacked
| email account). My TOTP fell in the drink a few years back,
| and some accounts very hard to reset and others were too
| easy.
| jerf wrote:
| If you're targeting a particular person, social engineering
| is probably easier. If you just want to illicitly harvest
| _some_ accounts, and aren 't too worried about which ones,
| blasting out emails linking to hacked websites that fake
| the login & TOTP flow is very easy.
| andrewmcwatters wrote:
| Considering there's an entire portion of the software
| industry built on accepting a user's credentials and also
| prompting them for their TOTP, I don't think this really
| matters.
|
| It's not an acceptable trade-off. And the answer isn't,
| "Those third-parties shouldn't be asking for your password
| and TOTP," because that's not a realistic premise.
| pottertheotter wrote:
| A couple years ago there were several posts here about not
| using PassKeys, and I went along with that for a bit. But I've
| fallen in love with them. They're so nice to use with
| 1Password.
|
| I suppose I might want to stop using 1Password someday, but it
| still has all my passwords as well so I can just fallback to
| those. And, honestly, only a fraction of the sites I have in
| 1Password have PassKeys available.
|
| What I hate much more is sites that don't have passwords and
| require you to log in via email every time. It drives me NUTS.
| andrewmcwatters wrote:
| I get the security behind email-only sign in, but waiting on
| mail servers is so slow!
| eddyg wrote:
| Passkeys are fantastic! I encourage my family and friends to
| utilize them as an alternative to passwords whenever
| possible.
|
| Compared to everything else, they are _so_ much of a nicer
| experience. I despise the "click the link we just emailed
| you" _so much_. And MFA is a pain, and still has security
| issues: https://blog.talosintelligence.com/state-of-the-art-
| phishing...
|
| I really don't get all the hate for Passkeys on HN...
| recursive wrote:
| > I really don't get all the hate for Passkeys on HN...
|
| It feels like the first step in a vendor lock-in strategy.
| Basically boils down to that. That's essentially my issue
| anyway.
| skybrian wrote:
| Passkeys are an API that requires the use of a password
| manager. It doesn't lock you into any hardware any more than
| your password manager does already.
|
| You can't copy a passkey to a different password manager, but
| you can create a new one for the same account, which is usually
| just as good.
| solarkraft wrote:
| Challenge-response with asymmetric encryption is pretty much
| perfect. I wish all auth worked like SSH.
|
| Passkeys kind of take that concept, but make it suck. No backups.
| Terrible interoperability.
|
| The other day I attempted to create one on my Mac with Firefox.
| The system passkey popup came up and made me scan a QR code with
| my iPhone that had to be connected to the internet. Bitwarden (my
| iOS passkey manager, that part works well) did open, but after
| selecting the profile to create the passkey in, it errored out.
| No passkey for me.
| zie wrote:
| I implemented passkeys @ $WORK, and we rolled it out to our
| tech department only first. Nobody could make it work reliably,
| and troubleshooting it was basically impossible. The best you
| could do was just wipe their passkeys and have them try again.
|
| I've since disabled passkey support and we have no plans to
| attempt a new rollout anytime soon.
|
| As far as I can tell the only people that have "successfully"
| rolled out passkeys are the companies with effectively zero
| user support and they just refuse to support passkeys at all,
| so if they don't work for a particular user: whatever.
|
| TOTP is fully rolled out and well supported. Troubleshooting it
| is "hard", but at least it's possible.
|
| TOTP troubleshooting basically boils down to 3 things:
|
| * Server time
|
| * User Phone/device time(most users opt to use their phone to
| generate TOTP, but we don't care)
|
| * More than one TOTP saved for a given site(i.e. they didn't
| replace the old and created a new TOTP shared key) or not saved
| at all.
|
| Our tech/user support helpdesk can handle this but it took a
| lot of training. We built special tools. We still get requests
| from them when they get overwhelmed with the complexity.
|
| Passkey troubleshooting:
|
| * Mobile network, including bluetooth
|
| * Server network connectivity
|
| * Computer/device network, including BT connectivity to mobile
| device.
|
| Most tech support can't handle that much complexity at once.
| Shoot, most developers and tech "whiz" people can't either. The
| error messages one does get, if they are lucky, are very
| general and not helpful at all(last I checked).
|
| Passkeys are not currently fit for production where you have to
| support the users. I hope they get there.
|
| 1Password is the only client/device implementation of Passkeys
| that pretty much just works. It saves the passkey in the 1p
| vault, and the 1p vault can be synced across devices.
| Spooky23 wrote:
| The problem with TOTP is that it isn't a second factor. It's
| like Kerberos for the web. Passkeys are similar, only allow
| hardware devices with PIN.
| LelouBil wrote:
| How is it not a second factor ?
|
| It's something else that is unrelated to your password that
| you have to provide in order to log in, is that not the
| definition of a factor of authentication ?
|
| Because it's phishable ?
| jerf wrote:
| Passwords are "something you know". TOTP is "something
| you know". It wanted to be "something you have", but it's
| not. Proof: I can put TOTP tokens into my password
| manager now. Anything that can go into my password
| manager is proved to be "something I know" by the fact I
| can put it into my password manager.
|
| Incidentally, passkeys go into my password manager too.
| You can probably work the math from there.
|
| (I'm heterodox on this matter, though. I don't believe in
| the existence of "things you are" and "things you have".
| I think it's all ultimately just "things you know" and
| it's all better analyzed in terms of the cost of knowing
| and proving knowledge, and that the 3-factor framework
| for authentication is wrong.)
| Spooky23 wrote:
| It's a second password - not a bad thing, but still
| vulnerable to many categories as attacks.
| ziml77 wrote:
| I haven't had any problems with syncing and using passkeys with
| 1Password and Firefox on MacOS, iOS, or Windows. When the site
| wants to create or use a passkey I get a prompt from 1Password
| on the device that I'm using. No need to involve a second
| device (which for me I'm fine with security-wise. If I really
| wanted to be sure there was no way of malware extracting the
| keys I would be using my Yubikeys)
| tzs wrote:
| What kind of Mac and what version of MacOS?
|
| I remember those QR codes and needing to use my phone when I
| tried passkeys a couple years ago when I was on an older Mac
| that didn't have hardware support for biometrics.
|
| Every since I got a Mac with that support passkey creation has
| worked fine entirely on the Mac.
| whartung wrote:
| So how well do passkeys work when you don't sync passwords. When
| you bounce from machine to machine. From OS to OS.
|
| How well does password recovery work in those scenarios?
| hanikesn wrote:
| It works great with physical keys. Just need one as backup you
| leave at home.
| lxgr wrote:
| And you need to register for every new service you create an
| account with.
|
| It's also not a good idea to store the backup at home - house
| fires are unfortunately a thing, and chances are you might
| not have time to grab either your main or your backup key.
| AnotherGoodName wrote:
| This is a really common question but it has a really simple
| answer. They still have recovery methods. You can optionally
| change these with most providers (go into account settings,
| setup something like a recovery codes and check the option to
| be completely passwordless) but regardless they still have
| recovery methods. As in i lost my phone and i recovered the
| account with a combination of my secondary email and old
| password.
|
| You might argue "but if they still have the recovery methods
| isn't my account only as secure as those" and to that i'd point
| out that you're still way ahead with passkeys simply by not
| entering passwords on a routine basis. The recovery methods
| tend to be two factor as well, just without passkeys as one of
| the two factors (hence email+password) so still a win over
| password alone in any case.
|
| Passkeys should be thought of as no different to the old two
| factor authenticators. I mean that's literally what they are,
| essentially the latest fido standard that allows devices such
| as your phone to be a hardware security key in its own right.
| These always had ways to do account recovery with all the
| providers.
| nixpulvis wrote:
| Should allow multiple passkeys. So you have one per device.
| recursive wrote:
| That introduces new friction to setting up a new device,
| which is worse than the case with passwords.
| petedoyle wrote:
| Somewhat off-topic: Does anyone know the underlying strength of
| the keys used as the "root of trust" behind passkey
| synchronization on Android/iOS? I can't find a lot of
| documentation on this.
|
| It seems like they're synced between devices using client-side
| encryption, with keys derived from your phone's lock code
| (typically only 4-6 digits). Is it possible that the passkeys are
| fully random, but then encrypted with far less than 128/256 bits
| of actual entropy while being synchronized between devices?
|
| Could it be possible to brute force the keys server-side (IIUC,
| derived from 4-6 digit pins) with non-excessive amounts of
| compute? What am I missing?
| some_furry wrote:
| Typically you see symmetric encryption keys (AES-256 is the
| most common), derived from a Password KDF. I don't know what
| Google or Apple do specifically, but that'd be my first guess.
| NicolaiS wrote:
| A confidential channel can be established over an insecure
| medium using e.g. Diffie-Hellman key exchange. To protect
| against MITM, an out-of-band QR/bluetooth can be used.
| throw7 wrote:
| Is there a "platform authenticator" that allows import/export of
| the actual origin site, keypair, and credential id in plaintext?
| The next would be a variety of platform authenticators able to
| import and use those?
|
| I don't want vendor lockin and I don't want proprietary third
| party cloud based backup/recovery.
|
| Today with totp, I store the plaintext otpauth url and I can use
| oathtool to spit out codes when needed on my desktop. My phone
| has aegis, but I don't use any cloud based backup/recovery. I
| switched from Google Authenticator after they implemented their
| cloud based syncing to google.
| coldpie wrote:
| KeepassXC allows this, but the spec authors think this is bad
| and have threatened KeepassXC with being banned by
| authenticating websites. The spec has explicit support for
| banning clients built in.
| https://github.com/keepassxreboot/keepassxc/issues/10407
| nemoniac wrote:
| Why does a browser have to be in the loop?
| vaylian wrote:
| Because the browser knows the internet domain that the
| login/registration is for. And the browser also provides the
| JavaScript API to talk to the authenticator
| (navigator.credentials.create and navigator.credentials.get).
| lxgr wrote:
| > Generally, authenticators are "something you have."
|
| Shameless plug: Here's one that is "something you know" :)
| https://github.com/lxgr/brainchain
|
| It derives all keypairs from a passphrase, and rederives the
| private key from the key handle, similar to "stateless" hardware
| authenticators.
|
| Please don't use it for anything important - it's a fundamentally
| bad idea, similar to "brain wallets"; I only implemented it to
| figure out whether it was possible, and to improve my own
| understanding of the WebAuthN and FIDO specifications.
___________________________________________________________________
(page generated 2025-05-14 23:00 UTC)