The thread here seems like a dumpster fire to me. Everyone here is worrying about lock-in to an open standard, so I want to clarify things.
WebAuthn is an open standard. It's a way for you to prove to a website that you have a specific private key. There's no lock-in, because the key is portable (unless you don't want it to be). There's no privacy issue, because the key is unique per website. There's no security issue, because it's unphishable and can be unstealable if it's in hardware.
If you don't like Google or Apple, use your favorite password manager. All it will have to keep is a private key per website, and you're done. No usernames or passwords. You visit a site and are automatically logged in with a browser prompt.
This is amazing, it's the best thing that's ever happened to authentication. It's something the end user cannot have stolen. Can we be a bit more excited about it?
EDIT: If you want to try it, I just verified that https://www.pastery.net/ works great with Passkeys even though I haven't touched the code in a year.
That means that django-webauthin also works great with Passkeys, for you Django users:
> The thread here seems like a dumpster fire to me. Everyone here is worrying about lock-in to an open standard.
There is a certain fiddling-while-Rome-burns quality to this comment. The blog post is not about the open standard, it explicitly focuses on a specific company's products. People are naturally worried about this even though the standard may be open, because we are at historically high levels of platform lock-in from megacorps. Gmail is the new "Blue E". Getting locked out of your Google account in 2022 is probably much worse than not being able to use a different browser in 2001.
Sure, HTTP is also an "open standard". How many real browsers exist that can play DRM-encumbered media? You'll find that the answer is "very few – basically anything made by Apple, Google, or Mozilla" (perhaps Brave as well, which has an ex-Mozilla founder and uses Google-funded tech).
The best way to get people to adopt the open standard is to actually showcase uses of it that are not just a single company's product, not call them names for being worried about lock-in.
Right, but that's like Gmail coming out and people complaining about another proprietary product locking people in. There are two issues with the current comments:
1. Absolutely nobody currently uses WebAuthn. I'm extremely excited about the popularization, which, unfortunately, requires big players to get behind it.
2. The comments feel very "oh my God this car I'm driving is heading towards the edge of the cliff even faster". Don't use Google, they're unreliable and evil. While I'm very excited about Passkeys popularizing WebAuthn, I don't think anyone should ever rely on Google for authentication, so just don't use them and use Bitwarden instead, if/when it supports Passkeys.
A vendor coming up with an implementation of a great standard isn't the problem, the fact that people use it is the problem.
> If you don't like Google or Apple, use your favorite password manager.
Unless the service you are trying to use requires that you use a particular model of authenticator, which the service provider can enforce via attestation.
> Unless the service you are trying to use requires that you use a particular model of authenticator, which the service provider can enforce via attestation.
Isn't it even worse? Browser vendors don't even offer any way to not use their baked-in authenticator? With WebAuthn they offered at least the options of using a security key via Bluetooth/NFC/Bluetooth as alternatives to the device authenticator. I don't see that option with passkeys.
So, there seems no way to use a password manager with passkeys.
I'm also surprised at how negative the reaction here is to Google embracing an open standard. Both Android and iOS devices keep your passwords/keys encrypted end-to-end between your devices. You can absolutely share passkeys between devices (if you want to) and even make them exportable to another secrets manager (if you want to).
If you ask me what's one thing in 2030 people will look back on and say "I can't believe we did that!" I'd have to say "passwords". Passwords need to die and WebAuthn is a great step forward.
Yes, WebAuthn is an open standard, but it seems that Passkeys can only be synced using Google password manager and I don't see any API that would allow the user to use a different password manager as is the case with the auto fill API.
Ah, that's interesting. So if I use Apple keys to log in to sites, I can never log in to them with my Android phone? That's unfortunate, though I don't see this being sustainable for too long, I imagine (and hope) they'll open it up to alternate authenticators soon.
As long as you don't need master key escrow to essentially be with the vendor (ex google / apple), you can have the master key backed up elsewhere so you can pass the mud puddle test [0], and the vendor has no way to access the master key, I'm ok.
But push google / apple about solving mud puddle problems and it's curiously missing from their wallet implementations and they stutter around it when they give talks about FIDO2 and such and people ask them. It's the lock in direction they see everyone going towards that makes people uncomfortable.
> There's no lock-in, because the key is portable (unless you don't want it to be).
> There's no security issue, because it's unphishable and can be unstealable if it's in hardware.
You mean, you can (in theory) choose whether you'd rather have a lock-in or a security issue. Both options are mutually exclusive, you can't have them both at the same time.
No, I don't. You don't have to use Google's thing, use an open source password manager that syncs via Dropbox or whatever. Same thing, different vendor.
> EDIT: If you want to try it, I just verified that https://www.pastery.net/ works great with Passkeys even though I haven't touched the code in a year.
There is a real privacy issue if online services will now force you to store your "passwords" on a device - whether it be in your phone or a password manager.
People are raising really good points here, but I do find it interesting how negatively this news is being received vs. when Apple said the same thing: https://news.ycombinator.com/item?id=31643917
The second most popular top level comment chain is:
> Unless I can back it up and import it into a new device from a competitor, then there is no way I am going to use this unless forced. I do not trust one company anymore.
Which is the same sentiment as this thread. The first comment was just talking about the open standard of Apple's implementation and weakness of 2FA loss/recovery.
Yup - GP made the mistake of treating HN as a single person with a coherent opinion. It's not, and it's extremely tiring and intellectually uninteresting to repeatedly see people doing that.
I find that sentiment ironic because I won't use it unless it can't be backed up (the main selling point of 2FA and hardware keys).
If it can be backed up, then a casual bystander/process can also "back up", filch all of your credentials in a few moments with you being none the wiser.
The protocol is open, so I can use one proprietary key from company A, one from company B, and a few open source keys. Keep one for regular use and the rest as backups.
It's not particularly surprising. Apple has a much better reputation at customer service than Google does – they have actual stores you can walk into.
Now I'm not sure whether they can help you unlock your Apple ID if you prove to them that you're the owner of the account, but I can at least visualize Apple having the scale to do that.
Google on the other hand has a horrendous reputation for locking out people out of their accounts totally and permanently. Of course everyone has concerns about handing all your account login responsibilities to a company with such terrible customer service.
Apple, on the other hand, has terrible problems with working with others that google does not.
Apple will happily tell you that if you want grandma to have a whatever color text bubble, you should buy her an iPhone, to name a recent example, rather than adopt the standard everyone else is using. I bought a Macbook last holiday season and couldn't even set it up until my wife set up her iPhone on my account to activate the laptop. I bought my wife a iWatch last week and briefly thought of getting myself one but you can't use it without an iPhone (they have a "kids" feature where a parent can activate it but it basically has no smarts at that point AFAIK).
So, for making an authentication standard, I'd trust Google over Apple.
At the risk of being pedantic, no. Apple Stores aren’t able or empowered to provide Apple ID support beyond what the public website based recovery workflows provide. I am sure someone will note that someone at an Apple Store has helped them reset an Apple ID password. What I mean is that Apple Store employees have neither procedure nor access to override Apple’s account system. You have to call support for assistance beyond what the website can do. I am sure Apple Store employees have been helpful and I’m sure policies have changed over time.
As an Apple user I find this as frustrating as it is wise. Mostly for future-me who may one day not be as savvy and manage to screw myself.
I don’t fully trust iCloud Keychain and Apple to never lose my data in a “I don’t concern myself with backups” manner. So I opt for using Passkeys where I can also add my FIDO2 tokens.
> but I can at least visualize Apple having the scale to do that.
> Google on the other hand has a horrendous reputation for
Neither are true nor false but definitely exaggerations. All you're doing is displaying personal biases by providing them with benefit-of-the-doubts. They too have a reputation for locking people out, and are well known for turning data over, but one that HN in gernal prefers to ignore.
Passkeys sound like another way for companies like Google and Apple to lock you into their walled garden. Having each walled garden randomly generating a key for every single domain instead of using the actual domain name as part of the key is a great way to lock regular people into their respective ecosystems.
My understanding of passkeys is that they are using WebAuthn under the hood (hence the nod to the w3c/FIDO at the end, and the fact that the passkey in the screenshot was associated with tribank.us).
They are solving a very real problem. WebAuthn uses private keys, but those private keys are tied to the device where they were created. This is a blessing and a curse.
It's a blessing because it eliminates a whole trove of phishing attacks. After all, if no one can get the private key, they can't steal or share it. Well, of course they could steal the actual device, but that's orders of magnitude harder than stealing online credentials (points to https://haveibeenpwned.com/ ). That's a good thing.
It's a curse because the same person logging in from their ipad, android phone, and desktop PC needs to set up WebAuthn three times. For each domain/website (broadly speaking). If they only set it up once and lose the device, well, they are either locked out or need to have another means of account recovery (username/password, calling a customer service rep).
This curse is what passkeys managed by Apple/Google are attempting to solve.
I believe the WebAuthn 3 draft is going to try to address some of this: https://www.w3.org/TR/webauthn-3/ but that's based on what a co-worker said. A quick scan didn't turn up anything.
> They are solving a very real problem. WebAuthn uses private keys, but those private keys are tied to the device where they were created.
To clarify I am not talking about the issue of syncing the device's private key. I am talking about the artificial problem these walled gardens are creating by having every single domain getting its own randomly generated private key. The only practical way to keep all of these randomly generated keys synced across multiple devices is to use the "cloud".
If instead the per site key was generated using a private key and the domain name, users would only need to transport that one private key to another device and would get syncing for free without the requirement of the "cloud".
Seems like you wouldn't want to share passkeys for the same reasons you don't normally want to share passwords?
Instead, each website that accepts passkeys should allow you to register multiple devices and probably print out backup codes as well (for the especially important accounts).
If there's no reason to migrate anything then lock-in is irrelevant. Just add more login methods so that when you lose some, you have others.
I have over 500 online accounts. Imagine if all of them used a login method where I had to have backup devices registered, instead of just me backing up the credentials (like I do today with a password manager).
With backup devices, whenever I upgrade or replace a device, I need to go to each of the 500+ online accounts and register the new device. This is much more work than a quick login to each site via my password manager (which can happen on-demand, only as I need to use the services).
Websites already have a hard time to get users to sign up, so requiring them to enroll backup authenticators (which they won't have) is not going to work. Printing or writing down backup codes is even worse from a UX point of view.
IIRC the spec has a flag to hint that the passkey is backed up (in iCloud or your Google account) so the relying party (website) knows whether backups are mandatory but that means the secret doesn't stay on your device and goes to the mothership. Then I don't see why the spec wouldn't standardize the transfer of secrets from one company to the other.
The entire third party auth push has turned into what may be one of the largest incumbent power grabs I have ever seen. Stuff like Google Amp or even App Store walled gardens pale in comparison.
What drives me nuts is how little discussion of this I've seen. People don't even seem aware of the implications of it. It's being pushed hard as a boon to security, which it is in some cases, but at a cost that nobody is even considering or talking about.
The implications are pretty profound: large companies having the power to lock you out of everything on a whim (even your own systems and unaffiliated third party services), levy taxes on the use of everything (e.g. Google starts charging you or sites to log in with Google), surveil literally everything (including logging into everything you have as you and sucking down data), and if a big identity provider gets seriously hacked it'll be an epic security apocalypse. Imagine someone stealing the master keys for a provider and pushing ransomware to millions of companies at once.
... and don't forget the obvious: "Oops I got locked out of Google and now I'm locked out of 50 SaaS services, my company's bank, my VPN, and my remote servers."
It just totally blows me away that these systems have no privacy protection at all, no portability provision for me to select or change my provider built into the protocol, no built-in support for third factor auth that I can control (e.g. FIDO2), no built in provision for recovery codes, and so on. These kinds of things didn't even seem like they were considered in the design of things like OpenID/OIDC. It's just a big "oh hey lets give god level access with no recourse to third parties and implement it so there's total lock-in... what could go wrong?"
Edit: yes some well-implemented systems offer their own built-in support for some of those things (recovery codes, changing your auth provider, reverting to password, etc.) but in my experience it's a minority and there is obviously nothing in the standard to encourage it or provide any guidance on how to do those things securely.
Man, every one of these comments has completely misunderstood the point. WebAuthn is an open standard. The provider is only there to sync your key. If you want, you can keep it yourself.
Why is everyone yelling about the sky falling down when this is the best thing to happen to authentication since ever?
This is also going to be a body blow for our privacy - if BigTech have access to your keys, so will the government and both can abuse it. The idea is to force you to "save password on device" (whether you want to or not) so that when a government authority gets your device they can also easily access all your internet accounts. US courts have already affirmed that it is legal for the police to force you to unlock your device if it is biometric protected (fingerprint or face scan etc.). Moreover, by forcing you to use your personal device for identity verification, BigTech is ensuring that identifying you and datamining your personal data becomes more easy for them. Don't be surprised if this is also extended in the future as a "super cookie" service to allow easy tracking.
I don't use my phone to log in to anything. All my stuff is done on a computer with a password manager.
At no time am I even likely to rely on Google for anything this important; every other week there's a thread about Google killing off accounts for no reason. No way would any sane person allow Google access to this with their track record. And this isn't even considering my suspicion that Google only wants to "help" with this so you're locked into their services and they are better able to track your activity.
Exactly. I will never trust Google to control access to my logins knowing that the Sword of Damocles (the Google "AI" deciding I'm a bad person) is hanging over my head.
If Google did an about face and started providing reasonable escalation mechanisms for when they lock you out of your account based on a faulty decision of their algorithm I'd consider it.
> I don't use my phone to log in to anything. All my stuff is done on a computer with a password manager.
More or less the same, except that I haven't found good TOTP solutions for the desktop, to the tune of KeePass (something that can run on Windows/*nix instead of making me use something like FreeOTP, Google Authenticator or other Android/iOS apps; or in addition to the mobile apps).
That said, even with multiple Google accounts for different things (e.g. personal e-mails, file storage, cloud services etc.) it feels like eventually you might want something like Qubes OS, another way to run multiple separate VMs, or just use separate devices for separate use cases.
Much like how some orgs have separate laptops for accessing prod environments, that are more tightly controlled, even though that's not convenient enough for most people.
Bitwarden will do TOTP, and its CLI tool is quite usable. If you want it fully local, just stand up a docker of their server software (which is open source) or the open source reimplementation (vaultwarden).
Depending on your setup you could just generate TOTPs on command line and copy to clipboard, that's what I've implemented: https://github.com/Ciantic/totper
It works pretty well with pass (password manager) that stores each individual entry in GPG encrypted file. GPG is pain, but if you happen to use it already then it works.
I’m with you, I de-Googled all my services a few years ago, and I couldn’t be happier with the decision.
I’m curious though, what’s preventing you from using a password manager on your phone? I use KeePass, and I’m able to use my password DB on any device I want.
How do you handle syncing? I use KeePassXC on my desktop, and I back up the encrypted password DB to SpiderOak, but I haven't figured out a good way to get that DB onto my phone, auto-synced.
Also are you worried about the security of the DB on your phone? My password DB's passphrase is a good 50+ characters long, which I can type quickly on my laptop, but I can't imagine pecking that out on a phone. And I feel like I would not want the DB unencrypted/unlocked all the time on my phone; given the possibility of my losing it or it getting stolen, I'd want it to re-lock immediately after each use.
Nothing really other than it's a device I can loose to easily or it could be stolen. I don't do banking on my phone either. Plus there's the hassle of syncing it too.
I don't think the point is that they can't. Just far more unlikely to, and there's usually more recourse. Google is mega-corp who never listens to their users, and are un-contactable. Some AI can and probably will ban some people for no real reason and even Google won't know why it happened.
you can always use a password manager like the KeePass family which is file based. sync it across devices with nextcloud/syncthing instead of gdrive/Dropbox/one if you are extra paranoid
In my experience on iOS, you can't make Passkeys work without also turning on syncing, that's sort of the entire point of Passkeys, otherwise they would just be WebAuthN tokens.
From TFA (the security blog): "The main ingredient of a passkey is a cryptographic private key. In most cases, this private key lives only on the user's own devices, such as laptops or mobile phones."
Final step is key escrow authority that will store your private key and produce it to you if you can proof your identity with government ID. It is not enough to store in cloud storage (which Google, Apple, or someone else could deny you access to), or your own device you could lose or destroy (which is why backup hardware tokens are always recommended for U2F MFA); you need the ability (but not a requirement) to bind cryptographic identity to IRL identity.
Of course, one doesn’t need to utilize this, but you’re SOL without a recovery mechanism of last resort (unless individual sites and services have their own recovery processes to re-provision a user who no longer has access to their cryptographic credentials).
Except for the fact that a mobile phone does not, as far as I'm concerned, fall in the "user's own device" category, as much as Google would like you to believe it does.
"on your device" doesn't mean that you can actually access the key though. It might be stored in the secure enclave/TPM or otherwise unavailable if the phone has a locked bootloader.
so what? maybe it is also pinned to your google account so regardless that it's a private key that only lives on your device, doesn't at all mean you can somehow transfer it. it could simply be one of many components that make up the effective key.
For all the talk of "one app to rule them all" (which is an awful idea) this is a step closer to that.
For all it's faults, crypto has one thing right -- not your keys, not your stuff. I get that doing keys/passwords is hard, but the best thing in the long run is for them to stay in the hands of the user.
And if not, the holder of the keys needs to be someone you can easily hold accountable, i.e. either fire, or arrest, or sue if they get it wrong.
> For all it's faults, crypto has one thing right -- not your keys, not your stuff
Erm, this isn't really an aspect of cryptocurrency, per se. It's more of a general rule that informed the initial thinking around cryptocurrency. In fact, most users of cryptocurrency seem quite content to give up cryptographic custodianship.
If you went back a similar time to the nascent web/cloud/etc, you'd find plenty of similar sentiment about remote software and storage. It's just that individual autonomy loses out over time due to convenience created by the massive investment in the surveillance economy.
That's a fair point, in that I should have said something like "crypto-fundamentalists." But the idea is the one I wanted to get across, and I have mostly those same feelings about remote software and storage (e.g. I tell students, priority one in your life -- if there's something digital you care about, e.g. photos, get at least one copy of them on something you can hold in your hand)
And BigTech's cloud (who will have no problem sharing it with the authorities). And when all your keys are on the device, it also becomes a lot easier for the government to access all your internet accounts by getting access to the device.
Pretty sure there's been talk on the Bitwarden community forums about them adopting support for using it as a provider. I assume once that's available you might start to see it move into Vaultwarden. But, that's sort of the risk you run with using a 3rd party to a 3rd party...
At least with Vaultwarden, it's open source and running locally with data stored on a server in my house, so if they misbehave, I could easily fork or switch projects. If Android doesn't allow or otherwise hobbles 3rd party password managers, there isn't much recourse.
Readit News
WebAuthn is an open standard. It's a way for you to prove to a website that you have a specific private key. There's no lock-in, because the key is portable (unless you don't want it to be). There's no privacy issue, because the key is unique per website. There's no security issue, because it's unphishable and can be unstealable if it's in hardware.
If you don't like Google or Apple, use your favorite password manager. All it will have to keep is a private key per website, and you're done. No usernames or passwords. You visit a site and are automatically logged in with a browser prompt.
This is amazing, it's the best thing that's ever happened to authentication. It's something the end user cannot have stolen. Can we be a bit more excited about it?
EDIT: If you want to try it, I just verified that https://www.pastery.net/ works great with Passkeys even though I haven't touched the code in a year.
That means that django-webauthin also works great with Passkeys, for you Django users:
https://pypi.org/project/django-webauthin/
Also, the latest Firefox on Android seems to work great.
There is a certain fiddling-while-Rome-burns quality to this comment. The blog post is not about the open standard, it explicitly focuses on a specific company's products. People are naturally worried about this even though the standard may be open, because we are at historically high levels of platform lock-in from megacorps. Gmail is the new "Blue E". Getting locked out of your Google account in 2022 is probably much worse than not being able to use a different browser in 2001.
Sure, HTTP is also an "open standard". How many real browsers exist that can play DRM-encumbered media? You'll find that the answer is "very few – basically anything made by Apple, Google, or Mozilla" (perhaps Brave as well, which has an ex-Mozilla founder and uses Google-funded tech).
The best way to get people to adopt the open standard is to actually showcase uses of it that are not just a single company's product, not call them names for being worried about lock-in.
1. Absolutely nobody currently uses WebAuthn. I'm extremely excited about the popularization, which, unfortunately, requires big players to get behind it.
2. The comments feel very "oh my God this car I'm driving is heading towards the edge of the cliff even faster". Don't use Google, they're unreliable and evil. While I'm very excited about Passkeys popularizing WebAuthn, I don't think anyone should ever rely on Google for authentication, so just don't use them and use Bitwarden instead, if/when it supports Passkeys.
A vendor coming up with an implementation of a great standard isn't the problem, the fact that people use it is the problem.
Unless the service you are trying to use requires that you use a particular model of authenticator, which the service provider can enforce via attestation.
Android's implementation of passkeys currently does not support attestation. https://groups.google.com/a/fidoalliance.org/g/fido-dev/c/nh...
Neither does Apple's, I believe.
So, there seems no way to use a password manager with passkeys.
If you ask me what's one thing in 2030 people will look back on and say "I can't believe we did that!" I'd have to say "passwords". Passwords need to die and WebAuthn is a great step forward.
But push google / apple about solving mud puddle problems and it's curiously missing from their wallet implementations and they stutter around it when they give talks about FIDO2 and such and people ask them. It's the lock in direction they see everyone going towards that makes people uncomfortable.
[0] https://blog.cryptographyengineering.com/2012/04/05/icloud-w...
> There's no security issue, because it's unphishable and can be unstealable if it's in hardware.
You mean, you can (in theory) choose whether you'd rather have a lock-in or a security issue. Both options are mutually exclusive, you can't have them both at the same time.
It does not work with Chrome on Android.
There is a real privacy issue if online services will now force you to store your "passwords" on a device - whether it be in your phone or a password manager.
> Unless I can back it up and import it into a new device from a competitor, then there is no way I am going to use this unless forced. I do not trust one company anymore.
Which is the same sentiment as this thread. The first comment was just talking about the open standard of Apple's implementation and weakness of 2FA loss/recovery.
https://news.ycombinator.com/item?id=31644190
If it can be backed up, then a casual bystander/process can also "back up", filch all of your credentials in a few moments with you being none the wiser.
The protocol is open, so I can use one proprietary key from company A, one from company B, and a few open source keys. Keep one for regular use and the rest as backups.
Especially when that company is Google.
Now I'm not sure whether they can help you unlock your Apple ID if you prove to them that you're the owner of the account, but I can at least visualize Apple having the scale to do that.
Google on the other hand has a horrendous reputation for locking out people out of their accounts totally and permanently. Of course everyone has concerns about handing all your account login responsibilities to a company with such terrible customer service.
Apple will happily tell you that if you want grandma to have a whatever color text bubble, you should buy her an iPhone, to name a recent example, rather than adopt the standard everyone else is using. I bought a Macbook last holiday season and couldn't even set it up until my wife set up her iPhone on my account to activate the laptop. I bought my wife a iWatch last week and briefly thought of getting myself one but you can't use it without an iPhone (they have a "kids" feature where a parent can activate it but it basically has no smarts at that point AFAIK).
So, for making an authentication standard, I'd trust Google over Apple.
As an Apple user I find this as frustrating as it is wise. Mostly for future-me who may one day not be as savvy and manage to screw myself.
I don’t fully trust iCloud Keychain and Apple to never lose my data in a “I don’t concern myself with backups” manner. So I opt for using Passkeys where I can also add my FIDO2 tokens.
> Google on the other hand has a horrendous reputation for
Neither are true nor false but definitely exaggerations. All you're doing is displaying personal biases by providing them with benefit-of-the-doubts. They too have a reputation for locking people out, and are well known for turning data over, but one that HN in gernal prefers to ignore.
They are solving a very real problem. WebAuthn uses private keys, but those private keys are tied to the device where they were created. This is a blessing and a curse.
It's a blessing because it eliminates a whole trove of phishing attacks. After all, if no one can get the private key, they can't steal or share it. Well, of course they could steal the actual device, but that's orders of magnitude harder than stealing online credentials (points to https://haveibeenpwned.com/ ). That's a good thing.
It's a curse because the same person logging in from their ipad, android phone, and desktop PC needs to set up WebAuthn three times. For each domain/website (broadly speaking). If they only set it up once and lose the device, well, they are either locked out or need to have another means of account recovery (username/password, calling a customer service rep).
This curse is what passkeys managed by Apple/Google are attempting to solve.
I believe the WebAuthn 3 draft is going to try to address some of this: https://www.w3.org/TR/webauthn-3/ but that's based on what a co-worker said. A quick scan didn't turn up anything.
If you want to know more about WebAuthn, I wrote a lot more here (my company is going to release an implementation Real Soon Now): https://fusionauth.io/learn/expert-advice/authentication/web...
To clarify I am not talking about the issue of syncing the device's private key. I am talking about the artificial problem these walled gardens are creating by having every single domain getting its own randomly generated private key. The only practical way to keep all of these randomly generated keys synced across multiple devices is to use the "cloud".
If instead the per site key was generated using a private key and the domain name, users would only need to transport that one private key to another device and would get syncing for free without the requirement of the "cloud".
Or just get some Yubikeys.
Deleted Comment
Instead, each website that accepts passkeys should allow you to register multiple devices and probably print out backup codes as well (for the especially important accounts).
If there's no reason to migrate anything then lock-in is irrelevant. Just add more login methods so that when you lose some, you have others.
With backup devices, whenever I upgrade or replace a device, I need to go to each of the 500+ online accounts and register the new device. This is much more work than a quick login to each site via my password manager (which can happen on-demand, only as I need to use the services).
Websites already have a hard time to get users to sign up, so requiring them to enroll backup authenticators (which they won't have) is not going to work. Printing or writing down backup codes is even worse from a UX point of view.
IIRC the spec has a flag to hint that the passkey is backed up (in iCloud or your Google account) so the relying party (website) knows whether backups are mandatory but that means the secret doesn't stay on your device and goes to the mothership. Then I don't see why the spec wouldn't standardize the transfer of secrets from one company to the other.
What drives me nuts is how little discussion of this I've seen. People don't even seem aware of the implications of it. It's being pushed hard as a boon to security, which it is in some cases, but at a cost that nobody is even considering or talking about.
The implications are pretty profound: large companies having the power to lock you out of everything on a whim (even your own systems and unaffiliated third party services), levy taxes on the use of everything (e.g. Google starts charging you or sites to log in with Google), surveil literally everything (including logging into everything you have as you and sucking down data), and if a big identity provider gets seriously hacked it'll be an epic security apocalypse. Imagine someone stealing the master keys for a provider and pushing ransomware to millions of companies at once.
... and don't forget the obvious: "Oops I got locked out of Google and now I'm locked out of 50 SaaS services, my company's bank, my VPN, and my remote servers."
It just totally blows me away that these systems have no privacy protection at all, no portability provision for me to select or change my provider built into the protocol, no built-in support for third factor auth that I can control (e.g. FIDO2), no built in provision for recovery codes, and so on. These kinds of things didn't even seem like they were considered in the design of things like OpenID/OIDC. It's just a big "oh hey lets give god level access with no recourse to third parties and implement it so there's total lock-in... what could go wrong?"
Edit: yes some well-implemented systems offer their own built-in support for some of those things (recovery codes, changing your auth provider, reverting to password, etc.) but in my experience it's a minority and there is obviously nothing in the standard to encourage it or provide any guidance on how to do those things securely.
Why is everyone yelling about the sky falling down when this is the best thing to happen to authentication since ever?
If they could just use their fingerprint/faceID to login (after initial registration on the device) they would be super happy.
Rest of us should be happy there will be less exploits where people give up the keys to their kingdom by clicking on a random email.
Deleted Comment
At no time am I even likely to rely on Google for anything this important; every other week there's a thread about Google killing off accounts for no reason. No way would any sane person allow Google access to this with their track record. And this isn't even considering my suspicion that Google only wants to "help" with this so you're locked into their services and they are better able to track your activity.
https://blog.1password.com/1password-is-joining-the-fido-all...
If Google did an about face and started providing reasonable escalation mechanisms for when they lock you out of your account based on a faulty decision of their algorithm I'd consider it.
More or less the same, except that I haven't found good TOTP solutions for the desktop, to the tune of KeePass (something that can run on Windows/*nix instead of making me use something like FreeOTP, Google Authenticator or other Android/iOS apps; or in addition to the mobile apps).
That said, even with multiple Google accounts for different things (e.g. personal e-mails, file storage, cloud services etc.) it feels like eventually you might want something like Qubes OS, another way to run multiple separate VMs, or just use separate devices for separate use cases.
Much like how some orgs have separate laptops for accessing prod environments, that are more tightly controlled, even though that's not convenient enough for most people.
https://github.com/browserpasshttps://www.passwordstore.org/
It works pretty well with pass (password manager) that stores each individual entry in GPG encrypted file. GPG is pain, but if you happen to use it already then it works.
I’m curious though, what’s preventing you from using a password manager on your phone? I use KeePass, and I’m able to use my password DB on any device I want.
Also are you worried about the security of the DB on your phone? My password DB's passphrase is a good 50+ characters long, which I can type quickly on my laptop, but I can't imagine pecking that out on a phone. And I feel like I would not want the DB unencrypted/unlocked all the time on my phone; given the possibility of my losing it or it getting stolen, I'd want it to re-lock immediately after each use.
Provided Apple has fewer services and less surface for your account to get banned, but that's still a valid concern.
"Only on the user's device", right.
Of course, one doesn’t need to utilize this, but you’re SOL without a recovery mechanism of last resort (unless individual sites and services have their own recovery processes to re-provision a user who no longer has access to their cryptographic credentials).
For all the talk of "one app to rule them all" (which is an awful idea) this is a step closer to that.
For all it's faults, crypto has one thing right -- not your keys, not your stuff. I get that doing keys/passwords is hard, but the best thing in the long run is for them to stay in the hands of the user.
And if not, the holder of the keys needs to be someone you can easily hold accountable, i.e. either fire, or arrest, or sue if they get it wrong.
Erm, this isn't really an aspect of cryptocurrency, per se. It's more of a general rule that informed the initial thinking around cryptocurrency. In fact, most users of cryptocurrency seem quite content to give up cryptographic custodianship.
If you went back a similar time to the nascent web/cloud/etc, you'd find plenty of similar sentiment about remote software and storage. It's just that individual autonomy loses out over time due to convenience created by the massive investment in the surveillance economy.