Exactly. I don't doubt that there are a lot of well-meaning techies inside the big companies who get how this works and want to do the right thing by most people; but the loss of control here is unacceptable.
Google’s implementation allows multiple passkeys. I have a passkey for my iPhone, one from Windows Hello, and 3 from different yubikeys I’ve picked up over the years. The yubikey implementation requires setting a PIN, so I’m not even really worried about one of them being lost of stolen.
The Apple security model for Apple ID and iCloud already works like this. Every device is effectively a “passkey” even if they don’t call it that. Been that way for a while now.
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.
What's wrong with an online backup? Offline backups are tied to their physical representation and can get lost in disasters for example. Spread your risk.
Online backup stuck inside Google's walls is the opposite of spreading my risk.
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.
AFAIK, you can use a physical key anywhere you can use a passkey [1]. And you can register multiple passkeys. So it would be perfectly possible to have your logins in a safe somewhere while having additional passkeys for daily use.
You just need create the backup manually for each account provider. You can't extract all your passkeys from a device.
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.
TOTP written down does work well, but the parent and I are both interested in how we should write down (on paper, like by printing) the various secrets necessary to reconstruct our passkeys in an emergency. Once that's known, I'll gladly adopt passkeys.
A lot of people in the world only have one primary digital device - a phone. If that phone breaks, or is lost or stolen, how do those users get back access to their keys? Will the store holders like Google and Apple validate their identity w/ personal information frequently stolen from credit agencies and healthcare industry data stores?
Its also worth pointing out that google, the company making the big passkey push, has a track record of just disabling accounts they don't like for any arbitrary algorithmic reason.
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.
You really want to learn how this technology works before spreading FUD which will cause people to pick less secure options. Passkeys are a W3C standard and they’re not an SSO system which requires a third-party server to function.
If Google closed operations tomorrow, it wouldn’t affect anyone using a passkey to login to any service other than Google’s own.
If I use passkeys right now, with Google or Apple, and they close up shop tomorrow, I'm screwed.
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.
> If I use passkeys right now, with Google or Apple, and they close up shop tomorrow, I'm screwed.
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.
This is pretending that, as others have noted, Google haven't made a habit of locking out accounts for no reason and providing no path to recovery.
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".
> This is pretending that, as others have noted, Google haven't made a habit of locking out accounts for no reason and providing no path to recovery
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.
And when it happens to you, Google will let you know that they reserve the terminate your account for any reason or no reason at all. You will get the same email response over and over again:
“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.
It’s very easy to become complacent. I knew forever that using Google was a risk. I keep email mostly on owned domains… but I also use all sorts of Google services.
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.
> And when it happens to you, Google will let you know that they reserve the terminate your account for any reason or no reason at all.
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 just email though. Won’t get your YouTube account back. Or documents in Drive. Or money in Wallet. Or passwords from Chrome sync. Or access to a Google Voice number. There are so many Google services and products you may rely on, and often times they have become part of larger processes you have no control over whether you use or not.
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.
> Gsuite account includes YouTube and most other google services.
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.
Email (and calendar) being cross compatible is accident of history and pretty unique. No other popular service[3] uses a common shared and accepted protocol
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
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.
Sure; I agree that Google is actually pretty good in this regard; I was just commenting on the fact that your previous comment didn't really connect with what the previous person was talking about.
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.
Another benefit is salespeople can often be helpful with things like this, especially if you convince them that you plan on upgrading your account but you need your account to get fixed ASAP.
The practical way is to stay the fuck away from Google - completely. At least for me it didn't take an effort.
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).
How much effort is it to even keep the accounts separate? They've never seemed to have much trouble linking my accounts together, even when (say) one was only used on a personal computer at home, and another on a work computer at the office.
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).
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.
We had apple passkey posts over the last few months with people salivating over it but suddenly they hear google and suddenly the feature is evil from the start.
I'm not defending passkeys but you people need to pick a side to shill for.
Indeed, Apple's passkeys are the in the field of heroic security while Google's is an evil play to take away users power.
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.
That's not a statement from Apple. That's a statement from an Apple developer.
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.
Unless it's an official "Apple" statement (and not an employee saying it somewhere, maybe not even Cook) and part of the official documentation and actually implemented (so that in what shape and form Apple has actually implemented it and whether it is of any practical use at all or not) unfortunately that is just a random statement. That's Apple.
I think you’re replying to the wrong comment. My point was neither pro nor against Apple, Google, or passkeys.
> 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.
The parent comment is in bad taste (and it's indeed weird it was a reply to your comment, seems out of place) but from my experience and observation I have noticed that Apple shills/fanboys, especially, do not really change their views. I assume something get hardwired into them. But even then the best way is probably to just ignore and not attack them.
You are both right, it was a childish comment that I can no longer edit. Sorry.
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.
> but from my experience and observation I have noticed that Apple shills/fanboys, especially, do not really change their views.
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.
>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).
You could consider it orthogonal before, but would a passkey store accumulate of many more critical accounts could be attached to that google/apple account. So a mistriggered security or regulatory function could cut off access to the account, followed by being cut off from your bank or other accounts wrapped up on that same passkey store?
> So a mistriggered security or regulatory function could cut off access to the account, followed by being cut off from your bank or other accounts wrapped up on that same passkey store?
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.
Just a pet peeve of mine directed at you and the GP.
"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.
Having worked with non-orthogonal coordinate systems, the use seems fine with me. “Straight line” movement along an orthogonal dimension usually induces a change in multiple non-orthogonal coordinates. So colloquial use of saying something isn’t orthogonal seems like a reasonable way of saying things are coupled in a way that doesn’t allow free change in one direction without dragging along other changes.
I didn't get that intent from what the original user of orthogonal posted. Maybe I just didn't understand what they posted.
> >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.
Orthogonal vs non-orthogonal is specialized jargon. And discussion should try to stay accessible and prefer a more widely understood term if a specialized term really isn’t offering any advantage in the discussion. So I’d agree with you on that.
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.
A lost phone can be replaced. Once the Google Account is gone, all your digital stuff in there is gone too. Do you want to lose 10+ years of Email, Docs, Photos. With no way to recover? It's not the password or the passkey - it's the whole bloody account.
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.
> Edit: If you need MFA please do check out solokey, an open source Fido project.
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/
Hmm, I don’t know the current status but I did receive and use my keys I got from backing. I have also gotten mails about firmware updates, but nothing recently.
I had to put a huge amount of effort to move away from Google - actually Google nuked the amount and I never knew why (I had no connections at Google, so that didn't work out). So I anyway do not use Google at all.
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.
> unless third party providers get to become, by explicit user permission and setup, A first class citizen
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.
The title and article don't really match (not an HN problem). The subject matter should be about passkeys, but this is almost entirely about Apple's implementation and forced iCloud aspect.
I agree. Of course the concept of passwords needs an overhaul, but there needs to be some open solution and not some silo’ed approach where a couple of large corps can exert control.
The standard allows any company to provide passkeys or to host your own. KeepassXC already has a pull request open, I believe.
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.
From Ricky Mondello, who works on password-related stuff at Apple:
> 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.
2FA is rife with problems. FIDO2/WebAuthn isn't tied to biometrics and can be inconvenient. TOTP can get out of sync and can be phished. Email can also be phished. Voice and SMS are vulnerable to SIM swaps. Now we're seeing that passkeys are horribly opaque without proper management and at risk of getting lost.
Biometrics aren't the second factor when using WebAuthn, the hardware security key is. But anyone with access to the security key can use the second factor. Biometrics would tie the key to you preventing them from being used by others. The best we have right now for unlocking the security key are PINs, AFAIK.
Passkeys are just software backed FIDO keys with no attestation and less features.
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.
I am a bit biased (I've been working on passkeys for about a year now on https://bulwark.id), but I don't think that passkeys either should nor have to reduce user control. Ultimately, passkeys do not have to be tied to hardware, and could just as easily be stored in software, much like passwords. What the industry needs right now is more open standards around passkeys, such as a shared file format for storing them or standard ways of transferring them, all of which should be possible.
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.
> From a technological standpoint, passkeys are just as versatile as passwords
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.
i kinda see passkeys being useful for all those websites i really don't care about and just have a short simple password for/something saved in a password manager i use once in a blue moon and wouldn't be too upset to loose access.
I don't see how passkeys would be better for that (or for anything, really) than simply letting the browser autogenerate a password and save it in its built-in password manager?
It’s much faster, doesn’t require you to tweak the generated password to fit their weakening requirements, and you’re never nagged to rotate it. I have used a password manager since the 2000s and for most sites like that I end up hitting the forgot password flow because they broke their password database or use inactivity expirations. You also don’t have problems when their front end developers break their form entry or validation for your password manager, which is common, and pushing this removes the justification for adding insecure MFA systems like SMS or emailed codes.
Think of passkeys as the browser autogenerating a password with much higher overall entropy (whose secret details can't be leaked if that website's database were to be compromised).
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).
How is it higher entropy? What's stopping a password from having 128 or 256 bits of entropy in it?
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.
> How is it higher entropy? What's stopping a password from having 128 or 256 bits of entropy in it?
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 a...
> they can't actually authenticate anywhere with just a public key
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?
> 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?
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.
Can you elaborate a bit on how Passkeys differ from WebAuthn/FIDO2? I know they're an implementation of it, but I don't know how pluggable they are. Will I be able to use my soft- or hardware WebAuthn authenticator on any site that uses Passkeys?
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.
Passkeys are just the product-facing name for WebAuthN, which FIDO2 devices should support. Theoretically, any FIDO2 device should support WebAuthN and therefore be used for websites, but right now there are a number of different implementations that each have their own quirks.
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.
It's surprisingly difficult to figure what what a passkey is, precisely. I think there's a bit of a terminology issue.
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).
Basically, Webauthn works by having the token sign some data using a per-website private key.
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.
Multiple accounts on the same website can be handled by the token prompting the user to select the key to use (as Passkeys do). It's not in the standard, though, so it'll have to be something custom.
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.
Passkeys are Webauthn credentials, but Webauthn credentials are not necessarily Passkeys. As best I can tell, Passkeys are _discoverable_ Webauthn credentials.
Most hardware tokens don't support discoverable credentials.
I believe the biggest issue is that they are functionally passwords when used in a user-friendy way, but security-wise they are still viewed as MFA.
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.
I don’t think it’s a complete downgrade. You get phishing protections, single-site super-strong “passwords”, if the public key is leaked, it doesn’t impact you, etc.
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.
Passkeys are not quite passwords even if backed by software and stored in the same memory space as other applications running on the OS. They're still asymmetric, cryptographically secure, and domain-bound. It's true that being "just a file on your hard drive" changes the threat model as compared to a hardware security key, but that file is wrapped at rest, potentially with a hardware security key as well.
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.
Please read the comment again, because that wasn't the argument I was making.
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.
WebAuthn lets RPs reason about the strength and capabilities of the authenticator at registration time. With a mechanism like a shared file format and standard ways of transferring them, those mechanisms would be undermined. With hardware-backed multi-device Passkeys, the entire sync fabric becomes the authenticator. Apple and Google currently zero out attestation data, but you can imagine a scenario where attestation data matching the device is presented for single-device passkeys and DPK, but a different attestation key is used for multi-device passkeys that represents the entire sync fabric.
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.
This is something that I think is a bit of a security tradeoff. Hardware-based keys are absolutely more secure than software ones, but they come with significant usability limitations. I worry that if RPs restrict themselves to only hardware-based keys, then that will kill adoption of passkeys in general and we will be stuck with passwords. Software passkeys are already a significant security upgrade to passwords, and so I would like to see them gain adoption.
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.
Yeah don't get me wrong, I wasn't disagreeing. I think the lack of interoperability is a major risk to adoption, but I also understand why we don't have interoperability today and why we likely never will.
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.
> 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.
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?
You can't export hard TPM keys so attested keys become recovery bottlenecks in the user experience. Sure, that's a potential moat to prevent people as easily jumping between walled gardens, but it's also a moat that accidentally can just make your users unhappy if they end up in an unhappy path in your walled garden. People lose devices and need hard recoveries all the time. If they can't get past the moat, they are just as likely to jump to your competitor anyway if they are "starting over".
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.
I refuse to use “login with XX”. I don’t want this either. It makes you dependent on somebody and I think the average person will eventually get strong armed into paying a subscription fee for their “passkey manager” even though they only have a few logins.
I don't believe someone who only has a few logins is really the target here. Someone with only a handful of logins can easily remember separately complex passwords for them. For most others, they are using a variety of services and are reusing their simple passwords which put them at greater risk.
I’ve been predicting that for OIDC for a while: “Starting January 1st 2025 the use of Google accounts to log in to third party services will require a premium subscription unless those services subscribe to Google Authentication services…” Wham, now Google levies a tax on all SaaS vendors or users that allowed Google login.
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.
Does FIDO have a method to require keys are stored on devices certified to a certain level?
One thing that concerns me is that if passkeys gain acceptance, certification requirements could be used to block open source/self hosted implementations.
This is for U2F, which is not FIDO2, though FIDO2 is backward compatible with U2F with a limited set of features. U2F-only hardware is not compatible with the passkeys model.
>The major difference between passkeys and ssh keys is how they are managed. You can, and should as good practice, generate separate ssh keys for each ssh service that you use, just as you should generate separate random passwords for each web service that you use.
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:
>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.
The problem is that sites are sloppy about this and many password managers allow you to fill in passwords even from other domains. WebAuthn makes that impossible even in the face of good social engineering.
That's the intent of password managers, but there are all sorts of attacks/bugs/footguns that could still let the wrong thing happen. You could imagine scenarios where you don't have time to investigate why your @#$(#! password manager isn't autofilling today, and you do it manually. The confused deputy problem is real. Contrast FIDO's design, in which it's actually not catastrophic to give the secret to the phishing site, because they can't do anything useful with it. There simply isn't a "hunter2" for them to obtain, even if the confused deputy wanted to give them one.
> 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.
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.
TLS prevents me from, say, tampering with your network traffic and pretending to be Google.com if I control the network you’re on. That’s a hard attack - not unprecedented, especially for hostile governments or unethical ISPs but uncommon for most people.
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.
There are two things being authenticated here. The server and the user. Passkeys authenticates the user. So there is nothing passkeys can do to prevent phishing of the type described which involves improper authentication of the server.
That’s not quite right. WebAuthn completely prevent cases where the user fails to authenticate the server, which is an extremely common attack. It does not protect against a compromise of the web PKI system, which is a rare and catastrophic scenario which no other alternative protects against but they do mitigate the damage somewhat in that using a public key rather than a shared secret prevents reuse and implementations are required to confirm user intention so I can’t spam logins to other sites or faster than you’re willing to tap a button.
What does any of this have to do with my contention that public key signatures are not really needed in the case where every connection has its own key pair? I think we are talking about two different things here.
Yes, https://bulwark.id/ and it's fully on software, it looks pretty cool. I haven't tested it and can't vouch for it but it's author [1] was commenting here that's why I found it.
"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." -Apple Authentication Experience manger
Until Google, or Apple, or facebook, or whoever is the passkey store holder decides to put up an interoperability wall, either through neglect, cost savings, or intentional user retention.
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...
I'll believe this when it actually happens and I can audit the whole implementation stack myself. Until then, I trust Apple about as far as I can throw them. Remember when they got sued for lying in ads and their defense was "no reasonable person in Plaintiff's position could have reasonably relied on or misunderstood Apple's statements as claims of fact"? https://www.wired.com/2008/12/apple-says-cust/
"Now, FaceTime is based on a lot of open standards -- H.264 video, AAC audio, and a bunch of alphabet soup acronyms -- and we're going to take it all the way. We're going to the standards bodies starting tomorrow, and we're going to make FaceTime an open industry standard." - Steve Jobs.
It's great that they're aiming for this, but there's no reason to take them at their word until they actually ship something.
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?
I share the view that I'm not going to trust Google or Apple with my passkeys, not for any ideological/trust/privacy reason but just not putting all my eggs in one basket.
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.
Just like there are diehards still running their own email servers (kudos to them), will there be people running their own passkey backends?
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.
Attestation for hardware-backed FIDO authenticators is worthwhile. You can attest to various properties, such as whether or not the credential is protected by a PIN.
Of course it has value, but it’s a tradeoff for freedom.
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.
It's presumably the authorized party who has the most to lose if the passkey backend is compromised, so it seems weird that the who-to-trust-for-auth decision falls to the web service.
I'm reminded of a sign in front of my neighbor's driveway: "Ford parking only"
One of the really cool uses of passkeys is cross-platform sign-in via the QR code flow. (i.e. passkey on phone, scan qrcode on desktop, desktop logs you in). However as I understand it, to be able to do this you need to use the platform's(google,apple, microsoft) caBLE infrastructure[0]. Will open-source passkey managers have the ability to hook into this?
I have the opposite concern. The great thing about Yubikeys and other FIDO U2F/FIDO2 keys is they can't be cloned. With Passkeys living on your iOS or Android phone, they are only one successful Pegasus exploit away from being compromised.
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.
The whole messaging on passkeys are extraordinarily confusing. When I start reading, it sounds like a great thing: instead of passwords, I authorize devices to my account by associating a public key with the account. But it's unclear if supporting passkeys actually requires services to support more than one public key associated with an account. The fact that you can sync passkeys to the cloud (rather than just using a key stored in a TPM) suggests that it's not actually a requirement, and it isn't even the default behavior. It seems like passkeys are intended as a fancier version of "log in with" rather than an actual private key/hardware-based replacement for passwords. 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.
It sounds like maybe I can achieve that, but not with any of the standard implementations.
Passkeys are a brand name for an "all of the above" buffet of menu options and sorting out specific "branding efforts" versus the practical, achievable, standardized options is going to be a real ongoing challenge. On the one hand, because it allows for and often uses so many different practical options that should mean that no one path is better tested than any other. On the other hand, yeah it adds for a lot of complications when trying to figure out what people (will) mean by "passkeys" support.
> 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.
Passkeys are half baked as implemented and rolled out by apple and Google.
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 there's an option to using alternatives to those you don't trust, like Google or Apple, that's good. If not you need to find an alternative service.
> The whole thing seems to be a bit of security theater too, because the YubiKey is not keyed to my biometrics, so anyone in physical possession could touch the button to authenticate.
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.
> 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?
183 comments
[ 2.7 ms ] story [ 206 ms ] threadHow 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.
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.
https://solokeys.com/
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.
https://passkeys.directory/
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.
[0] https://news.ycombinator.com/item?id=35851476
[1] https://github.com/keepassxreboot/keepassxc/pull/8825
[2] https://github.com/keepassxreboot/keepassxc/issues/8214
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.
https://hachyderm.io/@rmondello/110329118270492669
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.
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 a...
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.
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.
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.
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.
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.
My password manager of choice is open source, and cross-platform, and can export and later (or elsewhere) import an encrypted backup.
[1]: https://news.ycombinator.com/item?id=35854698
It’s a passkey-first authentication solution for websites and mobile apps.
https://hachyderm.io/@rmondello/110329118270492669
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?
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.
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"
[0]:https://blog.millerti.me/2021/06/18/previewing-chromes-cable...
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.
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.
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.
You need the choice.
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.