FIDO Alliance publishes new spec to let users move passkeys across providers

https://fidoalliance.org/fido-alliance-publishes-new-specifications-to-promote-user-choice-and-enhanced-ux-for-passkeys/

by Terretta • 2 years ago

225 272 2 years ago

fidoalliance.org

troupo5• 2 years ago

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'état of authentication, just like they did for HTML itself.
In the end, they control every protocol, become the gatekeepers for the web.

NikolaNovak4• 2 years ago

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• 2 years ago

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…

wolletd3• 2 years ago

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.

izacus5• 2 years ago

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.

buro9• 2 years ago

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.

ratorx3• 2 years ago

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.

lapcat2• 2 years ago

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.

lll-o-lll2• 2 years ago

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.

lapcat2• 2 years ago

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.

skybrian6• 2 years ago

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• 2 years ago

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.

solarkraft2• 2 years ago

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.

rcxdude3• 2 years ago

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• 2 years ago

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• 2 years ago

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• 2 years ago

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)

commandersaki2• 2 years ago

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.

lovethevoid2• 2 years ago

KeepassXC already supports passkeys

rprospero• 2 years ago

I'm curious if you count Pass (https://www.passwordstore.org/) as not being "in town" or if it has issues with user freedom that I'm ignorant of.

ratorx3• 2 years ago

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• 2 years ago

A bit is understatement. If this passkeys become widespread, we are talking about like 100 sites.

Jnr• 2 years ago

If you go for passkeys, start putting them in your own provider from the start? Vaultwarden is a nice option.

HeatrayEnjoyer2• 2 years ago

There shouldn't be. Secure enclaves aren't secure if they can be copied

lucianbr• 2 years ago

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• 2 years ago

Secured against who?

eikenberry3• 2 years ago

So you are against this new spec becoming a standard then?

benlivengood• 2 years ago

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.

noirscape• 2 years ago

In that case, the keys would be a non-starter. The overwhelming majority of tech requests relate to people forgetting their passwords and getting in trouble because the browser's password manager forgot the password itself.

The reality is that the biggest pushers of Passkeys are the providers with the least amount of infrastructure stability. If you want people to get to use Passkeys, providing an exit tool from Google and Apple is a must, because both providers are godawful at not accidentally mushing up your data. That's not so important if all you're using their infrastructure for is a periodic backup/use it to transfer photos to your PC, but it's a problem for anything that has to be stored long-term.

lxgr23• 2 years ago

Passkeys and secure enclaves are only loosely related. You can implement one using the other, but it’s by no means a requirement.

And even when they are, nothing says that secure enclaves can’t have importable or exportable keys. Many schemes do both on a regular basis.

Terr_3• 2 years ago

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• 2 years ago

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.

anilakar2• 2 years ago

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.

ithkuil2• 2 years ago

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• 2 years ago

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• 2 years ago

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.

eikenberry3• 2 years ago

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• 2 years ago

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• 2 years ago

Yes. My other Yubikey is in a bank vault.

I do not want a remote "authentication provider".

anilakar2• 2 years ago

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.

growse7• 2 years ago

If you want a Webauthn credential that you can "copy", don't use a Yubikey. Use something like KeepassXC, BitWarden etc. instead.

itohihiyt2• 2 years ago

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• 2 years ago

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• 2 years ago

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.

itohihiyt2• 2 years ago

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.

hooverd2• 2 years ago

Ok, but why should that stop me?

solarkraft2• 2 years ago

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.

skybrian6• 2 years ago

You can create backup keys by creating more passkeys.

lelandbatey2• 2 years ago

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.

JohnFen3• 2 years ago

I don't think that's really a workable solution.

Shank• 2 years ago

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.

rlpb2• 2 years ago

I’m already using a password manager. I struggle to see the security benefit to storing passkeys in them.

On the other hand I like the security benefit of hardware passkeys. But these are unusable because 1) most sites that support passkeys don’t support registration of more than one passkey, and it’s hard to determine if they do or not, and 2) the security benefit is defeated if sites allow recovery without a registered passkey, which most do, and again it’s hard to figure out if they do or not.

