Passkeys: A Loss of User Control?
lapcatsoftware.com
lapcatsoftware.com
Lose your (google) passkeys account for whatever reason (ai says no, wrongthink, itar ban), and you risk losing your digital life.
Edit: If you need MFA please do check out solokey, an open source Fido project.
There are other options out there.
If Google closed operations tomorrow, it wouldn’t affect anyone using a passkey to login to any service other than Google’s own.
They need to prove that this isn't going to be a bait and switch. Give users 100% control over their pass keys NOW before we consider using the service.
Otherwise, they're gonna play the "Oh, but most non-tech users will benifit from this" and then we get critical mass becuse a majority of users are non-tech users, and then the import/export function ends up being like the Official Linux Google Drive Client.
No. You’d be screwed when all of your devices stopped working before you enrolled another passkey with the services you use, or setting up a password login if you’d never done that before. That wouldn’t be great but you’d be far more exposed earlier to the fact that you were using devices which no longer receive updates.
The important thing to keep in mind here is context: people are getting compromised daily due to password weaknesses. People are going through account recovery processes for similar reasons, too, so a key question isn’t whether there’s a perfect option but rather how it’ll change those numbers.
That's the point: Google wants to collect your digital life and control it. But they also don't want to deal with any requirements to ensure you can actually use or recover it expediently.
So it's not "if Google close up shop" it's "due to reasons we've (our AI decided too) ban your account. Don't bother contacting us, as there is no customer service".
No. Other people have posted incorrect claims but repetition doesn’t make them less wrong. If Google locks your account, you lose the ability to add new devices to that account but all of your current devices will still have their synced keys stored on their devices as well as the ability to use other passkeys, recovery codes, etc. If Google locks your account, this is nowhere near the biggest problem you’ll have.
“We have concluded the review of the information you’ve submitted. To prevent possible fraud and abuse, your Google products and services will remain suspended. It is our policy to not discuss the specific reasons for these suspensions.
Note that in the Google <PRODUCT> Terms of Service, we reserve the right to change, suspend, or discontinue any aspect of our services at any time, including availability of a service or any feature, without notice and without liability. We also reserve the right to impose limits on certain Service features or restrict access to some or all of the Services without notice and without liability.”
It can wreck your life. Getting a suspension lifted can take a truly stupid amount of effort depending on the reason (if you even know it). For me it involved basically stalking employees until I was able to find someone who could actually review my account. Literally looking up employees by department and name on LinkedIn and Twitter, then trying to find their phone number and texting them. I must have sounded crazy. But I was able to find someone to help. Then it took like 5 minutes to fix. It was clear it was just a mistake on their end—an, “overzealous anti-fraud algorithm.” I probably spent around 60 hours in totally trying to get my account restored.
After getting access back I stopped using that account and made sure to distribute access to different accounts and emails. Using a single Google account is just way too risky. The more services you use the more likely you are to encounter an account suspending issue. I’ve heard of many cases where people get hacked and Google’s response is to ban the victim permanently. Facebook has similarly atrocious policies.
The thing is, for every Google service you really should have a separate account. One for dev, one for YouTube, one for Gmail, one for Wallet. Maybe one for Chrome if you use it as a password manager. One for AdWords. One for payments if you use any merchant services.
Every service you add to an account increases your odds of suspension. Oddly, I’ve also heard that one of the reasons guy can get banned is for having multiple accounts. So I’m not sure if my new policy is any better than my old one.
- They do not let you use any other client -- that's a bummer but let's say I can live with that
- But the real bugger is - while they allow catch-all, they (actually their clients because you can't use something like Apple Mail, or Thunderbird) do not allow sending email from "any" email address even on your own domain, which is the mandatory compliment to catch-all, and without it catch-all is half useless.
Note: Though I have never quite understood their reasoning for not allowing you to use other clients -- the mails to other domains/providers anyway go unencrypted and just like any other email in the world. This is a weird kind of walled garden.
The point was one might not want to go to Tutanota in the first place and rather go to another provider instead of going to another provider after a switch.
One practical way is to buy your own domain and set up a Google Business account for it. It includes email. So if anything happens, you will still be able to at least transfer the email to another provider.
That’s why the risk of storing passkeys with Google is so great. Your account gets hacked, someone removes all your devices and then the account gets banned. You stand to lose access to hundreds of linked services.
However gsuite does not protect you from bans , google will just as likely ban the entire tenant for infractions by a single user
I'm sure it does, but "if anything happens, you will still be able to at least transfer the email to another provider" doesn't apply since you can't "transfer {YouTube,money in Wallet,password from sync,etc} to another provider" in the same way as email. These things are more than just an address you can point to something else.
Google does allow your data to be exported[1] including YT videos and most of other things in your account in a non-proprietary[2] format, in addition the APIs from Google are fairly deep to extract a ton of information from your account
It is not their problem that other services do not always support imports from Google even when such peers exist.
Google is no means a saint, or supporter of open formats or of easy export formats, but for a company they do a reasonable job for a feature designed for people leaving their ecosystem
[1] https://support.google.com/accounts/answer/3024190?hl=en
[2] Non-proprietary to them, even if not fully open i.e. MP4 or DOCX instead of only supporting WEBM or ODT
[3] Used by regular users, not sysadmins i.e. DNS / Certificates by CAs et al. do not count
It is bonkers we treat SaaS as always available and that data will never be lost forever[1]
Big Co may not loose data in the abstract sense, but it can be still lost to us, not just of suspended accounts, it could be access is now restricted by new pricing tiers, or because Big Co have decided you are no longer active and deleted your data or myriad other reasons.
Always take backups .
[1] it shouldn't matter if it is paid or free service either. There is always things in the ToS that allows Big Co to do what they want without notice.
That said, I think the big issue here is not so much about data and exports, but rather that Google occupies a fairly central space in the internet. If you want to make money developing mobile applications then Android – and thus a Google account – is kind of required; there's been plenty of "I have a business selling Android apps and it was taken away from one day to the next with no explanation". The same applies to YouTube: you can make money posting videos on the internet with out it, but it's a lot harder.
One practical way is to, you know, not rely on any Google account at all.
The only Google app/service I have not been able to find an alternative for is Google Maps so I use that without logging in (no, in my geographic location there is no option - Apple Maps is worse than pathetic here and OSM apps are fancy things to install and uninstall once in a while).
For me personally, the small loss is acceptable. I know that it's going to take me maybe a day to set up everything on another provider.
Google had a recent blog post about it, but the push started with Apple at WWDC22 (and one session at WWDC21), to the point some assumed it was an Apple-only feature. An effort like this requires coordination from major players to take off with the impact they want (replacing passwords).
https://www.theverge.com/2022/8/5/23293643/apple-passkeys-fi...
1Password has been tracking services which support passkeys, and so far adoption seems slow. I’ve been checking their website on and off for months and it has hovered at about the same number of websites, occasionally going down.
I'm not defending passkeys but you people need to pick a side to shill for.
The flip side here is that Apple gives a user near zero power in their walled garden, and is hostile towards anyone outside of it. So Apple passkeys can't take away user control because they never had any.
And I have no doubt that he believes it and intends to implement it. But that's not a guarantee that the corporation around him won't decide tomorrow that they don't want to implement it.
It’s a statement from the Engineering Manager of the “Authentication Experience” team. Ricky’s not a random unknown Apple developer, they’re someone with knowledge and authority on these matters. And as far as I know they’ve been reliable regarding what they share publicly.
> you people need to pick a side to shill for.
This type of rhetoric is unnecessarily divisive, though. Attacking people isn’t an effective way of changing their mind or making them reconsider their point. Quite the contrary, it only makes them clam up.
I do disagree ignoring them is the best. This gives them an echo chamber here and can others can get the impression they are always right. The attack was not helpful as you said. I'll try to do better in the future.
From my experience and observation, the people who hate on specific groups are more set in their ways than the people hated on.
The preconception that someone is a shill and won’t change their mind does more harm to the conversation than what the other person believes. It is impossible to change someone’s mind if you start from the assumption that it won’t happen.
Case in point: this very thread. It seemed like the person I replied to was angry and set in their ways, but they took stock of what was said, apologised, and vowed to do better. That is a positive outcome for everyone and all it took was to not lash out in return and a belief that everyone can have a bad day.
Isn't this entirely orthogonal to the usage of passkeys? You could "lose your digital life" if you forgot your password, or remembered your password but tripped their risk scoring system (eg. fresh login from an unusual location).
In terms of key, it's either stored at the OS/browser level (Windows Hello), or at the hardware level (Yubikey). Imagine them as if there were SSH key files; You hold the private key(s), protected by a PIN/password and Google simply has the public key(s) to authenticate you.
Even if Google disabled the account, it still doesn't block you from using other stored Passkeys that are tied to other providers. The only place where you'd get in trouble is if these third-parties like the DMV used Google as their SSO.
"Orthogonal" - the better word for most circumstances unrelated to math is "unrelated". Depending on the situation, "has nothing to do with" works pretty well too.
And to the GP: Since passkeys (and passwords, and etcetera) are related to some extent to one's "digital life", then they cannot be "entirely orthogonal".
To really, really nitpick, even in math, orthogonality does not imply unrelatedness. Two objects being orthogonal to each other means that they both are related to the extent they belong to the same coordinate system.
I guess, by my standards then, using the phrasing "entirely orthogonal" indicates that you believe that the two things are related to the extent they belong to the same coordinate system, but never meet.
I don't like this usage because it seems that "digital life" embodies the entire coordinate system in which "passkeys" exist. Nothing is "orthogonal" to its coordinate system, at most it's orthogonal to an axis in that coordinate system.
I'm kind of tired of this nitpicking myself, though. Please don't borrow nomenclature from other fields when already existing nomenclature (or better yet, colloquial terms) work just fine. Thanks.
> >Lose your (google) passkeys account for whatever reason (ai says no, wrongthink, itar ban), and you risk losing your digital life.
> Isn't this entirely orthogonal to the usage of passkeys? You could "lose your digital life" if you forgot your password, or remembered your password but tripped their risk scoring system (eg. fresh login from an unusual location).
So the person they responded to was saying that loss of (centrally coordinated) passkeys means potential loss of all digital life.
They are responding that a loss of (centrally coordinated) digital life can happen for a variety of other reasons unrelated to passkeys.
The first person is narrowly concerned with central coordination of a particular passkey system, and the second person is saying that if "loss of one's digital life" is the primary concern, then they should instead be concerned with broader central coordination and verification. In essence, their criticism is that cause and effect are being reversed, or at least mistaken.
I dropped out of school in the middle of taking linear algebra, so you know more about math than I do. Maybe orthogonal was appropriate here, but I'm still going to push back against its colloquial use in most situations.
A better way to put the concern is the use of a passkey and access to digital life accounts should be independent, but the concern is in practice they could become entangled.
If you lose your driving license, but still have your passport things are easy.
What if you lose your passport, driving license, birth certificate and all other forms of ID? It's like that bad.
I did, but are they vaporware? Website has not been updated with Solo 2 information, but there's a Kickstarter that claims I can still buy early bird keys that will ship almost 2 years ago? Their github repos haven't had meaningful activity in well over a year: https://github.com/solokeys/
If only this passkey thing was a Fido standard that could be used with the product you linked us!
Now I carefully ensure that I am not depending on Apple/iCloud for anything either, because honestly that is just like Google and even though you can reach a human being at Apple, their support (at least in India) seems to be trained to perfection in stone-walling you and denying you even an escalation.
So no, I hope this passkey thing is optional or there are third party players (Mozilla?, BitWarden? etc) in this play. And I hope there will always be a recovery option that will be just user's and not with with the passkey provider "by design".
But knowing Apple and Google I think they will make it infinitely harder for any third party to become an option on their devices or platform that there won't really be a competition. It would be worse than the case where "iOS has alternative browsers, but not really". I somehow have a bad feeling about this passkey thing unless third party providers get to become, by explicit user permission and setup, A first class citizen of passkey on. a device.
I'm not keen on handing my identity over to a third-party to manage. And I share the concerns of the commenter up-thread that TLA agencies have fingers in this pie; if they don't, then they're not doing their jobs.
I had a go at implementing oAuth and self-hosting it; but part of the problem with (some of) these open protocols is that people with much more time on their hands than you, and with membership on the specification committees, start messing with the protocols and making them much more complicated. That happened to CalDAV - I wrote a CalDAV server, but it was obsolete as soon as it was finished, because the specs had already moved on.
I own several myself.
Because passkeys have had a lot of support from the megacorps like Google/Apple, people can obviously get the impression that passkeys are just about locked-down ecosystems, but that isn't true at all. From a technological standpoint, passkeys are just as versatile as passwords and IMO will eventually be just as widespread.
I don't need special software to authenticate with a password, and passwords can be used to authenticate on very low-grunt devices. So not quite as versatile.
I'm not arguing against passkeys at all, but passwords are much more versatile and convenient than them, albeit at the cost of being more difficult to use securely.
The UX is basically the same: as a user, let the browser deal with it. Let the browser's password manager/keychain restore/backup/sync it.
The overall security is higher (higher entropy, public-key cryptography).
The DX for building that website is a little more complex, but not arduously more complex (especially for any website already previously supporting FIDO and WebAuthn standards for 2FA).
If the website is compromised it doesn't matter either way since that password is not shared with any other site.
And the UX doesn't seem to be the same at all. For one, according to comments in this very thread, Google and Apple aren't making these portable or user-backupable.
On top of that, to log in from a new device, with a password I just need to get it from the password manager and enter i t on the new device. I can copy the entire password store to the new device, and immediately be sure that I can access any and all accounts.
Unless I'm grossly misunderstanding, that's not possible with passkeys, or at least not in the Google and Apple implementations? I would have to generate a new passkey on the new device, then enroll it with the website, and I would have to do that separately for each individual website/account? Not to mention, both devices have to be online at the same time? That's completely unworkable.
Admittedly, using "entropy" as the word here is bordering on an analogy break. "A picture is worth a thousand words": "a private key is worth a thousand characters of a password". It greatly increases the information complexity needed to just "brute force guess", as a rough off hand we call that "entropy" but what a Password Manager shows for estimated "password entropy" isn't a directly comparable "metric" to private key entropy (other than assuming that a private key is an order of magnitude "jump").
> If the website is compromised it doesn't matter either way since that password is not shared with any other site.
It still matters to using that specific site. If a website is breached and they get your password to that site, they can immediately use your password on that site. The potential damage is limited in theory to just the one site (and only limited in theory, not in practice, because in practice many social engineering attacks start with just a single site breach and spread), but the potential damage is still real. Whereas if they get a public key a website is using for authentication they might be able to encrypt some nastygrams that only your private key can read, but they can't actually authenticate anywhere with just a public key, not even the site they stole the public key from.
> And the UX doesn't seem to be the same at all. For one, according to comments in this very thread, Google and Apple aren't making these portable or user-backupable.
There's a lot of different definitions flying around for what constitutes "portable" and "user-backupable". There's also a lot of promised interoperability tools that haven't yet materialized and will answer some of these questions.
In terms of "average user UX" though, it is very comparable: on Apple devices if you use iCloud Keychain as your password manager, Apple's passkey implementation syncs the exact same (E2E) way and is not much different from "browser generated" passwords in Safari today. (Google's is similar but swap Apple names for things and E2E is "optional" for some dumb reason. Microsoft's is similar but swap OneDrive for iCloud and use more interop with iOS and Android phones.)
> Unless I'm grossly misunderstanding, that's not possible with passkeys, or at least not in the Google and Apple implementations? I would have to generate a new passkey on the new device, then enroll it with the website, and I would have to do that separately for each individual website/account? Not to mention, both devices have to be online at the same time? That's completely unworkable.
It sounds like you misunderstand how passkeys work. In general in the Apple implementation (which I have slightly more direct experience with) passkeys are built and stored like passwords in the iCloud Keychain. They sync with E2E-encrypted keys that are device-specific, but you enroll an Apple device once while two devices are online together (unless you have a much more desperate and harder recovery scenario) and once enrolled both devices have full offline access to all synchronized passkeys in exactly the same way they have access to all synchronized passwords in the same "Password Manager". (Think of it as a hierarchy with a few device-specific keys as the foundation being used to transfer lots more non-device-specific, but less powerful and website-specific keys to be used as passkeys.)
There are small exceptions that do make this easy to misunderstand/confuse: if a website "needs" an attestation similar to previous 2FA it may need something signed by a device-specific key in some situations. That should be much more rare in practice than the more password-like sort of passkey. That's also where more of the key operations want both devices online and talking via Bluetooth LTE personal area network. It's a 2FA operation trying to test that you have current access to a specific device. It shouldn't be something used for 95% of logins in the future once Passkeys are more stable.
(It is used a bunch right now for bootstrapping synchronization tools and cross-platform needs. Using iOS keys on Windows, for instance. Some of that is just waiting on some of the cross-provider interop features planned but not yet ready. Microsoft's efforts which are still somewhat behind Apple and Google are expected to be very much the "glue provider" as they will absolutely need to support both Apple and Google interop in Windows.)
Duh, obviously. Sorry about that stupid statement. Yes, public keys are more secure. However, that doesn't matter, because:
> use iCloud Keychain as your password manager
This is exactly the thing that is a total non-starter. A proprietary, closed-source third-party service that can go offline at any time? I would maybe trust that with my hackernews login and that's about it. Not even reddit.
> once while two devices are online together
This is also still a non-starter. What happens when you are traveling with only one device, and lose or break it? I simply buy a new phone, go get the USB drive with all my passwords on it from the hotel safe, connect it to the phone, and I'm back in business. What do you do with passkeys?
There will be open-source options eventually. Certainly, the wheels are spinning among some of the HN sorts that think about such things. Apple and Google (and Microsoft) have a head start because they have to coalition build on these standards to make them work, but it is all still based on standards (all of FIDO2, WebAuthn).
But in the context of "just save the randomly generated password in your browser's password manager", the big 3 cover the majority of average users' browsers, so the UX should in theory be simple for the average user, not just the technically proficient user (nor the "I only trust open source" user).
Firefox is, of course, working on their passkey tools as well.
> What happens when you are traveling with only one device, and lose or break it?
The same recovery process that happens for your primary account on the device, your Apple iCloud account or Google Account. That part isn't changing in all of this. Those are closed source so whatever details for how they already today escrow recovery keys for scenarios like that where no other device is available to bootstrap recovery from. Though once bootstrapped from a recovery state, all the passkeys should flow to the new device just as all the passwords in the password manager and you are back in business.
Recommending owning at least two Apple devices connected to your account is already common security recommendation going back several years now because of Apple's E2E guarantees when you do so. That's not new guidance unique to their passkeys implementation, but also a cornerstone of existing Apple ecosystem security.
Technically correct (the best kind of correct!), but in my recent experience with 4 different password managers[1], there are some pretty big catches:
It’s incredibly time consuming and error-prone to init and use good passwords correctly and to maintain them without any password manager, aka “special software” with deep hooks in your OSs and browsers that allow it to fill and save passwords efficiently.
And it’s nearly as bad to do so if you don’t have a cross-platform one unless you’re all in on a single narrow ecosystem like Apple. Suddenly I would be on a different platform and I’m like, using telegram to shoot myself messages with passwords from my phone. And don’t forget the absurd password ‘rules’ (sorry, “/“ is not on our list of 5 ‘special characters’) that are differently-misguided on every site. This is a huge blow to “passwords are convenient.”
And even if you do have one that’s cross-platform my experience recently has confirmed that if you’re not using the OS vendor’s own solution, you’re guaranteed a buggy, unreliable, slow, second-class experience on Apple devices because they don’t allow anyone else to work as efficiently, probably for some combination of “security” and “battery life” reasons. Similarly, even first party password managers are laggy or fail to trigger correctly in about 1/3 of “Apps” (they work fine on websites)
This means with passwords I’m left completely without a solution already since I’m sure as hell: 1. Not using Safari. 2. Not limiting myself to Apple only. So I have to pick a 3rd party solution with its buggy trade offs.
Anyway, if passkeys are implemented universally, at least I could ditch password managers and just have 1 passkey each in the Apple and a cross-platform storage location, and never have to deal with updating them.
[1]: I tried, in order: iCloud (omg what a horrendous b—-h to “export” from!), Dashlane, 1Password, Microsoft.
I tried to add a FIDO2 key to Google's passkey page and failed already, so it doesn't seem entirely compatible out of the box.
I am surprised that the FIDO2 key doesn't work on Google, but it probably just means that there is a bug somewhere in the implementation.
FIDO marketing materials talk about passkeys in the same way you do, a resident key (now called discoverable credentials). Some other materials say that passkey with no other qualifier is a multi-device passkey, meaning it's backed up by a sync fabric. (e.g. the short version here https://passkeys.dev/docs/reference/terms/#passkey). Others, like Google did in their blogpost last week and the long version of that link, say that a passkey is a multi-device passkey that also has user verification (so it can be used for passwordless and not just 2FA/2SV).
The default U2F/FIDO2 model was to use a single secret on the token, and deterministically generate a public-private keypair as required. At registration the token provided some opaque bytes to the website, and the website must supply those bytes back to the token when trying to authenticate.
Registration:
1. Token generates random seed
2. Token calculates public/private keypair by combining seed with global secret
3. Token signs registration request using private key
4. Token returns seed, public key, and registration request to server
5. Server stores seed and public key in user's database entry
Authentication:
1. User provides username
2. Server looks up user's seed and public key in user database
3. Server provides seed to token
4. Token calculates public/private keypair by combining seed with global secret
5. Token signs authentication request using private key
6. Token returns signed authentication request to server
7. Server validates authentication request against stored public key, and user is now authenticated
The biggest benefit of this is that the token is quite trivial to create as there is no need to store a per-website secret on it. One secret can be securely used to authenticate with an infinite number of websites without any security or privacy risks.
Passkeys use resident keys. This basically means that the seed is not stored on the server, but on the token. The biggest benefit of this is that you can also get rid of the username in the authentication process.
Registration:
1. Token generates public/private keypair
2. Token signs registration request (which includes unique token identifier) using private key
3. Token stores private key, together with website URL
4. Token returns public key, and registration request to server
5. Server stores public key and unique token identifier in user's database entry
Authentication:
1. Token looks up public/private keypair using website URL
2. Token signs authentication request
3. Token returns authentication request and unique token identifier to server
4. Server looks up user's entry in user database by unique token identifier
5. Server validates authentication request against stored public key, and user is now authenticated
And before you ask: no, I have no idea how this is supposed to work if you have multiple accounts on the same website either.
If you've got multiple accounts on a site, each with different credentials, you have to have some way to select which of your accounts you want to use.
Specifying the UI that clients should use for letting you specify that is entirely a client issue, so seems out of scope for the Passkeys specification.
Most hardware tokens don't support discoverable credentials.
When I use a non-proprietary passkeys implementation, it is essentially just a file on my harddrive, just like my KeePass database containing my passwords is. It is still a huge single-point-of-failure, and unlike proper MFA should not be treated as if it provides any additional security.
Switching to passkeys is a downgrade from password+2FA token and should be treated as such.
If the only attack vector is someone having to crack into your encrypted hard drive, and then decrypt whatever stores the passkeys… that’s still both pretty strong and also probably not the biggest security issue most people face.
The biggest issues most non-tech people face are 1. reusing simple passwords, and 2. getting phished through similar UIs/emails. It’d be much better for most people to use passkeys.
Whether it's a downgrade or not depends on your specific threat model, and whether it's a downgrade for you or for the userbase at large.
In comparison with a password manger managed password +2FA , just software passkeys are a downgrade.
Whether it is acceptable downgrade can depend on your threat model, the fact that it downgrade or not is not
I'll restate in case I wasn't clear -- the fact that it's wrapped addresses the "just a file"; meaning it's not sufficient to attack the filesystem to steal it, just like a password manager vault is.
As for how it's not a downgrade (or upgrade, mind you), it's domain-bound using standard browser APIs, meaning it's less likely than the comparable autofill used by a password manager to not leak passwords to the wrong site (LastPass suffered this issue in the past, for example). It prevents reuse across sites, it's not vulnerable to a man-in-the-middle in the same way a password or TOTP secret is, and guarantees strong assymetric crypto as opposed to whatever a server decides to do with a password and a secret. Additionally, and especially when compared to password managers, most of them now offer to also store and autofill TOTP secrets leaving us in the same spot were at with virtual authenticator backed passkeys, but with worse cryptography.
Instead, with all these password manager vendors not wanting to be left out, and a good portion of the userbase either not being entirely in a single vendor's ecosystem and not wanting to deal with the hassle of QR codes and registering each fabric in each RP, or simply distrusting the big vendors like we see here in this thread, I can see cross-platform virtual authenticators like the one you're working on becoming more common, and I don't think it's unlikely that the OSs will offer APIs to back these keys with TPMs/Secure Enclaves, and will allow you to replacethe built-in passkey manager with a third-party, much like they do with password managers today.
If software-based authenticators want to support import/export capabilities, they don't quite need an open standard, in the same way there isn't one for passwords but you can import/export passwords with any major password manager.
In my ideal scenario, users would be able to use software passkeys for most websites, and then have hardware authenticators either for the vault of software passkeys or directly for a few key websites.
What I'd like to see password manager vendors like you do, though, is to push FIDO and the OS vendors to have richer APIs for interacting with the hardware components that can back keys. To be clear, I don't want to use Bulwark to manage or export passkeys in my iCloud Keychain (I'm confident that will never happen), but I want Bulwark to be able to create a passkey that is backed by a secure element in Mac OS, and then be able request a wrapped version of that key to be exported, and later imported into a TPM running on a Windows OS.
It seems like you know more about this space than I do, so maybe you can explain it to me. What incentive do players like Apple and Google have to allow this to happen? Don't all of their incentives point to eventually requiring attestation from trusted hardware devices and increasing lockin?
For what it is worth, Apple has recently stated that they don't see a lot of day-to-day need for hardware-attested keys and their Passkeys implementation is working to avoid them in most cases in practice, in large part especially due to that user experience of preferring comfort and recoverability over lock-in.
[0] https://news.ycombinator.com/item?id=35851476
I assume I'll use 1Password's implementation they're building, which should meet all my needs, provided they provide a mechanism to export (which I expect).
And I also assume a similar open-source solution will arise.
So I'm not worried about a loss of user control at all. As long as iOS, Chrome, Safari, and Android all allow integration with third-party passkey managers. And I don't see how that wouldn't happen.
What is essential is the ability to have multiple credentials associated with an account. Possibly so you have redundant Yubikeys, but also to have an Apple and a Google passkey so you are not locked out if your phone is lost (thanks to Apple's brain-dead decision to allow phone + passcode to reset the recovery key) or if Google decides to close your account on a whim.
Since not every website will let you do that, even though they should, it's of paramount importance that passkeys can be cloned.
Some like Apple actually require a minimum of two FIDO keys before allowing you to turn on hardware key-based 2FA.
The big providers could provide cross company SSO (e.g. sign onto my google mail account w/ my apple identity) for all their accounts already, but for some reason that hasn't happened...
Also, considering that there are already multiple software vendors providing passkey hosting functionality, it seems a little late to start designing the "cross-device, and across passkey managers" part of this. If it's not in the standard already, what assurance does a user have that any of these third-party entities will implement it?
It sounds like maybe I can achieve that, but not with any of the standard implementations.
> But it's unclear if supporting passkeys actually requires services to support more than one public key associated with an account.
Present best practice for WebAuthn is to always support an arbitrary number of public keys associated with an account. That shouldn't change with Passkeys and some present passkeys implementations are allowed to present an arbitrary number of public keys at enrollment time.
> A properly secure system would have a mode that made sync impossible, you would have to generate a unique and hardware-secure passkey for each device.
You should be able to do that in theory. It's obviously going to be harder to operate and maintain than a system involving synced keys and yes it may be too soon to have a good idea of what sort of practical obstacles might exist.
How Keys are different than an OTP app like Authy?
Every device (except accessories like AppleTV, HomePod, etc.) you log into iCloud with effectively has Super Admin control over your entire iCloud account. Any logged-in device can remove, modify, or change (almost) anything without a password… including the account password (hence the almost). Once authorized, that access is controlled by biometrics with a backup PIN. As long as you maintain control of a single device you have access to everything.
Yubikeys work the same way. Doubly so when dealing with resident credentials and passkeys. Key as as many as possible—just make sure the PIN is not obvious. If you hold the key and know the PIN, you can do anything. No other information is needed.
The big difference between this and OTP is two fold: 1) much more resistant against phishing; and 2) the underlying key is less likely (or impossible-ish) to be exposed. Phishing a 2FA OTP is actually not hard with a good fake UI. It just requires someone to act quickly on the other end or a good script that can quickly change the password/security settings once a password and OTP are successfully phished.
If Google decides you have Done A Bad, suddenly you can't login to anything, anywhere.
An offline backup I can control, I can put in a safe for my relatives in case I die unexpectedly. Or I am robbed. Or any number of foreseeable circumstances where the physical manifestation of my secret is lost.
But for me, the online-backup provides enough redundancy. In order to be locked out, I'd have to loose all my devices and, at the same time, be banned by my cloud provider.
[1] at least that's what the Safari-UI suggests.
[0]:https://blog.millerti.me/2021/06/18/previewing-chromes-cable...
One thing that concerns me is that if passkeys gain acceptance, certification requirements could be used to block open source/self hosted implementations.
yes: https://developers.yubico.com/U2F/Attestation_and_Metadata/
See https://fidoalliance.org/specs/fido-v2.0-ps-20150904/fido-ke... for the FIDO2 attestation specs.
It’d be a great way to monetize gmail after AI ruins their search business.
Computers are annoying and so people will always tend to trade freedom and autonomy for convenience. But if you do that, realize that once you are locked in that relationship will either be directly monetized or (often worse) abused for surveillance. A certain amount of inconvenience is probably going to always be the cost of privacy and actually owning your data.
An even shadier thing OIDC providers could do is start logging into user services as the user to spider them for surveillance data. I’m sure the terms of service allow that. The ToS always allows everything, especially for anything free.
Im curious to see if this reaches mass adoption.
If you choose to use Google's passkey then you're taking quite the leap of confidence, but you don't have to pick between Apple and Google. We just need to wait a bit longer until passkeys are more widely supported.
> Passkeys will be importable and exportable, cross-device, and across passkey managers. They aren’t at this time, but they will be. It’s something that’s being defined and designed.
My password manager of choice is open source, and cross-platform, and can export and later (or elsewhere) import an encrypted backup.
It’s a passkey-first authentication solution for websites and mobile apps.
Personally, I will never use them until apple and gooqgle can explain what the implications are across all their services and all my devices.
For example, say I switch to passkeys for my Google login. How do I login to YouTube on my Roku device?
If I buy into apple passkeys how do I log in to apple music on android?
The answer to the above will always be via passwords.
Personally I want one passkey for Google and one for apple on my yubikey and that's it and password backup for limited devices with password backup for login.
The author is correct that requiring the cloud is asking for tons of trouble, but people that say they have to dig yubikeys out of a drawer are not yubikey users. Yubikey users attach them to Keychains or wallets because they ACTUALLY use them and keep backups of them.
Personally, I think Apple's 2 factor is a joke and likely dangerous. I dont trust Google to not screw up passkeys either.
The passkey does not have to be on the same device. It can be, but does not have to be. The Roku can display a QR code, and a passkey on a phone can perform the login. I logged into google on my windows laptop yesterday with a passkey on my iPhone. A prompt in chrome appeared basically asking “is your passkey on this laptop, or on a phone” and then displayed a code after I picked phone.
I hope eventually one of the major password managers implements Passkey support. I have Vaultwarden on all of my devices; I’d ideally love for Vaultwarden to store my passkey(s). It wouldn’t be any different from how I login currently, but with fewer passwords. There really isn’t much reason to stay locked into Apple or Google as far as I can tell.
If so, I'm open minded. If it's a situation where you have to be in some kind if in-group to do that, then I'm preparing to be as much of a Luddite as I need to in order to avoid them.
However, the implementation also supports attestation, which means a website is able to only allow certain "trusted" passkey implementations.
I should just give up and live in a shack in the woods. The entire industry is hell-bent on subjugating me to one of the big-tech fiefdoms.
I don’t want that “security”, personally. I would love to not do business with anyone who requires that of me. Unfortunately, I think that will increasingly force disconnection from society.
I'm reminded of a sign in front of my neighbor's driveway: "Ford parking only"
Le sigh.
Good. Biometrics (“something you are”) aren’t a second factor.
FIDO is flexible enough to distinguish userPresence (I.e., touching the key) from userVerification (commonly, entering a PIN), but this is only defined for physical keys IIRC.
This should make us wary. Google and Apple have a long history of vendor lock-in and “was compatible until our position was strong enough”.
Passkeys itself are SSH-Keys for normal users. A good thing as long as you have them stored safely and a login/password to access them.
This is clearly misunderstanding the point of a hardware security key. If I can reduce the number of people that can hack you to the people who can access a single, uncloneable, physical object, is that not greatly increasing your security? It is the "Something you have" part of security.
In my case, no.
You need the choice.
The two cases seen entirely different to me. I think that in most cases a single SSH keypair is fine. Some discussion of the question here:
* https://security.stackexchange.com/questions/40050/best-prac...
>On the other hand, passkeys are always associated with a single web service, never with multiple services, so that's an improvement in security over ssh keys and passwords.
Is it? I suppose that would be true if you didn't want the various services you use to know you were the same entity. That's more of an anonymity issue.
Then why does the passkey scheme even bother with public key cryptography? Why not just generate random passwords for each site and store those? This seems to be logically equivalent to a password manager.
That approach is susceptible to a man-in-the-middle attack. FIDO isn't.
(If you believe you personally are impervious to social engineering, imagine how many other people would respond in this situation: https://www.mercurynews.com/2023/04/27/larry-magid-how-i-nea....)
The big reason is phishing. If I can convince you that my site is the login page for something else, I can login as you – and if I’m clever, get you logged in as well or present some temporary error page before redirecting you to the real login page so you don’t even realize I’ve done that. Weaker forms of MFA like TOTP, SMS, app push notifications, etc. are vulnerable to that since you’re expecting a prompt. Because WebAuthn uses the hostname in the setup process, there’s no way to phish someone and keeping the private key locked down also prevents someone from even trying from another device.
Wouldn't TLS prevent that?
FIDO2/WebAuthn prevent the more common phishing attack where I register a different host name, get a valid HTTPS certificate, etc. for a different hostname like gooogle.com and try to convince you to enter your real Google password there. These attacks are relatively easy to run since they don’t require any successful compromises to launch and things like URL shorteners and link trackers, not to mention corporate rebranding and outsourced marketing, have trained most people to see weird links as normal.
Here’s a sample flow for that:
1. I setup gooogle.com and make it look like a real Google login page. 2. I send you a link, perhaps obscured, which takes you to my fake login page. 3. When you enter your password, my code starts a real Google login session. 4. When you’re prompted for TOTP or SMS MFA, my code submits those values to Google and now I have a valid session. 5. My code returns some kind of temporary error and sends you to the real login page. 99% of users are used to stuff breaking every so often and since your second login attempt will work just fine, almost nobody questions this.
There are various things you can do to make those attacks harder such as MFA systems warning users about where the logins are geolocated but those are unreliable and attackers can often foil them by e.g. using a botnet node or compromised cloud server in the same region. The WebAuthn protocol makes this attack completely impossible so it’s not just faster and easier but absolutely more secure.