[HN Gopher] FIDO Alliance publishes new spec to let users move p...
___________________________________________________________________
FIDO Alliance publishes new spec to let users move passkeys across
providers
Author : Terretta
Score : 143 points
Date : 2024-10-15 12:18 UTC (1 days ago)
(HTM) web link (fidoalliance.org)
(TXT) w3m dump (fidoalliance.org)
| troupo wrote:
| I came across an opinion I largely agree with:
| https://mastodon.social/@lapcatsoftware/113308133338196824 and
| https://mastodon.social/@lapcatsoftware/113308273654667583
|
| > These big tech companies will do anything possible to prevent
| users from ever actually being able to access their own passkeys.
|
| > Export and import should have been extremely simple. Instead,
| they took years to come up with some convoluted system where the
| only possibility is to transfer from one vendor lock-in to
| another vendor lock-in.
|
| > With passkeys, the big tech companies are executing a coup
| d'etat of authentication, just like they did for HTML itself.
|
| > In the end, they control every protocol, become the gatekeepers
| for the web.
| NikolaNovak wrote:
| So it's not just me!
|
| I feel like I either misunderstand pass keys or live in some
| twilight zone where they're ok even though I cannot wrote them
| down or memorize them, I can only have invisible magic stuck on
| my phone.
|
| If I show up naked, I can login to the system via password but
| I am conpletely useless with a pass key. And for somebody like
| myself who uses multiple devices daily (two phones, two
| tablets, several laptops and desktops), it seems a nightmare to
| set them all up or maintain:-(
|
| It feels a system designed for those who live by their phone
| and trust some specific service provider with their life. I'm
| not in either of those categories :-(. I still don't understand
| what the "Keepass, "little black notebook", and "good memory"
| equivalents are.
| portaouflop wrote:
| Idk I just set up both - email&password which live in my
| password manager and then passkeys for convenience - I can
| just hit a button without thinking and I'm in.
|
| It's probably different for everyone but in case I have
| strictly separate devices- so a laptop where I have my work
| accounts and a desktop for games and some personal stuff.
|
| I don't really use anything on a regular basis that needs
| accounts on my personal devices, but that's probably very
| weird nowadays...
| sph wrote:
| I already hit a button (the Bitwarden icon in my browser
| toolbar) so I do not see what passkeys buy me, except a
| terrible hassle the day I want to change password manager.
|
| It is a solution designed to lock people in the
| Apple/Google walled gardens, and I don't see why everybody
| is pushing for it.
| izacus wrote:
| Passkeys work fine with password managers like 1Password,
| KeePassXC, Bitwarden and others, why do you keep
| repeating this walled garden shtick?
|
| They're literally a cryptostring stored in your password
| manager just like your other passwords.
| troupo wrote:
| > They're literally a cryptostring stored in your
| password manager just like your other passwords.
|
| So I can copy paste them somewhere or move them around
| without "Credential Exchange Protocol (CXP) and
| Credential Exchange Format (CXF)"?
| rcxdude wrote:
| With Keepass you can, at least. Other ones not so much.
| izacus wrote:
| You can copy paste them using those formats. What are you
| arguing about here actually?
| FireBeyond wrote:
| How does one get a passkey from iCloud into one of these
| formats?
|
| "You can't take your passkeys from Apple Passwords"
|
| s/iCloud/1Password?
|
| "There's not a way to import/export passkeys"
|
| s/iCloud/Google?
|
| So "you can copy paste them using those formats, if you
| can get them into those formats in the first place".
| wolletd wrote:
| KeepassXC actually supports passkeys and can be a passkey
| provider in a desktop browser.
|
| And Android 14 seems to allow changing the passkey provider
| in the android system as well. With that, the only thing left
| would be a KeepassXC-compatible app that can serve as
| provider on android, using the same database as the desktop.
|
| With that setup, I'd be willing to use passkeys exclusively
| (my phone is still Android 13 and I don't know about app
| support). I already can't login anywhere (important) without
| access to my password manager.
| Dagonfly wrote:
| Can confirm: Using Android 14 and Bitwarden, I can sign in
| to github.com using my passkey. It pops up a system dialog
| where I can select Bitwarden and then my Github username.
|
| Last time I checked, the Bitwarden Vault export included
| the whole FIDO credential including the private key.
| wolletd wrote:
| Bitwarden (and Lastpass, iirc) support passkeys a little
| longer than KeePassXC. I'm glad to hear they achieved
| full integration.
|
| As a keepass database is used by various open source
| clients from different vendors, it just takes a little
| longer to get all this done. But I'm sure we'll get there
| eventually.
| barkerja wrote:
| > Android 14 seems to allow changing the passkey provider
| in the android system as well
|
| It's worth noting this is also supported in iOS and macOS.
|
| Settings > General > AutoFill & Passwords
| izacus wrote:
| > I feel like I either misunderstand pass keys or live in
| some twilight zone where they're ok even though I cannot
| wrote them down or memorize them, I can only have invisible
| magic stuck on my phone.
|
| There seems to be a lot of misunderstanding of passkeys
| indeed. They're in no way different than that random password
| stored in your password manager and can be (with this
| standard you're commenting on) moved around wherever you want
| them.
|
| All passkey sites also support fallbacks to just password or
| other auth mode.
| troupo wrote:
| > They're in no way different than that random password
| stored in your password manager
|
| Except in all the ways that matter: they are not accessible
| to users, they are tied to third-party vendors.
| izacus wrote:
| That's an outright lie now, isn't it?
| mzhaase wrote:
| They are different from passwords in that they are never
| send over the web. They are a private key used to sign a
| challenge from the site.
| dustyventure wrote:
| The private keys are not sent to the relying party yet
| TFA is about a spec to send them over the web.
| NikolaNovak wrote:
| >> All passkey sites also support fallbacks to just
| password or other auth mode.
|
| Is this a guaranteed thing? Are we saying any account I
| create cannot be Created with just a pass key; and that no
| site or service is able to discontinue the password option?
| barkerja wrote:
| No, this is not guaranteed.
| 9dev wrote:
| It is by necessity; at the very minimum, you'll need an
| OTP via email, since you need an out-of-band method of
| identifying the user during the registration.
|
| I actually built a small web application that's entirely
| passwordless, and it works really smoothly. I don't get
| the antipathy towards Passkeys.
| buro9 wrote:
| The second one is particularly pertinent:
|
| > Passkeys are essentially site-specific cryptographic
| keypairs, which are fine, combined with big tech company
| paternalism, which is intolerable.
| ratorx wrote:
| AFAIK, you can register your passkeys using your own provider
| (eg. Bitwarden). I've not personally used it too much, but the
| option is there.
|
| The remaining issue is moving the credentials between
| providers, which is an annoying limitation. But you can always
| add a different passkey to the site using the provider you
| want, so although annoying it is not the end of the world...
|
| The original limitation is similar to the usability of actual
| physical security keys, which (depending on the setup mode) are
| deliberately designed such that the private key material is not
| recoverable. Software based keys don't HAVE to share the same
| limitation, but it seems more like a missing feature than
| attributing malice to the creators of the spec.
| lapcat wrote:
| > AFAIK, you can register your passkeys using your own
| provider (eg. Bitwarden).
|
| Why should we even need a third-party provider? Imagine
| needing a third-party "provider" for your own ssh keys.
| joshuamorton wrote:
| Do you use the same SSH keys on multiple devices? I
| certainly don't. If you need or wanted to (you don't) you'd
| need some way to sync them across multiple devices
| securely.
|
| When I use passkeys on a single device, the "provider" is
| the OS, same as with my SSH keys.
| troupo wrote:
| > Do you use the same SSH keys on multiple devices?
|
| Yes. For example, when upgrading or reinstalling a system
|
| > If you need or wanted to (you don't) you'd need some
| way to sync them across multiple devices securely.
|
| `scp -r`
|
| > the "provider" is the OS, same as with my SSH keys.
|
| And you have full access to ~/.ssh and you can move copy
| update rename delete them however you like. Without a
| "Credential Exchange Protocol (CXP) and Credential
| Exchange Format (CXF)" to move between blackboxes of
| third-party providers
| Terr_ wrote:
| > Do you use the same SSH keys on multiple devices?
|
| Assuming you mean client devices, yes, depending on my
| personal relationship/control of the device. (For
| servers, the answer is "very yes".)
|
| For example, my personal laptop and desktop may have the
| same private key, and I will backup/restore that same key
| onto either of them if they are reinstalled or replaced
| with new hardware.
|
| However my _work_ laptop gets its own, so that I can
| more-easily limit what it can access or cancel it in the
| future.
| craftkiller wrote:
| > Do you use the same SSH keys on multiple devices?
|
| Yes.
|
| > you'd need some way to sync them across multiple
| devices securely.
|
| I take out my physical keychain and plug in my yubikey.
| Then, after typing in the password to my yubikey, I can
| use ssh and pgp until I unplug my yubikey. It is a hell
| of a lot more secure than storing your ssh keys on disk
| regardless of whether or not you use a unique key per
| device. I could lock someone in a room with my computer,
| my yubikey, and my password, and they still wouldn't be
| able to copy my ssh key.
| ycombinatrix wrote:
| pedantic nit: the yubikey is a device so you are arguably
| using one unique key per device
| craftkiller wrote:
| Haha technically true, but I don't think that was the
| kind of device they were referring to. Even so, it is
| possible to use the same key on multiple yubikeys. You
| generate a PGP key on a secure computer and then load
| that key onto multiple yubikeys. Then you use gpg as your
| ssh agent. But this is less secure than using keys
| generated on-device by the yubikey because your private
| key exists (hopefully temporarily) as a file on the
| computer where you generated it.
| joshuamorton wrote:
| No this is absolutely what I meant: A passkey and a PGP
| key function very similarly in this capacity, a passkey
| for a site can be generated on a yubikey and used across
| devices in just the same way.
| 0cf8612b2e1e wrote:
| I certainly backup my SSH keys. That way if my laptop
| dies today, I can be up and running tomorrow without
| anyone else being involved.
|
| How do I ensure I can access my accounts if my phone-
| containing-passkeys is lost/stolen/dies without backups?
| Scion9066 wrote:
| You don't. Same as a physical key for your home, you have
| backups.
|
| Whether that's having multiple separate keys/devices
| registered with your accounts or a single key stored in a
| password manager, you need to have a fallback plan.
| ratorx wrote:
| If you only want first-party, you can presumably implement
| the spec yourself and do whatever you want with the data?
|
| My example was only to point out that there exist self-
| hostable passkey providers.
| lll-o-lll wrote:
| This is an exceptionally cynical take. WebAuthn is an open
| standard; this new credential transfer spec is the opposite of
| "big vendor lock-in". It's standardising the export-import.
|
| Standards are slow and expensive to create and evolve. They
| involve endless meetings, discussion and design. However, the
| outcome is freedom.
|
| The idea that this should have been "extremely simple" is just
| standard hubris.
| lapcat wrote:
| > This is an exceptionally cynical take.
|
| > However, the outcome is freedom.
|
| This is an exceptionally naive take.
|
| > The idea that this should have been "extremely simple" is
| just standard hubris.
|
| Why? Export-import of passwords is extremely simple and can
| be done with copy-paste or CSV. The only thing preventing
| this with passkeys is the paternalistic idea that users of
| passkeys should not be allowed to access them directly.
| joshuamorton wrote:
| > The only thing preventing this with passkeys is the
| paternalistic idea that users of passkeys should not be
| allowed to access them directly.
|
| This is, of course, also the thing that makes passkeys
| uniquely unphishable.
| Terr_ wrote:
| That's a bit like saying a house fire is what makes your
| deleted files uniquely safe from recovery.
|
| The sentence is true, as far as it goes... But it's
| uniquely excessive, rather than the unique minimum
| sufficient for the task.
| lll-o-lll wrote:
| > FIDO Alliance's credential exchange specifications define
| a standard format for transferring all types of credentials
| in a credential manager including passwords, passkeys and
| more in a manner that is secure by default.
|
| The hint of why this may be just _slightly_ complicated is
| in that final phrase.
| troupo wrote:
| > The hint of why this may be just slightly complicated
| is in that final phrase.
|
| The hint is that they are putting the cart in front of
| the horse, have decided on an outcome, and now are busy
| working towards that outcome.
|
| ssh isn't less secure, and yet you can just copy-paste
| the required files on your own, instead of relying on
| convoluted protocols for moving data between black boxes.
|
| It reminds of of their "Data Transfer Initiative" which
| "let's people move their data around easier" but
| underneath it's just "well, some of data between Google
| Apple and some other third party services only":
| https://dtinit.org
| 9dev wrote:
| SSH keys are a _massive_ security liability. A private
| key, readable by any process you execute, without you
| noticing, that acts as a key to the kingdom? Maybe
| protected by a weak passphrase - since you probably have
| to enter that often - an attacker can brute force at
| their own discretion after copying it? A heap of public
| keys belonging to god-knows-which-machine, copied
| manually to every other server?
|
| Designing a system that is secure, scalable, and works
| for billions of people worldwide in a highly adversarial
| environment is _freaking hard_.
| skybrian wrote:
| Unlike your photo collection, passkeys aren't precious. They're
| just meaningless data. You can and should generate additional
| ones for each password manager you use, so you have multiple
| independent ways of getting into an account. As long as you can
| do that, everything is replaceable and there's no lock-in.
|
| Similarly, I wouldn't copy a private key for ssh to a new
| laptop. I generate a new one and copy the public key instead.
| It makes it easier to revoke access to the old computer.
|
| I do think this new spec will sometimes be useful for
| populating a new password manager, though.
| jauntywundrkind wrote:
| The proposal that any time o create an account o need
| multiple physical tokens or multiple password managers
| running is unbelievably stupid & fantastical. This whole
| project is doomed doomed doomed of this is the model.
|
| I've never seen a single sight suggest this either. Many have
| set up passkeys, but not one has prompted me to create a
| second. I have downloaded a lot of backup keys though.
|
| Sorry to be on blast here but every time passkeys come up the
| "use multiple keys" gets said & it's a joke. There needs to
| be a flow where I can create a passkey & have it replicate to
| a bunch of devices automatically; the current proposal that
| users need to gather all their security tokens & add each one
| is an absolute promise this technology is going to flop.
| growse wrote:
| > Sorry to be on blast here but every time passkeys come up
| the "use multiple keys" gets said & it's a joke. There
| needs to be a flow where I can create a passkey & have it
| replicate to a bunch of devices automatically
|
| Choose a passkey provider that supports this then. I use
| bitwarden. Other people use iOS keychain. Both work great.
| skybrian wrote:
| I bring it up because people claim there is lock-in and
| it's not true.
|
| Apple and Google both replicate between devices, so there
| is _some_ replication, within ecosystems. I only need to
| create a passkey twice per account so I can use both. It's
| not a big deal, though replicating between them would be
| better.
|
| And so I am clearly not locked in. (Not because of
| passkeys, anyway.) If people think they're locked in then
| it's a "can't be bothered" sort of lock-in.
|
| Clearly not fantastical since I'm doing it.
| solarkraft wrote:
| I know you're applying the same model as for SSH keys (and
| functionally they _are_ very similar) ... but I also think 1
| SSH key /device is impractical if you have many services to
| log into and many devices to log in from - which is just the
| reality nowadays.
|
| Imagine having to use a specific password for each
| service/device combination. Instead we don't tie passwords to
| devices, but to _users_ , to avoid this complexity.
| skybrian wrote:
| It's certainly not my reality. I have a desktop computer
| and a laptop that I use ssh from. How many computers do you
| have?
| rcxdude wrote:
| It's not particularly impractical for SSH: have a text
| document with the public keys of all your devices, and copy
| it into the authorized keys for any system you want to log
| into. Passkeys don't have an analog for this, though.
| fragmede wrote:
| fwiw https://github.com/<username>.keys is a pretty good
| one for that
| 9dev wrote:
| > Imagine having to use a specific password for each
| service/device combination. Instead we don't tie passwords
| to devices, but to users, to avoid this complexity.
|
| But that is the entire premise of Passkeys--they remove the
| complexity, because having individual passwords per device
| is _clearly superior_ to user-bound passwords, if you don't
| need to worry about it and it just works. Hence why, to
| stay with SSH, you shouldn't use SSH keypairs, but
| certificates signed by a CA.
| rcxdude wrote:
| For this to be practical, there needs to be a way to enroll
| non-present devices. Which is technically feasible, but
| there's no real support for it yet in the standard or in the
| available implementations. (e.g. with SSH you can have a list
| of the public keys of all your devices). That would make e.g.
| passkeys on a HSM more feasible, since you could enroll your
| backup in a safe whenever you create an account with your
| daily driver one.
|
| (The added bonus security feature being you could revoke your
| daily driver if you lose it, while retaining access to your
| backup. But again there's no actual support for this kind of
| thing)
| creatonez wrote:
| > Instead, they took years to come up with some convoluted
| system where the only possibility is to transfer from one
| vendor lock-in to another vendor lock-in.
|
| Can someone explain how this actually works? Are the two
| backends required to send messages to each other to facilitate
| a transfer, or is it a simple encrypted export and import? Will
| it only facilitate transfers to trusted destinations?
| jandrese wrote:
| Personally, I've never met a cloud provider I would trust with
| holding my secret tokens. It just seems like such a juicy
| target for hackers. You have to trust that they have done
| everything right all of the time.
| rkagerer wrote:
| Does this include a way for a technically-savvy user to
| 'repatriate' their passkeys into their own infrastructure? (i.e.
| If I want to be my own provider)
| commandersaki wrote:
| At a minimum we will see if KeePass is a provider that is
| supported; they seem to be the only pw manager in town that
| respect user freedom.
| lovethevoid wrote:
| KeepassXC already supports passkeys
| ratorx wrote:
| Can you not just set up a new passkey using a different
| provider (eg. Bitwarden)? It is a bit inconvenient, since it
| has to be done manually for every site.
| whatevaa wrote:
| A bit is understatement. If this passkeys become widespread,
| we are talking about like 100 sites.
| ensignavenger wrote:
| I have over 500 logins in my Bitwarden account right now.
| Many of those are not important in the least, but hundreds
| of them are.
| Jnr wrote:
| If you go for passkeys, start putting them in your own
| provider from the start? Vaultwarden is a nice option.
| HeatrayEnjoyer wrote:
| There shouldn't be. Secure enclaves aren't secure if they can
| be copied
| lucianbr wrote:
| How does this suddenly become a problem when as the user I
| want access to _my_ keys, but it isn 't a problem when
| corporations copy my keys between them, which is what this
| post is about?
| jasonjayr wrote:
| Secured against who?
| eikenberry wrote:
| So you are against this new spec becoming a standard then?
| benlivengood wrote:
| The exchange spec suggests that the sending secure enclave
| sends encrypted credentials to the receiving secure enclave;
| they're never unwrapped in public between 'trusting'
| enclaves; which enclaves will trust each other enough to
| perform the credential transfer is another question.
| Terr_ wrote:
| I would also be concerned about whether you can recover when a
| provider becomes unusable or hostile, and there is no
| cooperative migration path.
|
| That might be the company going bankrupt, a physical or digital
| disaster, geopolitical firewalls, or simply a Kafka-esque
| bureaucracy where your entire account has been deleted without
| appeal because the company decided it was easier than figuring
| out the truth behind some moderation issue.
| EasyMark wrote:
| That seems scary, I think I'd rather move them over one by one
| and delete the old passkey/2fa. I want to make it as hard as
| possible to keep them from being moveable as that's one less
| attack point for hackers.
| anilakar wrote:
| OK. Let me know when I can migrate FIDO credentials from old
| Yubikeys to new ones.
|
| Earlier this year I almost lost a domain because $REGISTRAR
| forced 2FA and I had forgotten to add them to my key spreadsheet.
| ithkuil wrote:
| I think the whole point of yubikeys is to make this impossible.
|
| IIUC basically these devices contain one single immutable
| random secret that is stored in a tamper proof hardware and can
| never leave the device nor be written into another device.
|
| When you "create" new keys what actually happens under the hood
| is that a new value gets stored in flash memory which is the
| _combined_ with the hard secret with some key derivation scheme
| and the resulting secret is then the one used to perform
| cryptographic operations
| pushupentry1219 wrote:
| Yeah whole point of YubiKey is that the physical key is
| REQUIRED and can't be cloned. So no, you won't be able export
| anything off of it.
|
| You're correct about how key creation works as well AFAIK.
| abdullahkhalids wrote:
| Yes, but nothing prevents someone from making a hardware
| security token that has a copyable memory. Some people will
| have a threat model where this is acceptable.
| ithkuil wrote:
| you can technically do that but that would be a very
| confusing use of the name "hardware security token".
|
| You can already use your phone today to store secrets with
| an acceptable threat model.
| redserk wrote:
| This is yet another security measure that completely
| ignores the real world and will become yet another
| security measure that gets ignored.
|
| People lose credentials all the time, from social
| security cards, to drivers licenses, and passports. Say a
| natural disaster hits and your laptop with Yubikey gets
| swept away in a flood? Congratulations, you're hosed!
|
| Individual people do not have the resources that a
| financial institution has. Getting people to adopt unique
| passwords is already an incredible hurdle, getting people
| to treat a hardware token _literally_ more carefully than
| their social security card is bizarrely out of touch with
| reality.
|
| As for me, I use Keepass to store my Passkeys. I use a
| password and Yubikey to secure it. The Yubikey has the
| same exact private keys set as 2 others, so I can keep 1
| on my keychain, 1 in my safe, and 1 at a relative's
| house. And even this would be an unreasonable effort to
| expect from the majority of people.
| eikenberry wrote:
| > I think the whole point of yubikeys is to make this
| impossible.
|
| It is and it is why Yubikeys are useless for most cases
| outside of the workplace.
| akira2501 wrote:
| The recommendation is to use two keys or to always have an
| additional backup method configured. So you should never be in
| a position where a migration is required.
| Animats wrote:
| Yes. My other Yubikey is in a bank vault.
|
| I do not want a remote "authentication provider".
| anilakar wrote:
| Hardware tokens are physical objects that are subject to
| mechanical wear and tear and can be lost. Hardware tokens are
| also subject to ending up on a hardware attestation blacklist
| because of security weaknesses.
|
| I have already had to replace two Yubikeys for the
| aforementioned reasons, so FIDO hardware token migration is a
| very real scenario that desperately needs to be addressed.
|
| Also mind that there are too many services that allow you to
| only use one FIDO token, or even worse, only one primary 2FA
| method in addition to backup codes.
| growse wrote:
| If you want a Webauthn credential that you can "copy", don't
| use a Yubikey. Use something like KeepassXC, BitWarden etc.
| instead.
| itohihiyt wrote:
| I only need one provider. A portable open source encrypted
| database I'm in control of and can back up and secure as needed.
| It's what I have now, and have had for years, in my password
| manager. I won't be at the mercy of a company or a device to
| access my digital life.
| leokennis wrote:
| That's cool, but the last thing I would want my mom to have to
| manage is a portable open source encrypted database shes's in
| control of and can back up and secure as needed.
| saurik wrote:
| Great; but, as long as a system supports the open solution,
| anyone can provide for you the closed one, while the opposite
| isn't the case.
| izacus wrote:
| And Passkeys is an open solution, what are you all going on
| about?
| politelemon wrote:
| Currently it is not. It was created provider centric so
| far, and in my reading of the spec, a thinly veiled
| lockin. The ability to move around should have been built
| in from the beginning but it was more beneficial for the
| providers to start without.
| wolletd wrote:
| Historically, the spec was written for hardware security
| tokens. Keys on those tokens can't be moved around by
| design.
|
| The whole "platform authenticator" thing enabling
| passkeys came later. Extending the spec that way was
| easy: a platform authenticator works just like a hardware
| authenticator, it just uses a different channel for
| communication.
|
| The spec the providers built upon just wasn't designed
| for software authenticators that allow moving around
| credentials. The original spec assumed credentials are
| stored in a non-extractable manner in HSMs.
|
| Edit: thinking about it, platform authenticators may have
| been in there pretty early, but under the assumption of
| also using an HSM and not allowing extraction of
| credentials. Providers compromised security for
| usability, removed the HSM and made passkeys
| synchronizable - the spec had to adapt.
| growse wrote:
| Passkeys are just resident webauthn tokens with a fancy
| name.
|
| Where's the lockin?
| reginald78 wrote:
| The attestation anti-feature which is part of the spec.
| And the portability feature which is conspicuously not.
| The former makes the enforcement of the later possible.
| growse wrote:
| The attestation is part of the webauthn spec, and it's up
| to the relying party to decide whether or not to use it.
| The whole reason it's there is to give some contexts the
| ability to narrow their users down to specific webauthn
| storage implementations (which is useful in some
| corporate / gov contexts).
|
| Are there any examples of any widely-used sites that are
| enforcing attestation?
| whs wrote:
| Two comes to mind:
|
| - Cloudflare had a "captcha" POC called "Cryptographic
| Attestation of Personhood" where you need to use a FIDO-
| approved token. It's reusing U2F just for the attestation
| part only. I don't think it ever go to production as most
| people don't have a token (but perhaps in the future
| hardware-locked passkey may serve as one...)
|
| - Okta do have an option to enforce attestation. By
| default it is off, but in my Okta production I can limit
| the list to FIDO-approved vendor only, or to even a
| subset of them. They also have a beta feature flag for
| blocking Passkeys but allowing physical keys (which they
| do not guarantee success)
| warkdarrior wrote:
| OK, so you gave two examples of systems that do NOT
| enforce attestation (one that is not in production, one
| that has an option to enforce attestation but is not
| apparently in use).
|
| Are there any widely-used sites that actually enforce
| attestation?
| ndriscoll wrote:
| People already do have issues with e.g. banking apps on
| mobile devices requiring OS attestation, so we can expect
| that once they know they can do the same for the most of
| their web clients (so probably once most people have
| moved onto Windows 11 which requires a TPM), they will.
| 9dev wrote:
| It's absurd, really. Attestation is clearly a feature
| intended for high security environments, where you want
| to ensure all employees use their corporate hardware
| authenticators and those only, yet people act like it's
| big techs secret, evil mind control back door.
| hooverd wrote:
| Given the chance, why wouldn't companies abuse that
| feature like every single anti-user feature in the
| history of them? Surely this time it will be different?
| 9dev wrote:
| Because it's highly annoying to set up in a way that
| doesn't massively inflate your support cost.
| jeltz wrote:
| This has not stopped banks in the past.
| ndriscoll wrote:
| If it's only meant to be used for those environments,
| then attestation data should not be provided by default.
| IT can enable it on managed devices.
| growse wrote:
| It's up to the provider as to whether they provide or
| not. I don't think there's a "default"?
|
| I seem to remember that apple specifically don't provide
| attestation details on their implementation.
| jeltz wrote:
| What is absurd about expecting companies to do what many
| internet banks in some countries already do?
| tadfisher wrote:
| There are FIDO Alliance folks posting Github issues
| requesting to remove features such as plaintext exporting
| of credentials, with the explicit threat that the
| Alliance might block such "open" passkey providers in the
| future. A local database is not enough, it needs to be
| locked in a secure element or protected with some TPM-
| like scheme.
|
| The spec allows for hardware attestation as well, to
| ensure passkeys are being provided from blessed computing
| environments. Hopefully implementers continue to ignore
| this anti-feature, because it's entirely stupid to lock
| out users who want to control their own security; at the
| same time, letting anyone with an Android phone restore
| passkeys from the cloud with one of their device PINs.
| arianvanp wrote:
| The original thread:
|
| https://github.com/keepassxreboot/keepassxc/issues/10407#
| iss...
| reginald78 wrote:
| Pretty telling thread. Tim Cappalli, one of the spec
| writers drops by to criticize the export feature and
| suggests that the attestation feature should be used to
| punish them for not implementing the fully locked in
| version.
|
| The credential exchange changes nothing IMO, the rod to
| punish anyone who doesn't want their credentials stored
| on a tech giants servers is still there.
| jacoblambda wrote:
| That's not what happened. He said quote "which would
| allow RPs to block you, and something that I have
| previously rallied against".
|
| This is something that has been proposed that Tim fought
| against but mentioned in the thread to provide context of
| the types of kneejerk reactions the spec authors have had
| to push back against.
| tadfisher wrote:
| Let's be truthful and show the remainder of that
| parenthetical:
|
| > (which would allow RPs to block you, and something that
| I have previously rallied against but rethinking as of
| late because of these situations)
|
| I read "these situations" to mean "non-spec-compliant
| providers", where "spec-compliant" means to prevent
| plaintext export of resident keys.
| bloopernova wrote:
| I halfway expect a v2 specification where keys are only
| stored on a few "Certified Attestation-capable" providers
| (i.e. facebook, google, apple, amazon)
|
| Then watch them get hacked through a systems management
| plugin like Clownstrike, or Solarwinds.
| itohihiyt wrote:
| My mum has a password notebook which is locked away in a
| drawer in her house, she knows to use either passphrases or
| random string that her browser generates for her. For her
| threat model this is better than any software thing.
|
| Certainly a password manager like keepass would be no more
| complicated than trying to explain to her that she can no
| longer access her account because she broken her phone.
| hooverd wrote:
| Ok, but why should that stop me?
| solarkraft wrote:
| I had hope for passkeys, with all the interop-promises.
|
| It turned out that no (mainstream) passkey provider allows
| backups however, making them infinitely worse than just using
| passwords.
|
| Maybe this will help, but fuck me, it's all complicated,
| especially for a damn _foundational security mechanism_!
|
| It could be so simple, just look at SSH keys, which I think
| largely use the same principle.
| skybrian wrote:
| You can create backup keys by creating more passkeys.
| lelandbatey wrote:
| That's not a backup, that's just _another secret_. If I can
| 't record the secret onto paper that I can put in a safe
| deposit box at a bank (or several), then it ain't backed up.
| dixie_land wrote:
| I understand the semantic difference but wouldn't you be
| able to say add a "backup" Yubikey and lock it in a safe?
| tjoff wrote:
| Quite convenient when you need to create a new account...
| eikenberry wrote:
| No. How do you use it if it's in a safe? The only way
| this works is if you use the yubikey to log into google
| or some other auth provider and then use that auth
| provider for everything. But you are even worse off then
| as that auth provider now is a single point of failure...
| get that account revoked for any reason and you've lost
| access everywhere.
| skybrian wrote:
| It's an equivalent key. It unlocks the same door. It
| doesn't matter if it's the same bits, because the only
| thing we care about is whether it unlocks the door.
|
| Two different combinations for the same lock serve as
| backups for each other for practical purposes.
|
| They could even be entirely different methods of access,
| like a Yubikey or backup codes. What matters is that you
| have independent ways to get in.
| Shank wrote:
| > mainstream
|
| The qualifier "mainstream" is quite silly here. Bitwarden and
| KeePassXC work great, can be backed up, and meet your needs.
| Why must "mainstream" providers support power user features?
|
| In-practice, 1Password, iCloud Keychain, etc _are_ backed up
| because they work across devices and those systems already have
| recovery mechanisms in place if you lose your devices. They're
| synchronized credentials available everywhere.
|
| The only way to make a problem is to "store a passkey locally".
| Then you're out of luck. If you just use Bitwarden or
| KeePassXC, this is a non-issue.
|
| > It could be so simple, just look at SSH keys, which I think
| largely use the same principle.
|
| Passkeys are technically complex in implementation because
| they're trying to be better than passwords for the lowest
| common denominator of users. If you spend time looking at how
| they work and interact with sites, the solution is relatively
| simple and easily understood. Maybe they're just unfamiliar to
| you? I personally have never explained to a layperson how SSH
| keys work without first explaining PKI, which is a pretty big
| ask for my mom.
| andrewaylett wrote:
| As a counter-point, my SSH keys are bound to my laptop's secure
| enclave and it's not possible for me to back them up.
|
| I have recovery mechanisms for regaining access if I lose all
| my keys, but (while I'll admit that the tooling for managing
| public keys in the general case is lacking) you're not
| _supposed_ to (need to) copy private keys between devices.
| arccy wrote:
| if you can get a backup, someone can get scammed into providing
| that to an attacker, taking away any security benefit.
| MarkMarine wrote:
| In one of the things that I do in my job, I run the auth system
| for a fintech, and passkeys are an incredible step forward for
| the typical user. Being able to migrate your passkeys between
| providers is a great step forward, I'm glad this is being
| implemented.
|
| Lots of complaints about passkeys and "big tech paternalism" in
| the comments here, and frankly I don't think ya'll deal with the
| middle of the bell curve user base that much.
|
| I've got users who, by literally no fault of their own, are being
| social engineered into reading back their SMS OTP codes to fake
| tech support. State of the art in industry is basically trying to
| understand every action that is happening on a device (via mobile
| phone network providers, location, their actions across multiple
| other sites, etc. etc. through vendors providing this type of
| intelligence... by vacuuming up all your data) to understand if
| fraud is happening by seeing if you can even trust the device
| that is getting the SMS. Every time we make a step forward in
| privacy, this gets harder and harder (fingerprinting devices is
| basically pointless now, so how do I tell if this should be a
| trusted device or not) so there is a driving force against
| improving user privacy coming from these vendors.
|
| Passkeys are the first positive step in auth I've seen in a
| decade that the average user will pickup and use, it helps them
| login and helps them not try to set a weak password they shared
| with multiple sites, and they can't read it back to a scammer who
| is fake tech support.
|
| Would I like passkeys to be more like ssh keys? um, maybe but I
| don't care about it one bit in practice. I use passkeys for
| everything I can and I've never once seen friction. The average
| user does not want to deal with backing up their passkeys or even
| thinking about them, heck most of them don't. If anyone in the
| comments doesn't like the implementation of webauthn, suggest
| changes to the spec and do the work to get it implemented instead
| of complaining about it in the comments.
| ndriscoll wrote:
| > If anyone in the comments doesn't like the implementation of
| webauthn, suggest changes to the spec
|
| Simple: clients meant for consumers SHALL NOT provide any
| attestation information. Those fields are intended to be used
| only by managed devices.
|
| People can be free to use a device that has guard rails for
| them. The issue is when e.g. my bank forces me to prove I am
| using a malware device, which is pretty much everything from
| "big tech". Normies will stay on the normal path anyway and
| will be using one of those devices, so there shouldn't be a
| need to block the people who are using something weird, because
| by definition they are not the average user.
| Groxx wrote:
| [delayed]
| crote wrote:
| > If anyone in the comments doesn't like the implementation of
| webauthn, suggest changes to the spec
|
| Rip out resident keys altogether. They aren't needed. You can
| get 99.9% of the benefits of Passkeys by using non-resident
| keys - _literally_ the only drawback is that you 'd need to
| enter a username.
|
| Resident keys essentially kill physical tokens. Without
| resident keys a $10 token can support _thousands_ of websites.
| With resident keys? A couple dozen, if you 're lucky.
| taeric wrote:
| I'm super curious how this will ultimately work. As noted in
| another thread, secure enclaves aren't secure if they can be
| copied. Such that, if this is moving the passkey by copying it,
| I'm not at all clear on how that stays secure?
| Scion9066 wrote:
| Generally this spec is talking about the kind of passkeys that
| are stored in password managers, not the kinds used by hardware
| security keys. Those in a password manager have always been
| technically copyable somehow, there just wasn't a standard
| format or protocol for doing so.
| taeric wrote:
| I knew that "passkey" had grown to refer to a set of
| different things. I can't say this upsets me, as it does
| sound like progress over the old status quo. Still, is
| confusing for those of us that bought in at the beginning.
| lxgr wrote:
| The terminology is definitely a mess, but I believe at
| least "passkey" has never referred to hardware
| authenticators. Those were usually called "security keys"
| or similar.
| jakub_g wrote:
| Something that is not clear to me about passkeys and makes me
| uneasy to start using them:
|
| Are passkeys replacing passwords, 2FA, or both?
|
| What if I created a passkey on some device, lost that device, and
| my passkeys aren't cloud-backed-up? Would I be able to recover my
| account, or it's doomed? Or does it depend on how a given website
| implemented it?
| rootusrootus wrote:
| If the passkey is all you have, then you're doomed (at least to
| the extent of whatever alternative recovery procedures the
| vendor is making available to you). That's why it's pretty
| universal to provide backup codes to put in your safe when
| setting up a passkey.
| create-username wrote:
| you should have passkeys on at least two or three devices
| lovethevoid wrote:
| Two things:
|
| You kind of have to go out of your way to not have your keys
| backed up. By default, the easiest route is using your android
| or iphone and both of them back the keys up using icloud
| Keychain or google password manager. 1Password, bitwarden, all
| support syncing. Chrome will allow saving it to icloud or your
| google account. Keepass can be manually synced. Windows is
| adding sync in the next update for windows hello. List goes on.
|
| The other thing is that multiple keys can be created. Easiest
| way to see this in action is google's account security
| settings. Log in (if you have an account), hit create passkey,
| see your options and play around with them. You'll also see you
| can add a hardware security key too, which isn't nothing new
| but if you have one that's another key that doesn't rely on a
| mobile device!
|
| If all else fails, the usual account recovery process applies.
| Much like it would if you forgot your password.
| rootusrootus wrote:
| This is good. One thing holding me back from fully embracing
| passkeys has been the inability to export passkeys in a format
| that I can store in a way that suits my preferences. This should
| solve that. Well, at least 1Password claims it will...
| dustyventure wrote:
| I find it silly and backwards to implement this. One has a
| private key and one could use it to act as a ~CA attesting for
| the establishment of another key with the relying party. Then one
| would always know what the hell happened when keys inevitably end
| up getting compromised by the poor practices of some of the
| vendors.
| greycol wrote:
| It's clearly a compromise, but if we were going for a perfect
| implementation then everyone would have a local/self hosted
| soloution. This just means in the case of a bad vendor/unwanted
| default/change to a better vendor you can migrate away from
| them quickly (and not need to visit them again) without having
| to update all your pass keys at once.
|
| I'd expect good vendors to be popping up "You haven't updated
| your passkey for this site since you migrated to us, you should
| go to your account settings and do so" on login to a site.
| teeray wrote:
| What's stopping providers from saying a collective "no" and
| forking the standard?
___________________________________________________________________
(page generated 2024-10-16 23:01 UTC)