So what’s the point?

andrewaylett• 2 years ago

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.

ziml77• 2 years ago

That was basically what I was going to say too. The most secure keys are the ones that can't be transferred. If I want protection against the loss of a hardware security key like a Yubikey, I have to get a second one and register that one as a secondary key to log in.

Technically you can generate a GPG key and load that onto multiple Yubikeys, but that's not as secure as letting the Yubikey itself generate the key. Plus if you only use one GPG key and one of the Yubikeys is lost (but not destroyed) then you have to rewrite all the remaining Yubikeys with a new GPG key since you can't selectively revoke them.

arccy• 2 years ago

if you can get a backup, someone can get scammed into providing that to an attacker, taking away any security benefit.

gre345t344• 2 years ago

To be fair, the webauthn spec expressly forbids facilitating the extraction of credentials from the authenticator (though arguably even syncing between devices violates the spec).

lxgr23• 2 years ago

If the vast majority of implementers (by users) are not compliant with a spec, that arguably says something about the spec as well.

MarkMarine7• 2 years ago

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.

ndriscoll5• 2 years ago

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• 2 years ago

Requiring MDM for attestation seems like the extremely-obvious answer to all this, yea.

High(er) security environments exist, and some extremely anti-user features make tons of sense there - anti-user is kinda the point, you don't want people to do anything they like. But those environments should not be allowed to impact any other environments, it's just going to foster abuse. MDM divides them very cleanly.

MarkMarine7• 2 years ago

You missed the rest of that sentence from your quote. It's an open spec, suggest changes to the spec, not me. I didn't write it. I actually agree you should be able to use whatever device you want. I'm a relaying party and I don't require attestation.

There are businesses and their employees trying to influence passkeys to push more towards their business models, because this does shut down a whole avenue of fraud and associated fraud fighting tools that are no longer needed, so there is a boatload of money out there trying to make passkeys worse. Comment on the spec and make your voice heard please.

lxgr23• 2 years ago

Where are you still seeing attestation?

Both Apple and (I believe) Google threw theirs out when they moved to synchronizing passkeys, and they’re both widely supported by relying parties.

Other than that, I think it’s fair for e-signature etc. services to be able to require a physical, non-synchronizing credential like a Yubikey. With such a service, it’s not just your (as the key owner), but also others’ security on the line when breaches happen.

crote• 2 years ago

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.

the_svd_doctor• 2 years ago

Resident keys essentially kill physical tokens.

Can you elaborate? I'm curious. Is there a storage problem?

MarkMarine7• 2 years ago

Again, ya’ll are living in a different world. Passkeys doesn’t have to support your use case, you’ve already got FIDO 2 keys for this. Physical keys have been readily available for over a decade from yubikey and the market penetration for consumers is basically zero.

comex• 2 years ago

With resident keys? A couple dozen, if you're lucky.

Or, future tokens start bundling a bit of flash storage and make this a non-issue. Considering how cheap it is, that ought to be possible even for low-cost tokens.

gre345t344• 2 years ago

Ideally you should not be able to determine whether a username is valid without authenticating.

lxgr23• 2 years ago

I use passkeys for everything I can and I've never once seen friction.

That’s great for you, but they don’t currently work like that for anyone

- using anything other than Chrome or Safari (many sites perform broken user agent based support detection)

- using both iOS and Android (at least not without setting up a third-party password manager, which not everybody knows how to do, or even why)

- not using iCloud (iOS just outright refuses to store local-only credentials, last time I checked at least)

Passkeys are absolutely an improvement for anyone able to use them, but that’s still strictly less users that can use passwords. And even for those that can use them, the availability story is still worse (almost by design, but that’s no consolation for a locked-out user).

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.

I have, with no success. There seems to be a misalignment of priorities and incentives. I even understand where the editors are coming from, but like most industry-sponsored specs, it’s really not the democracy you’re trying to paint it as.

acdha• 2 years ago

The thing you have to factor in is that most people are at risk of phishing or password leaks by compromised sites. The vast majority of users don’t have the problems you mentioned so it’s a question of whether we should leave 90% of users at risk or let them have a safer, easier, faster experience while the remaining people continue doing what they are doing now or drop a few bucks on hardware tokens.

MarkMarine7• 2 years ago

There are already different specs for hardware tokens, if there was adoption by consumers people like me would support them, but there isn’t. Hell I was an early yubikey user as a consumer myself, but the utility was never there because there was so little adoption by regular people.

You’re 100% right that the experience isn’t seamless yet for people outside of apple’s ecosystem or google’s but this is just catching hold, and the spec isn’t complete, this original article demonstrates a real improvement that should fix a pain point.

So, I do appreciate the way you’re engaging on each point, but I don’t understand what changes _you_ would like to see.

Using anything other than chrome or safari These will improve as support improves, I see failures and then have to deal with support calls when the user is on something that isn’t supported well. I don’t check user agent, but it would cut down on my support costs.
using iOS and Android without a 3rd party password manager

Ok, I understand the problem here, and I think I understand the issue with passkeys not being savable like a ssh key, because the apple and android ecosystem is using its keychain and syncing that keychain with its respective cloud service, you can’t use the same passkey on both systems… but the restriction here saves the users from losing these digital keys or having them stolen, and saves me as someone trying to protect their money from basically having to make a passkey need enough secondary data about your device and other factors. I think you’re missing what I posted about for 2 factor… to support it right now for anything other hardware keys (which are basically only supported in volume by a different central authority, like the IT dept)

I need a huge data vacuum operation on the backend to know who you are, where you are, what device you’re using, what that device has been doing recently, if you’ve swapped your sim, etc etc etc. as a counter, you can just make a passkey on the iOS and the android ecosystem, and now you’re good. Extend this to any other ecosystem you want. Yubico has an author on the spec, they aren’t ignoring the use of hardware keys. I’m sure you would be happy to not participate in that data vacuuming operation, and while it’s dual use (marketing and fraud prevention) they still have a veneer of use for the consumer.

Perfect is the enemy of good in this case. Let’s help all these regular people not get scammed

taeric4• 2 years ago

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?

Scion90662• 2 years ago

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.

taeric4• 2 years ago

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.

klausa2• 2 years ago

Passkeys don't need to be hardware bound.

The (probably?) most widespread implementation of them (iOS + macOS et. al) isn't; they're synced between devices.

lxgr23• 2 years ago

Passkeys aren’t identical with secure enclaves.

They can be stored in them, but also in software; even when stored in hardware, they can be marked as extractable to some trusted party (a companion device with the same root of trust, a trusted cloud sync service, a supply chain attacker etc.)

taeric4• 2 years ago

Fair, but if the secret is exportable, then it loses a ton of its power.

If you are worried about state level activity, have it stored in a single place that can be compelled by law to disclose it and that is off the table for you.

Which, sure, you can argue that there are still hardware tokens for people. But that is itself a signal, no?

gcr• 2 years ago

Hardware-bound passkeys have always been copyable by the proprietary vendor.

Make a passkey on your Mac, it appears on your iPhone.

Make a passkey on your Android, it appears on your other Androids.

Anyone who can bind a new iPhone or Android to your Apple/Google account wins your passkeys. I think the only passkeys properly tied to hardware are dedicated FIDO devices.

yencabulator• 2 years ago

By definition, if it can be copied out it wasn't hardware-bound.

Yubikeys are tamper-proof and cannot be copied. Everything else is just a place to store a statement that your cloud vendor of choice blesses this gadget to authenticate your account.

jakub_g2• 2 years ago

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?

rootusrootus3• 2 years ago

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-username2• 2 years ago

you should have passkeys on at least two or three devices

lxgr23• 2 years ago

Unfortunately that pattern negates many benefits of WebAuthN: That recovery code is phishable, can be captured by malware on the client or server etc.

jesseendahl5• 2 years ago

Account recovery flows are generally entirely unaffected by the move from password to passkey.

It’s just your login credential.

If you lose either a password or a passkey, you do the same thing: set a new one via email recovery.

CatWChainsaw• 2 years ago

A backup code is a password made of numbers.

lovethevoid2• 2 years ago

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.

Fire-Dragon-DoL2• 2 years ago

So we still need a passkey + second factor, isn't that the case?

And if my google account gets banned, I lose access to a trillion things instead of just one.

I was hoping passkeys would work on 1password,but chrome/brave don't support that yet.

It seems like a passkey is just a password though

thayne• 2 years ago

The other thing is that multiple keys can be created.

That depends on the site. For Google, sure you can add multiple passkeys. But many other sites will just do minimum effort and only allow you to register a single passkey.

bobbylarrybobby• 2 years ago

It's easy to have your keys backed up to a device, but then the question becomes losing the device and being able to get back into a new one. I know that Google really, really likes to make sure it's you when you log in from an unexpected device, location, IP, etc, and it might be hard to prove that it's you without that one device.

lisper7• 2 years ago

Are passkeys replacing passwords, 2FA, or both?

They are advertised as a replacement for passwords, but the truth is that they are orthogonal to both passwords and 2FA. They are a completely different kind of authentication.

Both passwords and passkeys work by proving that you know a secret. The difference is that with a password, the way you prove that you know the secret is by revealing it, which leaves you open to phishing. The other problem with passwords is that the secret is generally one that you are expected to type and remember, which limits how long and random it can be.

With passkeys, the secret is a public key (EDIT: in the sense of public-key encryption. The secret is actually the secret part of a public-private keypair), that is, a long string of random bits that a normal human could not remember even if they wanted to, and the way you prove that you know it is using that key to produce a digital signature for a random challenge. You never reveal your key during normal operation, and that makes it more resistant against phishing.

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?

It depends on how a web site implements it, but keep in mind that everything that makes it easier to recover from a lost key also makes your account more vulnerable to attack. So having backups of your passkey keys is a really good idea. But those backups don't have to be in the cloud. You could keep local copies on your own devices, or even print the key on a sheet of paper and keep that in a safe.

scherlock3• 2 years ago

I don't see how passkeys do anything to prevent phishing.

bastawhiz6• 2 years ago

It depends on how a web site implements it, but keep in mind that everything that makes it easier to recover from a lost key also makes your account more vulnerable to attack. So having backups of your passkey keys is a really good idea. But those backups don't have to be in the cloud. You could keep local copies on your own devices, or even print the key on a sheet of paper and keep that in a safe.

Obviously this isn't bad advice, but it is the reason I won't be diving into passkeys any time soon. Firefox Sync (the original version) had this philosophy: it's perfectly secure but if you lose your key, you've lost your bookmarks, history, and anything else that gets synced. For non-power users this is a catastrophic failure mode. For power users this still happens and it sucks. I was at Mozilla during this time and the failure modes of Sync were impressively common, even among employees.

Nobody expects to lose their backup. If you were a victim of hurricane Helene, it's entirely likely your safe is gone and all of your devices are destroyed. If that also means you've permanently lost access to your files or email or whatever, that's really really bad. And completely within the realm of possibility!

Obviously you can't fix this with cryptography alone. But it shows that passkeys can't be implemented as a full solution.

regedit7282• 2 years ago

Minor correction (I'm assuming it was a typo) -- the secret for the passkey should be the private key. The server stores the user's corresponding public key.

Based on my (limited) understanding from reading the page: 1. Server generates challenge, sends a challenge 2. User device signs the challenge by encrypting with its private key, returns the signature. 3. Server verifies the signature by decrypting with the public key.

As you mentioned, the private key (the only thing that can generate a valid signature) isn't leaked.

dwaite• 2 years ago

Are passkeys replacing passwords, 2FA, or both?

The minimum bar is replacing passwords with something more secure for the user.

If the site wants more specific factors or characteristics of authentication (such as a non-cloneable possession factor) then only some authenticators provide that today themselves. For someone using a synced software provider, they will need to do an additional step to meet this sort of requirement.

Factors aren't nearly as solid as they are made out to be - my SMS OTP is synched to all my devices, my TOTP keys come from a software implementation right alongside my password - which isn't a true knowledge factor because it was auto-generated for me. Password managers and other software have long put us on the path of sites leveraging externalized authentication processes and policies, similar to how they might do this explicitly by accepting federation.

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?

The syncing is meant to make it harder to lose the passkey. Sites still ultimately have to have a recovery process when someone does lose access.

ForHackernews2• 2 years ago

Sites still ultimately have to have a recovery process when someone does lose access.

Do they? Is that legally mandated somewhere, or can they just say "You're stuffed, make a new account if you want"?

gre345t344• 2 years ago

A FIDO2 credential can be used for passwordless authentication, so long as the authenticator performs user verification (e.g. requires a PIN). This counts as 2FA because it's something you have (the authenticator) plus something you know/are (PIN/biometric).

It can also be used as an second factor for traditional username/password auth (with or without user verification).

Losing a passkey is no different to losing any other credential: you need another method to authenticate or recover your account.

rootusrootus3• 2 years ago

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...

dustyventure5• 2 years ago

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• 2 years ago

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.

dustyventure5• 2 years ago

Leaving everyone finding the custom way to update/add a passkey when the fix for that would prevent sharing keys and needing to manually do something 100-1000 times to regain a little security.

The need for this compromise doesn't even make sense in light of all the past compromises. We pretty much know the RP is an an always online web site instead of variety U2F enables because that was apparently too hard and thrown out with everything else that didn't please always online keyvault makers.. Who is needing to compromise here?

teeray• 2 years ago

What’s stopping providers from saying a collective “no” and forking the standard?

bastawhiz6• 2 years ago

"and forking the standard" isn't necessary if you're not going to implement it.

karlkloss• 2 years ago

If they can be moved, they can be stolen. This'll boost acceptance, but also open a can of worms.

lxgr23• 2 years ago

They can already be moved in proprietary ways. This just adds a standard one.

reshlo4• 2 years ago

Passkeys are terrifying, and I don’t understand why the companies pushing them are doing so. What are their motives? What do they gain from catastrophically increasing the risk that users completely lose access to our ability to conduct our lives?

If someone steals my phone today, I can still access most of my accounts, and can regain access quickly to the others.

Now let’s assume passkeys are ubiquitous and used to log in to every website.

If they can’t be exported, then your entire digital existence is at the mercy of whatever device or technology platform you use to store your passkeys. If you lose access to the platform, you also permanently lose access to every single account you’ve ever signed up for. For me, that would include losing access to my retirement savings, tax records, and the ability to communicate with many of my friends, to give a few examples.

My computer also doesn’t have Bluetooth, which means I can no longer log in to any websites on it even when I do have access to my passkeys.

Hypnosis6173• 2 years ago

I mean, isn't the idea from them that you have 2 or more of them?

Shure not everybody does that and some sites don't really support that but thinking about this concept of having "physical key s" to your data makes a lot of sense to me.

Don't know how this change will affect my trust in the concept

ForHackernews2• 2 years ago

I don’t understand why the companies pushing them are doing so
your entire digital existence is at the mercy of whatever device or technology platform you use to store your passkeys.

JohnFen3• 2 years ago

An argument can be made that a weaker security option that is used by more people is better than a stronger security option that is used by fewer.

Passkeys come with enough friction and hassle that I don't actually use them. The ability to move or back them up removes one of the friction points.

zigzag3123• 2 years ago

Password vs. Passkey:

- Password is a single key, while passkey is a key-pair (private key & public key).

- Password can be weak, while passkey is always strong.

Password can be strong, if autogenerated.

- When authenticating, password can be send to the server (depending on the authentication protocol; SCRAM or PAKE based protocols never send password to the server). With passkey, private key is not send to the server for authentication purposes.

- Password manager can sync/backup your password and your passkey's "private" key.

- For a single service, same password is used from all devices. Passkey can be different for each device, but I'm not sure how this works (if it works) with sync/backup.

- Quantum-Safety: Key-derivation functions used with passwords are quantum-safe. Most (all?) asymmetric key algorithms, currently in commercial use (passkeys included), are not quantum-safe.

I'm not an expert on the topic. That's just a summary of my current understanding of passkeys, if it helps anyone. Note that mistakes are possible.

geoelectric• 2 years ago

Re you not being sure how sync would work with multi-device passkeys, you can share a passkey between devices with 1Password, Apple’s Keychain, etc, and use it to log in from any of them. I typically do this rather than manage them per-machine.

Per-machine passkeys would ostensibly be better hygiene, but only if I somehow kept them unsynced (easier said than done if you’re using Keychain). Having to manage that process would probably be more mistake-prone than just using the single passkey from my encrypted 1Password store.

zigzag3123• 2 years ago

Yeah, multi-device passkeys are easy to sync. Per-machine passkeys sync would be interesting, as it could not just copy the private key (as then it wouldn't be per-machine anymore), but would need to generate a new passkey for each synced device.

For example, if user has two devices with same password manager. To sync per-machine passkey from 1st to 2nd device, the password manager would have to initiate authentication with the service on the 2nd device and confirm it from the 1st device. I guess this process could be fully automated.

The advantage is that this enables disabling passkey for a specific device. If a device is stolen, a password/passkey manager could be used to disable all passkeys tied to that device.

Another advantage is that a private key doesn't need to be shared with a third-party. A cloud service provider doesn't need to ever see your private key, unless you also want to have a cloud based backup. But the passkey backed on the cloud would need to be an unique keypair and maybe even have a different authorization policy (e.g. requiring another authentication factor when using it).

VoodooJuJu• 2 years ago

It's also not a one or the other kind of thing.

The ideal auth system makes use of both, with the passkey or hardware token as the MFA component and a strong passphrase as the traditional password component. In this way, you are protected from phishing, which is the final weak point that MFA methods like TOTP do not address.

Unfortunately, globocorps are pushing for passkeys as the sole means of authentication, rather than just the MFA component. Being cynical, I'm guessing they're doing this to facilitate some kind of vendor lock-in or fingerprinting.

varjolintu• 2 years ago

The worst thing about passkeys is how browser extensions must handle them: using JavaScript injections to the web page. Of course this means _any_ browser extension could do the same and be the man-in-the-middle inspecting the passkey creation and authentication. I'd be glad to have some kind of standard API behind a proper permission for handling passkeys.

taeric4• 2 years ago

The only thing that they should be able to intercept there, though, would be the specific passkey for the page you are authenticating with. With the specific challenge that was included, even. Such that it is not exportable to somewhere else for them to authenticate as you.

Sure, it sucks that anything is interceptable. But this is still an improvement over the status quo.

tdpvb2• 2 years ago

While better in many ways, broadly speaking this could mean no more throwaway accounts?

Passkeys that require embedding on personal devices like cell phones means direct affiliation with your identity, no? Seems like a shadow benefit to industry is perfect ad targeting across the web.

dustyventure5• 2 years ago

No, a site can require attestation that you are on a kind of device but it can't correlate a key you have registered with it with one you create for any other site.

tdpvb2• 2 years ago

Right, but I imagine most sites will continue to use third-party authorization for passkeys, similar to Okto, Auth0, et al? They'd even be incentived to do so if it meant more granular user profiling -- all alongside third-party guarantees of "real verification", etc.

apple4ever• 2 years ago

After seeing this and reading about future plans from the spec writer, I am never using passkeys. There is zero reason export should be so hard.

FIDO Alliance publishes new spec to let users move passkeys across providers

Related Stories