As others have pointed out, cryptographic authentication is very hard to bootstrap if you simply loose your device.
Just last month my missus cracked the glass of her iPhone. Apple repaired it under AppleCare, which is great… except… that they didn’t tell her that the “glass repair” entails them replacing the guts of the phone and wiping it in the process.
Apple iPhone backups don’t contain cryptographic secrets like eSIMs!
She got stuck in a loop where she couldn’t activate her eSIM because that needed her email, but her email needed MS Authenticator, which she couldn’t activate without an SMS.
She had to drive to the Telco with a pile of photo ID to reissue her eSIM. Her bank account got locked in the process despite the password being correct because of some sort of phone hardware lock.
This took days to fix and multiple in-person visits to various organisations. If this had happened while overseas on holiday, she would have been screwed.
Times have changed.
Your entire digital identity is now a smart card in your phones
That Smart Card is either a SIM card or an onboard TPM chip, but in any event if you lose it, you may as well be dead as far as anyone else is concerned.
Passkeys make this much worse. At least if you still have a physical SIM you can transfer it from any phone to any other phone.
Passkeys are not cross-vendor transferable!
Run away screaming. Don’t believe the hype. Wait until the vendors get their act together and come up with a solution for transfer and recovery.
> Run away screaming. Don’t believe the hype. Wait until the vendors get their act together and come up with a solution for transfer and recovery.
Very much this. Having authentication tied to hardware you don't control is a near-certain denial of service in the future.
People love to hate on passwords but the reality is that for many circumstances (threat models) they are the best compromise. You can make them more than strong enough (take 32+ bytes out of /dev/random and encode however you like, nobody will ever brute force that in this universe) and various passwords managers solve the problem of re-use (never reuse a password).
And it comes with the benefit that you control how it is stored and can apply as much redundancy as you want to feel comfortable.
> People love to hate on passwords but the reality is that for many circumstances (threat models) they are the best compromise. You can make them more than strong enough (take 32+ bytes out of /dev/random and encode however you like, nobody will ever brute force that in this universe) and various passwords managers solve the problem of re-use (never reuse a password).
> And it comes with the benefit that you control how it is stored and can apply as much redundancy as you want to feel comfortable.
Honestly, I agree!
I used KeePass back in the day (https://keepass.info/) but now use KeePassXC (https://keepassxc.org/) and it's really nice - I don't know any of my passwords because they're all randomly generated and are pretty secure, in addition to them being unique for every account. The only one I have to remember is my main password for decrypting the safe, which I also wrote down and entrusted to someone close to me due to its complexity.
It honestly works great, software to interact with the password safe is on every platform where I need it to be, in addition to it being super easy to reason about storage, because it's basically just a file - that I can then put on self-hosted Nextcloud, or another solution like that, or USB sticks or burn to CDs for all I care.
Maybe I should also migrate all of my TOTP stuff over to it and look into good Android apps at some point, then I wouldn't quite need Google Authenticator or FreeOTP anymore, either.
You're gonna have a problem when you're on a trip abroad and lose your phone. Your only recourse is to go to the local internet cafe and log on to your email so you can send a message for help. Except you can't, because you dont know your password...
> You're gonna have a problem when you're on a trip abroad and lose your phone.
There's also the possibility of bringing my netbook with me, which also could have a Nextcloud client setup (or Syncthing, or some cloud based option), same as every other device that I own, which would have the last offline backup of the file even if the server itself would blink out of existence.
Honestly a bigger problem without my phone would be the fact that I basically couldn't pay for things all that well when using a card, because of a redirect to my bank when making a purchase online (to confirm it), which then makes me use https://www.smart-id.com/ with a code to confirm it. That's kind of a problem because it's not TOTP but rather it's bound to the device.
I can work around the password safe issue with an SD card that has the database on it, or a USB stick as well, but that wouldn't work for the app, so in the modern day I'd basically need to have two phones, the same way someone might have two sets of keys to their apartment or something. Kind of crazy when you think about it. And I'd also need a smart card reader to even register a new account in most cases, in combination with my government issued ID card.
Non-tech people have a fundamental misunderstanding of what makes a good password, and stupid IT policies like password expiration lead to really bad habits like frequently forgetting passwords, frequently reusing passwords, and end with writing it down on a post-it note.
How does this address OP's concern? If you have a single device (e.g. an iPhone) and you store all your passkeys on it, then losing it means you lost all passkeys. Your post describes exactly that:
- "I can’t recover the keys if I lose the hardware"
- "That is a risk you’ll need to take if you’re using hardware authenticators"
Fantasizing that with this proposed simplification of the authentication process people will introduce complexities such as a password manager or a backup hardware device is naive to say the least.
I haven't heard anyone claim that passkeys are simpler than passwords, as that would be trivially false. The claim is that they're more secure while still remaining fairly usable.
Passkeys are WebAuthn credentials that are synced between devices, so they aren't hardware keys, they're software keys.
"more secure" is a completely meaningless statement, I wish this usage would die already (in general).
You need to talk about security in the face of a very specific threat, then you can say solution A is better than solution B against threat T1, worse for T2 and about a wash for T3 and so on.
Security is not a linear scale from 0-100 where you can say "more secure". There are many different criteria and any given solution will be better in some, worse in others. You must do a threat model for your specific use case to say if something is better or worse for those specific threats, and keep in mind other people will have very different threat models for the same solution.
Threat #3: User reuses a credential (uses same credential across multiple services)
Threat #4: Phishing
Attackers use huge password dumps compiled from multiple server breaches, and then try them against other services. Relying on a combination of the fruits of their labor from all four threats, attackers successfully compromise millions of accounts on the internet every year.
If you want to see the data, check out the Verizon Data Breach Investigation Report that comes out every year.*
These threats affect a majority of both consumers and enterprises.
Passkeys address all four of these major real-world threats. Passwords address none of them.
Threat #1 mitigation: with passkeys, only a public key is stored on the server. Attackers can steal all the public keys they want; it will not help them compromise any user's account.
Threat #2 mitigation: passkeys (which are WebAuthn credentials) are guaranteed to be cryptographically strong. It is not possible for a user to generate an insecure passkey. This is because the browser the the Operating System APIs take care of generating the credential.
Threat #3 mitigation: passkeys (which are WebAuthn credentials) are guaranteed to be unique. It is not possible for a user to reuse the same passkey across multiple apps/websites. This is because the browser the the Operating System APIs take care of ensuring that a new, unique credential (passkey) is generated for every new app/website the user sign's into.
Threat #4 mitigation: passkeys (and all WebAuthn credentials) are bound to the server FQDN at the time they are created. The browser and Operating System APIs take care of ensuring the credential is only ever sent to the app/website server it was created for. Users cannot be tricked (via phishing) into using their passkey on a malicious app/website controlled by an attacker.
But personally, as a technically able user, my risk of randomly losing access to my Google (or MS, Apple, Meta, etc) account is far greater than from all those threats combined.
If we had a trustworthy and accountable authority operating this stuff then it would be great. But we don't, we have a bunch of companies who are neither of those things.
It's like mandating that everyone must use self-driving cars that are on average safer than human motorists but occasionally randomly drive off a cliff.
You can use whatever passkey/password manager you want to though. You don’t need to use Google or Apple’s password/passkey manager apps if you don’t want to. Passkeys are WebAuthn credentials, which is an open standard, and it’s being supported by an increasing number of password manager apps.
In theory. Let's see how that pans out over the next couple of years, I think imposing platform lock-in in is going to be impossible for them to resist.
What about the users who _aren’t_ technically able? That’s where this technology is most important at the moment.
That aside, what happens if you lose your current password? Every major platform out there has a method for recovery. Why can’t that be used for passkeys as well? I don’t see how there’s any incentive for companies to lock us out of accounts, when the platform is pointless without people consuming it.
We may have very little power, as users, but if enough people have trouble getting into their own accounts, that’s going to directly impact the bottom line of the company locking them out. From a purely capitalist standpoint, that’s a really good reason to make sure that that doesn’t happen.
Lastly, at least Bitwarden is planning on having passkey support in their password manager very soon, so there’s real competition that will allow users to be in full control of their own passkeys.
Password managers completely solve #3 and #4. They also largely solve #1, unless the leak happens from a company that stored them in cleartext or base64. But since the password was unique, it doesn't matter in practice except for that single backwater site so who cares. Not a threat.
Password managers don't solve #4. But you left out the huge one, losing access to the account. Which for most people is a larger risk than all the others put together.
For just about every person and account, the near-zero chance of getting personally spearphished is much less relevant than the risk of complete loss of access.
>But you left out the huge one, losing access to the account.
Losing access to your passkey/password manager is a separate concern from the strength of the credential itself. Passkeys and passwords are just credentials. What you use to manage them is a separate concern. The concern about losing access to your passkey manager is super valid, but that same concern applies to all password managers that exist today. It's not a new concern that's specific or unique to passkeys. Yes, if you lose access to your password/passkey manager, then whatever solution you're using better have a great recovery story.
I know that at least both 1Password and iCloud Keychain have pretty great recovery flows. I am not sure about Google or the other password/passkey managers (I haven't looked into it deeply).
>of getting personally spearphished
100% agreed that most people don't need to worry about spear-phishing attacks. But that's (sadly) not super relevant, because many users fall for run-of-the-mill basic phishing attacks that any reader of HN would never fall for in a million years.
The most problematic and the most probable security risk I have relating to logins is losing access. It for example took a week to restore access to my Apple account after I had forgotten to update my phone number there.
Since this is the greatest security problem, I would hope all the vendors trying to improve security would focus on that.
> The most problematic and the most probable security risk I have relating to logins is losing access.
Exactly. Unrecoverable secrets tied to closed hardware solve for the scenario where your most important criteria is that no attacker be able to ever access your account, even at the expense of yourself possibly losing access to it forever.
Does this solve a problem anyone actually has for consumer accounts? No.
That threat model makes sense for highly classified information where it is preferable to lose the information forever than have an attacker get it. Other than that, it's not a reasonable threat model to optimize for.
They are not more secure from a cryptographic standpoint. There are different attack vectors and for some passkeys are superior but in others they are certainly not.
Additionally, part of the security concern is also accessibility by yourself.
edit: Just tried the Google passkeys on one of my Android phones. It is a complete usability hell and it seems I cannot opt out again without logging in from my browser and deleting my "device". If there is another way to just do it from my device without an additional browser, please tell.
Etc etc. If this is the first time you are seeing businesses and media refer to passkeys as being simpler to use than passwords you haven't been paying attention.
Oh huh, I stand corrected. I thought passwords were easy, but, thinking about it, I've had lots of trouble trying to figure out which password I've used for each site.
I can definitely believe passkeys are easier, in light of that.
Personally I think that’s the best selling point of passkeys. Most non-tech people don’t use password managers and have to memorize passwords, reset frequently passwords they can’t remember, etc. Security is way harder to sell than convenience.
Saying that, I am struggling to understand what is the expectation for ordinary user behavior in terms of hardware-tied credentials. Eg so many people upgrade their iPhone every 1-2 years. If passkeys are not transferred to the new phone, what is the industry suggesting people do?
Passkeys are Google-synced WebAuthn keys, so there's no such thing as hardware-tied passkeys. If you want to use hardware WebAuthn keys, you should know what you're doing.
> I haven't heard anyone claim that passkeys are simpler than passwords, as that would be trivially false.
I have frequently heard and read claims that passkeys are easier to use than passwords. The claim always seemed incorrect to me for so many reasons. What passkeys do is make things more complicated, but move where the complication is.
“That is a risk you’ll need to take if you’re using hardware authenticators. The fact that the key isn’t copiable means you only have one of it, so you should probably be enrolling multiple hardware authenticators on each account, or just switching to a software authenticator if you don’t care about the decreased security.”
Software authentication with backup and synchronization is how passkeys are being shown to end users on two of the biggest platforms. For Apple, this is iCloud. For Android, it’s Google Play services. Add to that the fact that 2FA tokens are very often tied to a particular phone, and there’s very little difference between a passkey and the current system of passwords + 2FA, except that passkeys are currently far more resistant to phishing.
Certainly it’s far from perfect, but for the majority of every day users out there, this is a huge potential leap in preventing phishing attacks, which _are_ a real (and growing) threat. Rather than just throwing the technology out, perhaps we, as well informed people, should be looking for solutions to the problem of bootstrapping and recovery, rather than just throwing out the first technology that has a real chance at fixing this problem.
Why does this article claim that attestation is unlikely? We know Google loves the idea - see Web Environment Integrity (WEI).
Also, what's stopping us from falling into the passkey version of the world we got with OpenID, where many services force you to log in with your BigTech account?
> Why does this article claim that attestation is unlikely?
Facebook is still going to want me on their websites even if I’m running Firefox. Most websites people visit will not do any chrome WEI attestation. Likely exceptions are sites which handle any legal, financial, or health-related data. Not credit cards. I doubt most Google properties will use WEI.
They still want to slurp up all my juicy Firefox usage data and I bet they think a lot of such users will drop their services like a rock if it meant otherwise dropping their browser.
I'm willing to bet otherwise (w.r.t. your first statement). They probably consider the sliver of such users expendable. They probably also (rightly) assume that a significant percentage of that sliver will continue using their service (e.g. via sanctioned Chrome on sanctioned hardware) if push comes to shove.
Or at least they will at some point in the near future.
Facebook went out of their way to make an onion address available for the application (https://en.m.wikipedia.org/wiki/Facebook_onion_address). They consider nobody to be “expendable” when it comes to their desire to profile individuals. Forcing their users into a specific browser will do nothing for them when what they want is for people to make requests against their servers.
That article is about as misleading as it's possible to be while still being technically right. The "attestation" feature of passkeys exists solely to let websites refuse to let you use passkeys tied to hardware you do control, or to software. The way this article only mentions it in passing and tries to downplay it reminds me of the joke of https://what-if.xkcd.com/49/ - a very long article listing a bunch of upsides of the Sun going out, and only one sentence about the downside: "We would all freeze and die."
We can already see this to some degree. On my Android device, Chrome will only let me create a synchronized passkey in a Google account UNLESS attachment is explicitly set to "cross-plattform" - even though not specifying the option is supposed to allow all types.
You can try this out on webauthn.io and changing the attachment setting.
Just like the rest of it, they’re going to try to lock down the open web, general-purpose computing, etc.
They are going to be the gatekeepers if you and the web services let them. Oh yeah — also they’ll run all the web, email and other services anyway. Trap you in their metaverse and AI most likely, since that’s where your coworkers and friends will be you’ll have to be there too.
Contrary to popular belief Google doesn't run email. It more or less does so in the US, but only there people were so enthusiastic to jump onto their platform. Probably a result of other US alternatives being that bad.
But in many other countries, gmail isn't that successful. Still, email is still under attack by big mail servers getting more and more restrictive.
Riiight. Another cryptocurrency solution. crypto falls into the same category of untrustworthiness as the rest of these so called solutions. The only difference is the that crypto has a more murky past.
There are existing cryptographically secured systems which have scaled to many users, like Bitcoin wallets and Keybase accounts, and do have a recovery fallback. It's usually called a "seed phrase" or "paper key"... which is really just a password! :D
> Run away screaming. Don’t believe the hype. Wait until the vendors get their act together and come up with a solution for transfer and recovery.
I believe all of the issues you've described, but you can usually add multiple passkeys to each service. There is nothing stopping you from adding your iPhone and a cheap android phone and having redundancy, or using 1Password and storing your passkey in there.
iPhone backups do store backups of the media stored in iCloud Keychain, if you have another apple device or if you have the recovery key, you can get back in. You just need the device passcode or recovery key and you can re-bootstrap everything. eSIMs are unique because they're carrier things and those things have and always will be a pain and tied to stores and phone calls.
Passkeys and u2f keys aren't the same. Systems must support multiple passkeys, otherwise you could only access the service from a single device, since passkeys are usually tied to a particular piece of hardware.
Nevertheless, nothing forces my banking app to accept a second PassKey other than the one linked to FaceID. When I buy a new phone, I need to re-bootstrap auth from zero. There’s no way to store two.
You'd be surprised! There are plenty of new banks in Asia which only have mobile apps. You can't access your account using a web browser at all. They don't even give you a passbook, all banking activity from signup are done via the mobile app.
The majority of sites I've used that supported U2F/passkeys/yubikeys/webauthn support multiple. In fact the vast majority I've used supported multiple, only a few outliers only supported one.
There are workarounds, but that doesn't mean that passkeys is a half-baked technology. The real, simple solution would be a way to write down the passkey, similar to an SSH private key.
A main idea of passkeys is that the private keys are bound to hardware and cannot be copied. Using the private key is subject to biometric authentication. This eliminates a whole category of issues where the private key could get stolen.
So no, writing down the SSH private key is not the solution. The solution is to trust multiple private keys, each stored within tamperproof hardware.
This is also why, as a service provider, I'd like to see some device attestation. I want to know that the keys being used here are not written on a fucking piece of paper.
> This is also why, as a service provider, I'd like to see some device attestation. I want to know that the keys being used here are not written on a fucking piece of paper.
This is precisely why user should run away. Service provider is moving liability to end user and washing their hand away, while user gets screwed if anything happens during vacation.
End user also gets screwed when they are phished for their paper key. And I'm not sure about liability, unless you consider the requirement to check haveibeenpwned once a week for a breach to be no one's responsibility.
It sounds like I am up the creek if all of my devices are gone.
With a bank, if I lose paperwork, they will have a process in place for me to prove my identity. BigTech will shrug if my phone-locked passkey becomes inaccessible.
The effort and hassle for Google et al to invest in robust support mechanisms (backend and people) for passkeys makes it highly unlikely.
No doubt you'll get the standard boilerplate email responses, if you are even that lucky, that just point you to an FAQ or something similarly unhelpful.
I recently watched a movie called the circle with Emma Watson where they want to tie the account with a corporation as a means of Id to register to vote.
Imagine leaving identity to a corporate who simply shrugs off all but legal threats. It's terrifying and I reckon we are in our way there
Or use a password. Seriously, you have to do better here. I guess we will see recovery options by a master password and then the mechanism would be the question again.
I don't get it, why is a password superior? The argument of "what if you lose access to multiple devices" seems just as valid as the argument of "what if you forget your password". Recovery is the same either way - you need to establish identity somehow, using any number of other mechanisms (such as showing up somewhere with government issued ID).
I can make a personal backup of a password. A fragile piece of hardware can fail me for a variety of reasons outside my control(lost or suddenly breaks).
I have had a (Google) phone suddenly die in my hands without any prompting. With a password I was able to transition to a new device without incident. If my passkey was locked to that device, I might have found myself locked out of my digital identity.
> A fragile piece of hardware can fail me for a variety of reasons outside my control(lost or suddenly breaks).
But you can use multiple devices... How is "a password written down and stored somewhere" better than a separate device used for backup purposes? Hell, get three devices, go nuts.
It's free and trivial to backup a password database any number of times. Even storing it with a cloud provider is nearly free, because they are so small. You can even automate verifying that all the backups are accessible and valid. When you create a new account with a new service, your daily backup will pick it up immediately.
With passkeys you have to buy multiple phones, sign each of them into every one of your accounts, then keep them physically distributed (no cloud storage for phones). And to make sure they still work you have to periodically manually go and interact with the phones physically, even the one you stored in a bank vault. You also have to do this if you sign up for a new service.
Not to mention the inevitable services that don't allow multiple passkeys.
You also lose an element of security - if someone steals your phone, they still need your fingerprint/face/PIN/whatever to access all your accounts, and you might even be able to lock or wipe the phone remotely.
That does not seem like a big burden to the majority of the population? Many people have a single phone. That’s it. Everyone can write down a password without any troubles. This new and improved mechanism requires people to shell out real money for multiple devices just to be safe in case of loss/theft/failure?
Let’s not forget the providers who do not offer the ability to enroll multiple devices. Last I heard, AWS would only let you put a single authenticator on your account.
AWS is violating the spec and it's an embarrassment tbh
Anyway, to be clear, I'm not advocating for "get rid of passwords forever", I'm saying that for a lot of people passkeys are superior and the whole "how do I recover" is just not that big of a deal.
The main issue is the cost of devices like yubikeys. They should lower those. Companies should start providing them. Schools should hand them out. etc.
> as a service provider, I'd like to see some device attestation
As a user I hope you don't get it. Having an easy way for services to require that everyone using them is doing so via the official app on an iPhone or OEM Android phone sounds like a nightmare.
> The solution is to trust multiple private keys, each stored within tamperproof hardware.
But as a user, this is not a realistic solution. If I have to keep multiple pieces of hardware enrolled, that means that I have to keep all the multiple pieces of hardware at hand when I create an account somewhere, and go through multiple enrollment cycles.
That means that I have to keep all the various pieces of hardware in the same physical location and relatively easy to access, which removes a great deal of the safety of redundancy.
It's just not realistically workable for me.
> I want to know that the keys being used here are not written on a fucking piece of paper.
What kinds of services would benefit from this level of security? I could see it being useful in corporate contexts (like locking down which machines are allowed to remotely control other machines), but not as much from a general consumer point of view.
At least with enterprise IT, or a bank etc you can pester them until they let you back in. They’ll have to sort it out eventually. That’s not going to work with Google or most web services.
Any web service that locks accounts to devices is going to be shedding customers as they lose or replace phones.
Totp is phishable. Passkeys aren't phishable. At the point where the user can access the private keys phishing is once again a concern.
If I can't access my pk, I cannot be phished. As soon as you allow me to copy my key (instead of creating many, which should be acceptable) I can be phished again.
You can't MITM a passkey, you can MITM a TOTP challenge.
That is, passkeys cannot be phished. The only way to get into my passkey protected account is to physically gain access to my passkey device, which requires both physical access to the device, and a second factor like a face/fingperprint or PIN/password.
Additionally, the TOTP secret can be copied, while today passkeys don't allow that either.
Except that that thing you memorized gets transferred across the wire as part of the authentication process, leading to all sorts of places where it could be intercepted. Passkeys don’t leave the device, outside of backups and synchronization. Thats a way lower attack surface.
Add to that many web sites now make it a point of pride that they employ no humans in support and will not do anything to help you get back into your account if you are locked out (Google, Meta etc).
They employ humans in support - behind firewalls like follower counts.
If Neil deGrasse Tyson gets locked out of his Instagram, you can be damn well sure someone answers his support request.
If you or I, in two to four digit follower counts, have an issue? We can get fucked.
Damn near most companies do this with the social media PR teams, too. Any tags/mentions, messages, etc are filtered through software that decides how much cloud you have and thus how worthy of attention you are. Delta loses your guitar and you've got 100 followers? Nobody in the social media team is likely to even see it. Someone with 5000 followers, and a post about it gets a couple hundred likes/retweets? American is going to fall over themselves to make it right.
That's the great lie about social media - that you can use it to draw attention to a problem you're having. Unless you've cultivated a large enough following, you'll be completely ignored.
As with everything, you probably want a backup. Get more than one passkey.
I pretty much use 3; Yubikey in my workstation, portable Yubikey, phone. All 3 of those can bootstrap Google, which I use for email, and Apple, which I use for my phone. Then, everything else is in 1password, which are available through those mediums. Worst case, I am pretty sure in the most dire of dire emergencies, I can get my email back no matter what. Verify ID with my DNS provider, switch MX records, back in business. Even then, it's not necessarily essential to daily life. (A colossal inconvenient to lose access? For sure. Death sentence? Probably not.) All my SMS and Signal contacts are elsewhere. I can spend money out of my bank account by writing a check. I can get into work stuff by showing up in person at an office.
I do think that passkeys are probably too complicated for the ordinary user of computers; unfortunately that "we'll just email you a link every single time you want to sign in" seems like the most user-friendly passwordless authentication.
I also don't feel great about my habit of putting passkeys in 1password, because I know I'm locked in forever. But, I like the service, and when I want to switch, welp, at least there's a list of accounts I have to remake.
My biggest fear is something like forgetting my phone's passcode. One time I woke up, got distracted at just the wrong moment, and could not for the life of me remember my 6 digit passcode. (I also use the same code to unlock my workstation.) I had to distract myself and then use muscle memory to remember it. It was really crazy, truly one of those "did I just have a stroke" moments. I have that saved in 1password now, so if I have one unlocked device, I can refresh my memory. This happened a while ago and I don't think I have dementia. Just a weird quirk.
(Meanwhile, I can perfectly remember every 1-year-max-lifetime password I've ever had at any job. A lot of that good does when you can't remember a 6 digit number!)
To save people from reading the article before running away screaming:
> But while they’re a big step forward, we know that new technologies take time to catch on — so passwords may be around for a little while. That's why people will still be given the option to use a password to sign in and may opt-out of passkeys by turning off “Skip password when possible.”
So, soon passwords will be added to “Killed by Google,” along with my account. (I keep zero devices logged in.)
It’s well past time to migrate off my few remaining use cases. I wonder if my employer will be able to reset my corporate account passkeys when the inevitable happens.
There is no way adding multiple keys to your account is more work than a password manager. Just use a password manager and retain full control over your secrets.
Passkeys are one of the non-phishable means for authentication. If something is easy to recover for user then its same for a malicious actor. Some platform based passkeys (apple, google) are actually sync-able across the devices. The whole Passkeys concept is under debate and discussion for what it means for different types of WebAuthn authenticators when it comes to the ability to sync the credentials. Alternatively one can use security keys which they can keep with themselves and could protect themselves by enrolling one additional security key for recovery purposes that they can keep away. Regardless the whole idea is to have more than one MFA factors enrolled so that one is not get locked out. Ease of using WebAuthn/ Passkeys overweighs typing in password, SMS, TOTP codes and has big savings for big players to avoid phishing attacks. It might not be suitable for every use case but worth using for some.
Unless you store the passkey in a hardware Fido key like a Yubikey. Then the way to transfer it is to physically carry the key and plug it to another device.
In this case, we're using the term "cross-vendor transferable" to mean that the key material can be exported out of one vendor and imported into another. So if you could export the passkey from Windows Hello and import it into your iCloud Keychain, that would be cross-vendor transferable. Or if you could export the Resident Key out of your Yubikey and import it into Google Password Manager, that would be cross-vendor transferable.
Honestly, if they'd just give me the option to write it down (or take a picture or whatever) and manually restore it by typing it in if I need to, that would just about solve the issue
Seems like it'd be a little annoying to pick different things to type in for each service, maybe we could manage those, but still have a primary 'thing to type in' to the 'thing to type in' manager, which would then handle choosing and typing the various things into the various authentication boxes.
And it would be completely independent of vendor or device. Should write a paper on it.
Seriously, just tried passkey on an Android phone of mine with a burner account. I would not recommend this to anyone. Passkey as a tech might not be the issue, but the lacking option of just removing devices and passkeys freely from your account is just not acceptable. The vendor simply has different ideas about security than I have and it is not just restricted to serving me "safer" ads.
Great so now people need to be rich enough to own multiple phones? Really. The solution can’t be “buy multiple devices” when the average person can barely afford to maintain one working device.
Your computer can also be a passkey.
I currently use both my laptop and my computer as a passkey, and a USB drive. So I have 3 backups to my Google account.
It is true that you do need to be rich enough to own a phone and ~100 USD of something else (laptop or USB), which does put redundancy out of the reach of a large portion of the world. But then they can just use regular 2fa at the expense of not being phishing-proof.
Yes, but in order to add new items to each piece of hardware you have to be physically co-located with all the pieces of hardware you want to use as your backups. Which means they cannot be geographically distributed (or if they are that there is a period of time in which you aren't fully backed up). Which means you're either in a place where you can loose all your keys (e. g. a house fire or a flood) or your in a place where you can loose all the devices that have a key.
You have to be within several layers of bubbles to not see how small a percent of the general population are going to even understand any of this BS.
Things being this complicated makes them a non-starter. A nerd vanity project.
And this isn’t a knock on the “intelligence” of the general population. They quite rightfully won’t want to spend their limited time on God’s earth learning about all this.
How many of those devices do you think people are willing to buy, keep updated, AND store off site? A fire, car accident, flood, or major theft could wipe multiple devices out in one fell swoop. Unless there's a secure way to make passkeys portable and able to be backed up in a secure manner off-site, I will avoid this tech like the plague.
Funny story, if you’re using TOTP (the time-varying code thing like in Google Authenticator), you can save a picture of the QR code and reuse it later and it will still work.
Your wife's experience sounds very bad and the risk of getting locked out of your various accounts is serious.
That doesn't mean giving up on having good security, though. Passkeys don't work like eSims and other users' situations might not be the same. Their failure modes will be different. They might have more than one device (like a phone and a tablet), or they might not use MS Authenticator for their email, or they might have set up different recovery methods?
We need more backups and user education, which ideally would include rehearsing account recovery before it's actually necessary.
TBH I don't trust google on security one bit after one of my namesakes attached her phone to my google account a few months ago without any warning or prompting by google to me.
Not being able to regain access in exceptional cases is one of the big reasons why I am very weary about being forced to activate 2FA and other auth. It is so nice in theory... But the reality is that many users only use their phone to do almost everything digital in their life. My gf works for an assitive technology reseller. Since 2FA has been forced down the throats of unsuspecting users, she had to support several of their customers in regaining access to their Apple ID, noticing a few glitches in the supposed apple support path while at it. Phone hardware changes every few years. email addresses can change. And phone numbers can change. Combine all of them, and 2FA is suddenly no longer such a good idea... For reasonably sized companies, 2FA might be a good solution, because in case of you loosing access in some way, there is likely a support path that gets you back on track in reasonable amount of time, given that IRL auth is relatively simple. But for services where you are just a number, like every big provider, I believe a reasonably strong "master" password is still comforting to have.
The solution to your problem is simply more passkeys.
I am not being sarcastic - which ever service your authenticating to make sure you have passkeys from at least 2 different devices so you do not lock yourself out.
If you don't fit into this multi device assumption, passkeys are not going to work well for you. There will not be a standard for transfer / recovery.
That is completely unrealistic to me. The normal users will not register different devices and will simply be locked out when the device fails or is lost.
And the question they will ask is about the need to have two passwords.
Not just multiple devices, but multiple locations. A fire, flood, car accident, or theft can result in the total loss of multiple devices unless one is sufficiently far away and also secure. Then there's keeping that remote device up to date. This is beyond the patience, finance, and understanding of virtually everyone.
Completely agree. Currently I can perform a full bootstrap using information stored in my brain (with my partner's brain as backup). Any new "solution to passwords" that doesn't allow that means an instant NO from me. I don't care how much more theoretically secure it is.
It isn't more secure if you use a secure password with the standard way of auth today. Especially not theoretically what relates to cryptography.
Some common attack vectors like phishing would be more secure since you more or less automatically generate different credentials for different services, just as you get different access tokens from your oauth service. Token theft is an issue too, but only ever partially compromises you for a limited time.
Having different passwords doesn't prevent phishing where you think you're logging into the service being phished. The hacker would also create a new TOTP on that service once they get in to that service.
It would be awesome to have an "emergency" server where I could type in the URL, decrypt it with my passphrase and OTP, and get access to everything I need temporarily so I can re-bootstrap all my stuff. Of course, this doesn't solve the problem of SMS 2fa being used for everything, but it's a good first step.
I am in favor of crossplatform solutions like YubiKey. Apple and Google passkeys are lame.
Passkeys follow the 3-2-1 backup rule, just like any other digital data. The main difference being that you don't need to backup the passkey itself, just have multiple passkeys.
Have 3 passkeys
2 of them on-person at any time (e.g. one on your phone TPM, one on a Yubikey)
1 of them off-site (e.g. keep a backup Yubikey at home in a fireproof safe, or use a 1Password passkey, depending on your threat model)
Whenever you sign up for a new vendor/service, register all three passkeys with your account.
I do follow this. Unfortunately, it leaves out one glaring flaw: you can’t register a Passkey you don’t physically have.
I use four: an Apple Passkey, a YubiKey I keep on me, a YubiKey at home, and a YubiKey in the bank. When I sign up for a service, I need to register all four of them. Not only is this generally a bit of a pain in the ass, but it also means I have to remember to go fetch the one in the bank vault periodically and update the credentials.
If I could save a stub locally that would let me register with a key not in my physical presence, that would go a long way to making this more usable. Even better would be the ability to register a bundle of them all in one go without having to do it four separate times.
As it stands right now, it’s hard to recommend to users who don’t understand or care enough to take all of these steps. Which to be clear is entirely reasonable on their part. It’s an unacceptable amount of work and mental accounting for it to be something the average person can do without high risk of losing their entire digital identity.
> "glaring flaw: you can’t register a Passkey you don’t physically have."
I have Yubikeys and find this frustrating.
Is there not a technical solution that should've happened by now, or is it not as simple as I'm imagining: can't hardware passkeys have a way to export whatever it is that's needed for services to register them (public key/s?) such that if you have 4 keys you can export 4 files to your PC and and time you create an online account just provide all four files at the same time to be registered?
I guess maybe it's not as simple as being a public key that can be registered without the key being around, some sort of active challenge/response needed as part of registration? Or is my imagined solution above completely workable and just overlooked so far?
> I have to remember to go fetch the one in the bank vault periodically
I feel you, but I don't think Average Joe's threat model requires keeping a Yubikey in a safe deposit box (this is besides the issue that safe deposit boxes are less safe than you think: https://www.nytimes.com/2019/07/19/business/safe-deposit-box... ). A cloud-based passkey (like 1Password) is fine as the off-site backup key for most people.
> A cloud-based passkey (like 1Password) is fine as the off-site backup key for most people.
You're probably right, but this is still new enough that I'm nervous to rely on that. If 1Password has a data-corruption incident and you don't have other passkeys, there goes your digital identity. 1Password (or Apple Keychain) plus two YubiKeys is almost certainly fine. But that does still now run into the pain of registering multiple passkeys.
To be completely honest, I sometimes wonder if it's borderline malpractice that sites allow registering only a single Passkey. Registration processes should fundamentally require you to onboard two of them at a minimum, and encourage three. Or maybe I'm just becoming curmudgeonly as I get older. But I do worry that the current state of things—while absolutely on the right track—is going to be an unfolding disaster for non-savvy early adopters.
I will say that for Google's Advanced Protection, I was convinced having a recovery phone added was okay.
I just have a hardware key on my key chain and one on a pretty fireproof safe (which I got for other reasons). But I still added a phone recovery just in case.
As I understand it, the recovery process will always wait multiple days while sending many emails to me that it's been initiated.
I moved quite a bit of logins to Passkey and I chose to stay with the Apple ecosystem as my Passkey Lord/God. So far, it has worked and I have moved between devices (desktops, mobile, and the in-betweener).
Assuming I’m going to stay for quite a while with the Apple Ecosystem, am I doing it wrong by making my Passkeys pass through my Apple ID?
For instance, I change my eSim or number or replace phone, won't accept next time I login and then verify from the laptop, desktop, iPad, watch, or, heck, the Apple Polishing Cloth? (Assuming the cloth will become a smart cloth eventually).
They are when using a third party password manager like 1password or dashlane. At least in they are device agnostic. Haven‘t yet tried to export a passkey to another manager.
Why do you believe that introducing support for passkeys inherently makes the situation worse? If you don't trust them, you're not forced to use them; traditional methods still exist.
In any case, you should have multiple methods. It could be passkeys on multiple devices. It could be TOTP, plus recovery codes in a safe. Passkeys are just one more method.
For the longest time, the gold standard for authenticating people has been tamperproof hardware with keys that cannot be copied. Except iPhones actually have credible biometrics on top of that. Much better than Yubikeys, for example. Of course you always need to have at least one backup device or other method in case your primary device is lost. Now that this is finally making it's way to the “normal people”, it's suddenly a “run away screaming” scenario? Come on.
Yes, the security industry is probably going to shift massively to Passkeys over the next few years. Phishing is a massive issue for enterprise security, and Passkeys basically completely fix it.
IMO, this also means the problems with Passkeys will get fixed pretty quickly. And given I can already store my Passkey in 1Password and then use it on every device I currently use (including Firefox on mac/windows and iOS Safari), it's honestly not a huge problem.
I think passwords are a much bigger problem for people. Simple/re-used passwords are still incredibly common-place, and too many people don't realize how big of a problem that is. Once you incorporate a password manager so that you don't need to remember passwords... Passkeys via a password manager should be even easier to use, given you don't have to rely on browser extensions auto-detecting input fields.
How do you secure 1Password? With a passkey? See the loop?
Or a password? Wait, didn't we want to get rid of passwords? How is that any better?
The kinds of people with reused passwords all over the place won't use 1Password. And if you do use 1password to actually generate strong passwords you don't need passkeys and it works on all kinds of services without those having to support passkeys.
it's better than a password because good passwords pretty much require to be generated by password managers in this day and age. Which means you can't actually remember them anyway, yet a password is still hackable or guessable Theoretically of course but not really, I've had some fairly long passwords of mine hacked somehow. I assume because a service stored them in plaintext and then got hacked. Make it 40 or 50 characters long, it doesn't matter: It's still just text and it can be stolen from you by remote, digital thievery somehow.
The promise of passkeys is that this cannot happen anymore, they'd have to steal your physical device AND your way of unlocking that device. Sure you still need a master password to unlock your password manager but like I mentioned above: You now need this any way because you need a password manager no matter what.
Cloud-based backup storage – contained configuration data, API secrets, third-party integration secrets, customer metadata, and backups of all customer vault data. All sensitive customer vault data, other than URLs, file paths to installed LastPass Windows or macOS software, and certain use cases involving email addresses, were encrypted using our Zero knowledge model and can only be decrypted with a unique encryption key derived from each user’s master password. As a reminder, end user master passwords are never known to LastPass and are not stored or maintained by LastPass – therefore, they were not included in the exfiltrated data.
In other words, the thieves went to the bank vault a d stole your safety deposit box but can't access it because they need your key, which only you posses.
If I can store my passkeys in 1password (or lastpass etc) then nobody needs access to my physical phone. They just need access to my password manager's password.
I agree that for many many people password managers are way better than alternatives. But they don't magically make everything safe.
It's like MFA. "it is all safe now because we will send you a code via SMS" and the people fall for social engineering attacks that make them disclose the code the attacker just had the bank send to them.
I doubt such people will be a le to safely use a password manager or passkey for that matter. Passkey are just new enough that we have not had widespread news about how crooks were able to find the weak link(s). Probably on the human side again like in many cases.
well I really thought that the whole point of passkeys was that they are tied to the device. Syncing a passkey should have only meant that you have a backup, not that you can actually log in from a totally different device with that other device's passkey...
What is the point of a backup if I can't restore the backup to any place my choosing? The point is that if my device get lost, stolen, dies or is damaged irreparably I can always just use another device, restore my backup and done.
So even if there is some sort of hardware tie in that only ever works with real hardware an attacker just needs hardware. Or virtual hardware I guess ;)
Totally out of context parallel: Pokémon Go. A game that gets you out into the world to find and capture Pokémons and talk to other people. Or spoof your GPS coordinates with a simple SDR setup. No anti-cheating software on the phone will ever know.
> IMO, this also means the problems with Passkeys will get fixed pretty quickly.
Apple and Google do not quickly fix things when users have no alternative in my experience.
> And given I can already store my Passkey in 1Password and then use it on every device I currently use (including Firefox on mac/windows and iOS Safari), it's honestly not a huge problem.
For you. You believe the criticisms are dishonest?
If passkeys evolve by enterprise requirements it sounds unlikely you'll be able to ever properly export your keys. Instead, you'll get forced attestation to make sure you're not using Linux or some other untrustworthy platform.
EDIT: I assumed passkeys refer exclusively to hardware passkeys, mb.
My answer below means separate HARDWARE "security keys", not ones tied to a smartphone, Google or Microsoft account...
The problem here is that you are assuming one passkey. Just like you don't get just one key for your door its risky to get only one passkey, if you are planning to use it exclusively.
Passkeys are like normal keys but for your digital life. They have many benefits over normal keys like being impossible to copy/pick while still being easy to replace (as long as you have one that works) and if used properly (with a short pin-code) someone who finds or steal your key cant log in to your virtual doors anyway. They compare even better to passwords.
Just get one for your keychain and one to put at your stationary computer at home. The only thing to remember is to add both to your account(s), which still is faster than fiddling with your password manager and/or second factors.
Passkeys are really amazing, the only thing(s) remaining is to stop confusing people with terminology, explain that you should have a pair and for services to start properly using the keys as a combined first+second factor with a pin (which you can have safely the same on all your passkeys, in contrast to passwords).
What do you mean not cross-vendor transferable? You can use any brand key that properly implements the protocol (fido2/webaunth), and replace them with any brand key. If you mean copy them, well yea that's kinda the point..
There are plenty of ways for recovery on reasonable services, sometimes they ask to set up way to many (and with multiple passkeys, recovery is only relevant if you loose ALL of your keys).
Just want to point out that if your missus had a pair of passkeys there would not have been any issue!
That's the reason i have 2 devices with my accounts and auth app. One is for daily use and another one is a backup phone in case something happens to the first one
For that reason I don't want passkey. Password and regular 2fa/totp are fine... when setting 2fa I put it on my phone and my computer and another password vault on rpi... granted, everything still in same location but still somewhat better. I'm not really sold on esim neither - regular sims let you pop and swap them easily... why complicate it?
This might feel true, but it's factually not true.
Both passwords and TOTP can be phished. In addition, passwords can be weak, reused, and password hashes can (and are frequently) stolen and cracked in server breaches.
Passkeys are guaranteed to be strong, unique (can't be reused), strongly phishing-resistant, and there's nothing worth stealing from servers (just public keys).
Passwords and TOTP are not fine, they're both fundamentally broken when you look at them in the context of the modern internet attack landscape.
If someone is ignorant and (Re)uses weak password then it's own fault. Yes, phishing can happen but it's more convoluted (and again - lack of attention). Being conscious about it brings the benefit of not relying on single point of failure...
years ago i was robbed in dc of my phone at night on the way to a concert. i use google voice and was able to login at cvs to contact a friend to meet me there. in 2023 i would have been locked out by not having a 2fa or phone
While I believe this is a step in the right direction. I have read too many horror stories of people who were locked out of their Google and iCloud accounts with no real possibility of getting back in.
I don’t think I am alone in thinking I am on borrowed time. Someday, probably due to my own fault I will be locked out of Google and my digital life will be over.
If a private company can offer a similar login method like login.gov and let me talk to a real person when I am locked out like the USPS, I will be screaming shut up and take my money.
Especially for normal and older folks and Google's history of very non-existent support. Not to mention that passkeys is a flawed system as well. [1] [2]
AFAICT, the flaw is that passkeys are tied to device security. If I steal a naive person’s phone at the bar, and if I can guess that their PIN is 1234, then I can get into their Google account.
The criticism is based on the idea that most non-techie folks are unlikely to use a strong PIN and are unlikely to set up strong biometrics. There’s a related criticism about malware being able to steal passkeys on PC-based systems.
If someone steals my phone and guesses my pin they already have access to my Google account because I'm signed in. To look at my email they just have to click on the gmail app. This "flaw" exists regrardless of password or passkeys
Won’t most people be logged into their Google account anyways? So if you steal their phone, and guess their PIN then you can just use the already logged in account.
Certain account changing actions cannot be completed without the password. But if you have the phone (session, sms, passkey), you can reset the password and it's off to the races.
What are the odds that someone with a passcode 1234 is 1/ already signed into Google on their phone or 2/ has their Google password already saved in the device password manager (since it asks you to save it every time you sign in) which is also protected by the device pin?
At least in this case the thief has to steal the physical phone instead of guessing "password123" on the google signin prompt from the comfort of their home.
Also- how many non-techy people do you know that avoid using on-device biometrics? On my end, the number is approximately 0.
The point is that the odds are very high, i.e. if you've stolen their phone and know the PIN, you're very likely already in their account, passkey or no passkey.
Don’t try to argue that on-device biometrics are a foolproof solution to this. Even at it’s best you can unlock a device from a sleeping (or drunk or naive) user which just brings us back to the same issue: already being logged in to a passkey service.
> The criticism is based on the idea that most non-techie folks are unlikely to use a strong PIN _and are unlikely to set up strong biometrics._
On-device biometrics are typically _also_ used to unlock the device password manager, so my other remarks still apply. I bet a sizeable portion of the HN crowd also uses biometrics to unlock their well-configured password managers on their phone.
At least, that's what I personally do. Entering my very strong vault password every [lock duration] on a touch keyboard is already irritating enough; I'd rather just look at my phone to unlock my passwords when I need to use autofill.
Most people have _extremely_ weak device security. 0000, 1234, DDMM of their birthdate, etc, you probably cover the majority of people.
And none of that helps you when someone robs you of your phone and says tell them your unlock code or they’ll stab you. Now they’ve got all your passkeys too.
They also have your phone so they have text messages, email access, Google auth access, etc.
So yes it is true that your phone and it's pin/biometrics are ultimately the most important thing for security. But passkey on your phone is no worse than the previous state.
Disaster recovery. This is 100% my biggest worry with 2FA/MFA. I also think this is one of the reasons stuff like PGP never took off (don't @ me regarding perfect forward secrecy): the problem has always been managing some little, precious thing and the ramifications of what happens if it put beyond use or is used by some bad actor.
I'm from Brazil, where as is known many robberies and assaults happen on the street, and ever since the whole process of putting essential life services into smartphones started, many people are adopting a scheme of having 2 smartphones (if not 3 or 4 for other reasons! ) :
1) The House smartphone → it is where you install everything truly vital, like the main bank app (started mainly because of this), 2FA apps like authy google microsoft equivalents, passwords, streaming apps (to do their 2FA), etc. This phone NEVER NEVER leaves the house, except ONCE if the bank app requires on location authentication of the phone for the bank app to function, which is common practice with traditional banks.
2) The Street Smartphone → you essentially create a ''street bank account'', deposit sufficient money for day-to-day transactions for some days or weeks, install the app, and only keep this app installed for any money use (many people also avoid even using the same bank as the main bank app, as the main bank usually is a traditional bank with physical locations to get help - and has tons of personal information stored - and the street bank usually is a fin-tech bank that people do not really trust like old banks, either economically or for security, but it has less personal data anyways). It also has the essencial social media like Whatsapp, instagram, some password manager like bitwarden or the apple-google cloud, and 2FA (the ones who actually use it) is avoided in this device.
3) the thief smartphone → many people like to take some old phone around to give to a thief if the need arises, this way even the street smartphone is saved. Might not work if the thief smartphone is too old or clearly broken though.
4) the work smartphone → the only mostly chill 2nd smartphone on the list, useful to keep private life separate from the professional life, and also is useful to avoid the boss sneaking into the worker's private life and devices. There was a scandal here when a provincial government out of the blue installed a whole app in the smartphones of teachers AND students with no warning or any control whatsoever, and many people got scared that the administrative google service app being used by all (google education or some s*t) pretty much allowed the devices to be remotely controlled and viewed by the employer , be it private or public, so many people assumed any work devices is or can be done the same.
"... This phone NEVER NEVER leaves the house, except ONCE if the bank app requires on location authentication of the phone for the bank app to function ..."
Can you elaborate ?
What does this "on location" process look like ? What do they ask you to do ?
Not sure what he means, but some banking apps in Brazil have a "geofencing" feature like "only allow transactions when phone is inside this area". Presumably you set your home and work addresses as trusted.
Pardon for the delay. I'm surprised , i did not know this was not usual in other places. The biggest bank here is Bank of Brazil (state bank), and it has a lot of local physical sites in all over the country, with multiple units in bigger cities. A client ALWAYS has a main physical unit associated with their account, according to the address, and the person is required to physically go there to do many actions. There is a 2nd floor or rear area where there is a few bureaucrats or even the local manager, and the client has to appoint a meeting with them (usually by entering and waiting in a line at the moment, no internet pre-arranged way) to do stuff like big financial transactions, close or open the account, buy dollars or euros, seek advice about and start to use financial services of the bank like insurances retiremensts, etc. The front area of the 1st floor is where the money machines are located, where people usually get physical cash, pay bills, etc. The person has to use both a fingerprint and a password to authorize the operations, and of course there is cameras both in and out of the bank registering everything, and usually morning to afternoon there is a local security staff of 1 or a few (depending on the unit size).
Now with the context, finally to the on location authentication mechanism: The client can download the bank app, and login, but to actually DO anything in the app, the client first has to physically go to her-his main physical unit with the smartphone to be used, and go to a money machine. There, she-he has to login in the machine using both the fingerprint and password, and do the operation of authorizing the smartphone to be associated with the account, confirm by SMS on the smartphone, and voilá. ONLY NOW can the bank app properly be used.
That is why i called it 'on location authentication', the client has to go personally with the smartphone itself to a physical unit in order to authenticate the phone , so that the bank app can be used.
The fin-tech banks by contrast are 100% freestyle in every way, having no physical units and not demanding any sort of protocol to do equivalent actions, and that is loved by many, but there also the issue of less security, even much less security i dare to say, which was proved by a history of many crimes and frauds happening now that used them as instruments. Many people were victims of fraudsters that created bank accounts in their names exactly in these fin-tech banks, and did shenigans like taking 5 digit loans, buying physical goods, etc.
I'm guessing it means you have to walk inside the bank branch, and show ID and your phone with the installed bank app to an employee who somehow authorizes the phone to use the app?
Even that doesn't seem like enough to me. You need not just multiple devices, but multiple distant locations. A fire, flood, car accident, or theft can result in the total loss of multiple devices unless one is sufficiently far away and also secure. Then there's keeping that remote device up to date. This is beyond the patience, finance, and understanding of virtually everyone.
Total security does not exist, as the saying goes. These are several counter-measures that emerged in the social sphere of common people, to increase security a few levels and hopefully avoid the worst scenarios at least. I don't think almost anyone has all 4 smartphone categories i listed, but if you ask around, most would recognize the measures you are talking about.
A disaster scenario in practice means you are screwed either way here, tons of physical documents can be lost or destroyed too, but that is a calamity that by definition is exceedingly rare.
Most are worried about common thiefs, a scenario of robbery or assault that can happen anytime anywhere and frequently, repeatedly. The overall threat here is far larger that the rare scenario.
Now, to the complexity.
Usually the thief smartphone is some old phone still around, might not even be working, and no one puts anything in there, it is literally a throw-away device. It has no complexity or hassle, and usually is free.
The house smartphone, people usually repurpose some old smartphone or buy a cheap android. I still have an iphone 6 for this purpose, and if the app is up to date, it usually is safe enough. People will not be using the phone for anything else, it will not leave the house, so exposition is severely reduced.
Gopass is my current solution. Easy to sync and move around (it's just git), supports OTP generation, everything is encrypted by GPG. I have at least three devices in separate locations with it, so my DR is covered (and I exercise it frequently).
I personally use Bitwarden, the self-hosted version. My phone, computer, laptop all essentially have the passwords and OTP synced from my server running it. Gopass seems to be quite a bit less user friendly so Bitwarden may be a better solution for a lot of people I think.
I feel okay with Authy because I've got synced across multiple devices; one I bring out into the world and one I usually don't. I would be pretty nervous if I didn't have a second eligible device though
There are some Google Authenticator replacements that have an export function (eg. Authenticator+ on Android, although I'm not sure if it's still maintained). You give up a bit of [theoretical] security for a whole lot of DR insurance.
"You might get locked out of your account" is the updated version of the old "Your hard drive will crash."
It isn't a matter of if, it's just a matter of when. Backups and a thorough disaster recovery plan is absolutely mandatory for anyone who cares about their data. Some company is going to mess something up due to no fault of your own. It is inevitable.
Unfortunately, there aren't good disaster recovery options for some aspects of lost accounts, but having multiple accounts and avoiding single-points of failure help some.
My thought on this is to involve notaries. As in you can get a notorised account. And if something goes wrong you can get a notary in the loop and by law the providers have to fix what ever has gone wrong or they are liable for actual and statutory damages.
Imagining pessimistic scenarios is useful if it spurs action. In this case, appropriate action would be to learn about Google's account recovery options and take advantage of them. Make sure you have multiple, independent ways of logging in. (For example, by printing out backup codes and keeping them with your important papers.)
But even this can't protect against getting locked out of your Google account due to some Google policy change, so ideally we'd rehearse how to get by without it.
I haven’t heard of people getting locked out of iCloud. Losing all your devices nukes E2EE stuff, but that’s not much stuff by default. In particular, photos, device backups and messages are recoverable.
I thought the Apple Store would check your driver’s license or whatever and reset your password, recovering whatever is protected by the escrow keys.
I know Google loses accounts all the time, mostly thanks to “surprise 2FA” combined with zero tech support. I’d believe Apple screws this up too, but I haven’t heard any anecdotes.
Modulo the whole privacy/vendor lockin issue, passkeys are not a terrible alternative to people without 2FA reusing the same basic password on every single website.
However, when you actually rely on it to secure things, it quickly becomes a massive nightmare - made even worse by it being treated as equivalent to password+2FA.
> made even worse by it being treated as equivalent to password+2FA.
passkeys are significantly more secure than the most widely-used/most popular forms of 2FA, because the most popular forms of 2FA are TOTP and SMS, and both are subject to phishing attacks. A passkey alone is much more secure than the vast majority of password + 2FA combinations.
The only thing stronger than a passkey standing alone is a Security Key, but Security Keys come with a lot of usability downsides that can easily bite the average user, including:
- inconvenience: you have to remember to carry it around with you everywhere (and not lose it!)
- recoverability: you're completely screwed if you lose it and don't have extras that you already previously added to your accounts. (this also means that you need to buy at least two security keys to have a decent recovery story.)
- rotation (have to log in to every single service, one by one, to re-add new key if you change keys)
And if you really want the extra security that a Security Key provides, you can use a Security Key as a passkey.
Blanket statements like this demonstrate a misunderstanding that "security" is just one thing in a single lineal scale.
In reality you have to ask, secure against what? And to answer that meaningfully you need to a thorough threat model for the specific use case of person P and account A.
The same person P will have a different threat model for every account they have.
The D in STRIDE is for denial of service. Passkeys are much worse on this axis than any other solution. You need to evaluate for the specific combination (P,A) how much this matters vs. other criteria.
I don't think this is correct. It's more difficult to steal something from me than to, e.g. repeatedly force password reset emails. From a ux perspective, it may be easier to accidentally kneecap yourself with a passkey, but security wise, they're still probably better since it's harder for someone else to kneecap you.
I'm not sure why you didn't include the rest of the sentence, which made it clear that I was making a very specific comparison to password + phishable forms of 2FA. I was very clearly not making a blanket statement.
Here's the full context again:
passkeys are significantly more secure than the most widely-used/most popular forms of 2FA, because the most popular forms of 2FA are TOTP and SMS, and both are subject to phishing attacks.
>The D in STRIDE is for denial of service. Passkeys are much worse on this axis than any other solution. You need to evaluate for the specific combination (P,A) how much this matters vs. other criteria.
How are passkeys (really, WebAuthn credentials in general) any worse in terms of denial-of-service attacks than passwords?
I think you're trying to make a point about specific passkey/password managers, rather than the actual credentials themselves. Is that accurate?
It seems like his argument is that putting access to valuable accounts on your phone is a bad practice, because if your phone is stolen at the club after the thief watched you enter your code, then the thief can get at your banking, brokerage, crypto, password manager, etc.
But that argument doesn't address how passkeys somehow make that worse.
Sure, if you don't want your valuable stuff stolen, don't put it on your phone. But that's a problem whether you use passkeys or passwords or passwordless links sent to your email or SMS.
The point is that the phone with a crappy 4 digit pin can be used to authenticate everything on every device the user owns that uses passkeys. It's a one stop shop of failure.
The argument is that without your phone, you likely have no recourse to stop the attack. Since your passkey on the phone is what controls your access, now.
To me, it's unclear what the headache is. If the argument is about the consequences of passkeys for most ordinary people, most people are signed into their google account on their mobile device. In that case, your account is compromised anyway if your device authentication is breached.
For Google in particular, password/passkey isn't a binary choice(currently). You can fall back to the password sign-in flow if your device doesn't have a passkey.
This debate is frustrating because it lacks data — it's full of opinions about which risk is worse than which other.
To compare the risks and benefits, we need to know how often people actually re-use passwords, use 2FA, rely solely on their phone screen lock for access to all their accounts, use biometrics, need account recovery, and so on. That data is the only way to settle the debate (and would allow each person can settle it for themselves, perhaps differently based on their circumstances).
Google has most of this data. They should publish it to back up their claims.
The fundamental idea of using asymmetric cryptography to authenticate is good. It is time-proven, and it works in the best interests of users, simultaneously providing improved security. SSH just works (and while it typically lacks fancy UIs for key management, it's irrelevant to the core idea).
The passkeys design, though, has a number of obvious deficiencies and limitations. It is drastically better than ye olde <input type="password" /> but it's not a good standard.
The other alternative is SRP, but no browser vendor had bothered to do anything about this, so it remains a curiosity implemented on a couple websites (with all JS crypto gotchas, so - no good).
1Password enabled PassKey support recently and I was "surprised" to learn that there is no way of exporting them out of 1Password. They're not included in the 1PUX format export, nor in the CSV.
That means that they're literally impossible to back up. If 1Password goes down, or the company stops operating, or anything else like that, your Passkeys are just... gone. Absolutely no way to recover them.
Currently, none of the big players in the passkey space support exporting or importing of passkeys, because the spec for doing this securely has not been agreed upon, and nobody wants to allow plaintext export of passkeys.
Re. your point about 1Password going down: Your passwords and passkeys are all stored locally when they sync to your devices. If 1Password becomes unreachable for any reason, you still have access to everything in your vaults, you just can't sync between devices any more.
I guess "100% secure against phising" is incompatible with "the user can in any way access the key" because if you knew the key, in theory some super-convincing phishing site could get you to spill it.
I still think the real reason is lock-in, but I could imagine this is their official justification.
Given all of the horror stories (some real, some hypothetical) told in this thread, it seems that one of the major side effects of passkeys — if not the primary purpose — is to keep you locked into whatever you used to create your passkey. Plaintext export would ameliorate that.
Passkeys are supposed to eliminate the need for companies to store a password so we no longer have to deal with the fallout of 40 breaches a year. In order to export passkeys it has to be in plaintext at some point, even if encrypted once again into the export file. Point is, one of the huge selling points of pushing people to use passkeys is the portability and lack of vendor lock in yet here we are with choices that are all currently vendor lock in.
Can you, though? passkeys.io does not showcase this. The default assumption from every vendor is that you'll use their passkeys and they don't care about anything else. It's a very explicit silence, no "official" resource from any major vendor addresses cross-platform portability.
Yes, some individual implementers recognize the issue and have "log in with another device" (which is the best option you can have, although still quite clunky), so you can solve the chicken-and-egg problem of logging in on another platform's device to add your another platform's passkeys. But to best of my awareness, this is not a part of any standard or recommendation (it should've been).
And other implementers do the contrary and artificially limit your options so you can't add a portable authenticator with them without some hacking around.
What are the vendor options though?
(I think) its Google, Apple, Microsoft, Yubico and 1password?
None of which support exporting the keys as per other comments in this thread.
Isn't that the point of Passkeys? The user isn't allowed to interface with them directly, so social engineering can't compromise them [1]. Rather than move your passkey between devices, you're meant to generate a different passkey for each device, then register all of them with the relevant service, like SSH keys.
1: of course, a user could still be tricked into adding an attacker's passkey to their account or something
The major problem with passkeys is that first they were poorly designed so there's no portability or ability to enroll an offline (or worse, physically unavailable, like stored in a safe) authenticator, then there's this kludge to work around the limitation.
It was obvious from day 0 (to anyone except for Apple and Microsoft) that people do have multiple devices and not all of them are from a single vendor. My only explanation is that they deliberately decided to ignore this aspect, because it wasn't in corporate interests.
They made it significantly easier to lose all the passkeys, because they made it very hard to add multiple passkeys (you literally have to walk/run/drive/fly and grab every different device you have, get it online and register - or get properly locked in with a single vendor and pray they work for you, forever).
Carrying a Yubikey does not work (you can lose it). iCloud/Windows Hello does not work (you can be on a non-Apple/Microsoft device). 1Password is better but still does not really work (you can lose access to your account). They're all SPOFs, and avoiding SPOF was deliberately made hard (you can't easily enroll a "backup" Yubikey that you don't have at hand, and if you have it at hand it's not a backup anymore).
Heck, "official" demo at passkeys.io doesn't even bother to showcase how multiple passkeys are going to be a thing at all, which is an obvious red flag.
That is, not to mention that a growing number of vendors contributed to the crappiness by limiting what kind of authenticators and which platforms one can use (BestBuy, PayPal and so on), contributing to decreased security and increased headaches.
The "forgot password" flow involves accessing your email. And accessing your email without having access to your passkey requires a device that has previously logged in to your email. And the device that has previously logged in to your email is the same device where your passkeys are stored, which is to say, the same device that is now lost or bricked, which is the reason your passkeys are lost in the first place.
And sure, you and I have multiple devices. We're in the minority. Most people just have the one. Without another way in, they're irrevocably fucked.
Do any of the third-party, self-hosted password managers provide a compatible passkey implementation that can actually be exported and backed up in a secure manner?
1Password's Passkey support feels very aggressively growth-hacky to me. They intercept calls to `window.credentials` and if you want to use 1Password along side other verifiers like Yubikey, you need to go into your settings and disable their passkeys offering entirely. It's similar to how they also intercept (and globally disable!) Google One Tap prompts in order to show their own OAuth prompt. I only use their Chrome extension so I'm not sure if the native app experience is significantly different.
I'm kind of mad at 1Password - but this isn't correct. When the 1Password prompt some up, you can click the little "USB key" icon which ostensibly is for hardware keys, but all it does is pass control back to the OS, at which point your iCloud prompt, or whatever provider you are using, can be used.
Is version 8 reasonably mac-like? On 7 it's still a mac application that acts like a true mac application (drag/drop works properly everywhere, expansion, properly keyboard-enabled, etc) which is well nigh impossible when running inside a chrome box.
Agile Bits support kept insisting it was the same as the old native app and people kept complaining about bugs until I stopped following it.
It's as Mac-like as any other Electron app. Which is to say, it does a pretty good impression of a Mac app, but the bundle is 345M, with another 244M hiding in your Library directory.
It’s so rare that I use anything other than the 1Password Chrome extension that I couldn’t really tell you! The main app seems.. fine? But like I say, I hardly use it, so I probably wouldn’t notice details like you mention.
Do you have a different workflow where you use the main app a lot?
I keep a lot (including images) in the main app as an ecrypted shared resource for IDs and various other secure info. If I suddenly need my insurance card I can quickly grab it out of the app rather than rummage through the (unencrypted) icloud or dropbox filesystem on ios. And I can cut/past text out of the images. I also use it for logging into apps, dragging credentials into remote machines over ssh etc.
With 1password 7 whe safari plug in is more conveniently integrated than the chrome one which is pretty clunkly by comparison, though this is true of other chrome plug ins too. But that's not a big deal as I rarely use chrome anyway, just for google docs which don't need 1password.
This is a quibble, but if 1password goes down, your vaults still exist on all your devices and the app will keep working, it's only the syncing of modifications between devices that won't work.
Just happened to my in-law. She dropped her phone on the stairs, screen cracked, and became unresponsive. I gave her an older phone I had and swapped the sim fine. But she couldn't figure out how to log in to Google account because it was so adamant telling her to use her phone. Her laptop was logged out of her email, etc. Fortunately I have backup tokens for her from a previous incident heh. I have no idea what other folks will do.
A few months ago Google wouldn't even accept backup tokens for me. I was on vacation, and that tripped enough fraud detectors to cause problems. I couldn't log back in till I got on my home network and changed my password.
Back in the old days with no 2FA and only username/password access geolocation lockouts happened every time I went travelling. You could regain access by getting a code from a recovery email, but that often got locked out as well!
Eventually I set up my own VPN server so that the services still thought I was using my home IP.
I don't know how Google solved this, but it's an old solution. Shamir secret sharing. You break apart your keys into M pieces, where you need N pieces to reconstruct the key, so let's say 3/8. Then you need 3 pieces out of the 8 pieces it's broken into to recover your key. You take each of those 8 pieces and give to trusted sources. When you need to reconstruct your key, you have at least 3 of those give you the key and you recover.
How does this look in implementation. When I Implemented this in multipasskey (YC demo). It would ask you to select contacts you trusted. Then it would send the sharded parts of the key in the background to them. If you need to recover, you make a request to them. It would reconstruct your device key when you got enough pieces. Once you have your device key, it would download your encrypted backup of keys from the remove server and you are back as new.
I called my project multipasskey in 2017/2018 and applied to YC with a working demo and they said nope. I'm going to assume that I sucked at selling it. ;-)
I had the same idea about a decade ago but never bothered to try to implement it. I felt like it would have suffered from the same problem all other technologies have in security: overly complex user interactions. The concept makes sense, but getting N other people to commit is overhead the average user probably doesn't want to deal with.
So I preferred the idea of regular folks for backup, for security reasons. I thought of the idea of professional users like say your bank or 3rd party. The issue is that it's far easier for the govt to subpoena those pro 3rd parties and recover your key. Whereas, they would have to know which of your friends you used for key recovery to be able to do that. The idea was to make it tough for a bad/powerful actor to steal your key. Of course, the challenge is that a non social person would need friends or to depend on ISPs, banks (pro 3rd party providers). My goal besides security when building this project was to break the chain of 3rd party auths (Google, MS, Github, etc) :-(. They use their auth as a way to lock folks into their ecosystem and if you offend them in anyway, you could lose access to everything. Offend Google on adsense and lose your personal photos/email. Offend Amazon on sales and lose your prime streaming/AWS access. Hopefully as the idea picks up, the monopolistic corps can be tackled again to remove such power.
I wholeheartedly agree with where you were aiming your goals. Other thoughts I've had:
- What if access is time critical but your backup people are distributed across timezones? Or they aren't available for some reason? Could be hours to days before you could recover your account
- Adding/removing people as they enter/exit your life could make it a challenge to maintain (PGP + trust vibes)
How? The usage was very easy. You select a contact and add them as your recovery contact (by selecting contact from your contact list) The system adds the key in the background. If they don't have the app, the app asks you to tell them to install the app (viral growth?). The users didn't need to know any thing technical. But install app, and click yes/no like they do with a 2FA app.
I think the challenge is more coordinating the 8 people who will be a trusted part of your life long-term. Also they’d have to be sure to keep their fragments of the key intact through replacing devices, etc, no? Seems like just keeping a Yubikey in a safe deposit box would be simpler.
If it is a safe at your home, you need to have a fixed home address in the first place, and the usual advice about off-site backups also applies.
If it is at friends or family, you’re back at the same problem.
If it is a rented deposit box, you need to trust the company you rent it from (banks don’t usually offer such services anymore, and there are risks like in [1])
I’m not in the crypto world to know why this is the way it is, but if you only need 3 pieces out of the 8 to reconstruct the key, why split it into 8? Is it to have a larger pool should you need it/higher odds of being able to gather 3 should some pieces be lost?
To add, it is pretty poor there is no FAQ linked to from that post to answer basic non-technical questions as to how this is intended to be used.
I assume as a technical person, the answer is I should have a backup device with a friend and/or store my passkeys somehow on my Apple or Microsoft or password manager account as well.
But it needs more explanation in detail from Google!
So now that "friend" has access to your account? How is that more secure than my 32 random character password I store in an encrypted Keepass database that I back up offline?
You can try this: https://support.google.com/accounts/answer/13548313?hl=en, this help center page is linked to from various parts of the product experience for regular users to get a better idea about passkeys if they are interseted.
You have a valid concern, but I'm curious how many sufficiently non-technical users would be reading Google's blog. Practically speaking, it could be a moot point.
I had a fire. I lost every single thing I own, except my landlord grabbed my phone, bless him. Otherwise I would have been totally stuck as all my TOTP apps are on there.
Also, never lose your phone number. I can't get back into my Google account even though I have the username, password and recovery email because I can never get the SMS code.
> Also, never lose your phone number. I can't get back into my Google account even though I have the username, password and recovery email because I can never get the SMS code.
This is an excellent point. Google seems to be uninterested in addressing this transparently, but despite their push for phishing-resistant MFA and first factor sign-in options, they still consider a phone number to be golden evidence.
My father changed his phone number last year and never updated his Google account. Despite having a recovery email address he could access, TOTP, and printed backup codes, it was not enough. Google wanted to “verify it really was him” after a move (and IP address change) and it doesn’t even allow a password reset to be authenticated with any other recovery option. Phone number or bust.
I have heard and read about a number of similar cases where people can get completely locked out of their account despite being able to authenticate correctly, because they lost access to some other required resource that Google decided is essential. I'm very skeptical about the utility of these types of security policies. I'm sure they prevent hacking in some cases, but they also greatly increase the chance of a legit user permanently losing their account which is a pretty freaking bad outcome for someone who has all of their email, messages, photos, documents and more stored in their Google account.
Given the importance of these digital services I expect that refusing to provide support to users in this situation, as Google is well known to do, won't be legally tolerated at some point in the future. Unfortunately this won't be changing anytime soon, so the best we can do is inform others about the risks of relying solely on Google for anything important and hope people backup what they can.
Especially when they migrate previously password-only accounts to requiring what they think your phone number might be, and especially given that it costs under $15 to borrow somebody's phone number for the day without their knowledge.
I need to find one of these services so I can borrow my old phone number for a few minutes to get back into my Google account before it is erased at the end of the year in Google's oncoming purge.
Have had to recover from 0 pretty similarly. My backup approach basically started with the fact that I knew the password to a cloud storage account that I had uploaded a keepass vault to, and that keepass vault had the password to my primary backup provider. In a full no passwords world, I would have had no chance to do so.
Getting locked out of a Google account because I didn't have the number anymore happened to me too. Even though I had everything else even backup email verification, password, etc. Was a massive hassle.
In my country my phone number is linked to my government issued ID so I don't need any physical properties to recover it (this might take some time though but for me it's still the best option).
The solution would be to have a separate phone and phone number used solely for authenticating. It will never leave home, and never be used except to authenticate. Still vulnerable to home fire, however.
And what do you do when you go abroad and a web site says "Oh, looks like you are logging in from a new location - please check your SMS for a PIN now" :(
If google thinks your login is suspicious, it will look for 2FA. If you don't have a phone number tied to that account at that time, it will insist you add one.
This is not true. It will ask for a provided number if you've already provided one, but if you've never provided one, it'll ask for any number and treat that as the provided number for future reference.
> The claim that google will never insist you set up 2FA by providing them a phone number if their ML algorithms decide your log in is suspicious.
1) that's not what I said.
2) that flow you describe isn't asking you to set up SMS 2FA. It is asking you to verify an account with SMS. Likely because there is no other way for them to verify your account.
> Based on my own experiences with a little used google account and finding the messages of other users who have encountered the same error.
The number of people who've reported that error is super small. Even the link you provided is 10 months old. This must be related to an edge case of not having another 2FA set up.
> What is your basis for claiming that my position is untrue?
You said that it insists you add a number. I don't believe that is true. The example you provided does not show that is true.
Passkeys are a new technology and everyone - including users, service providers, and organizations - will take time to learn and adapt. In this interim period the recommended approach is to provide passkeys as an alternative to whatever is already offered. This is the approach that Google and many other service providers are taking.
That said, you are bringing up the right questions on the general topic of account recovery that everyone should be asking even without passkeys: "How would I login if I forget my password / lose access to my password manager / lose my second factor devices" and have a plan. Introduction and adoption of passkeys do not completely eliminate the need for thinking about your account recovery situation.
However, there is one special case where using passkeys is actually better for account recovery. If you create passkeys for your Google account on an Apple device with iCloud keychain, the passkeys are synched to your iCloud, so now even if you lose all your devices because your house burned down, as long as you have access to your iCloud account, you can just get all the passkeys for your Google accounts(and other websites).
Now, you may ask: 'what if I lose access to my Apple iCloud account" -> that's a fair question! Which is why I said Account Recovery concerns do not completely go away - but they can be significantly reduced with passkeys in many cases.
All those issues were obvious from the day zero, and raised multiple times by many people. They're deliberately ignored by the stakeholders.
They strongly want to lock you in to their own authentication platforms (iCloud Keychain, Windows Hello, 1Password*), that's why they don't want to address this.
It's impossible they're not aware about those issues. Anyone with a brain and some technical expertise would come up with those questions in an evening or two, and Passkeys were worked on for months. To best of my awareness, there is no official acknowledgement (support replies "no, you can't do this" doesn't count, that's just restating facts, not acknowledging an issue).
*) Ok, 1Password says they're all about user freedoms and that it's up to user to decide where they store their passkeys - but that's what they say, not what they do. What they do is indistinguishable from Apple and Microsoft.
Relevant excerpt for those too lazy to click through:
"However, it's also important that passkeys be recoverable even in the event that all associated devices are lost. Passkeys can be recovered through iCloud keychain escrow, which is also protected against brute-force attacks, even by Apple."
On account recovery, the user is strictly no worse off with passkeys relative to passwords and arguably actually better off in many cases. This is not what I'd call deliberately ignoring concerns.
Yes, but if you had to resort to recovery you’re already past Passkeys or passwords. Recovery is not exactly in either’s spec, it’s a separate matter. Saying “but recovery is the same” is pointless - sure it is, by definition, because it’s out of scope.
Passkeys make it more likely that you’ll have to resort to account recovery, because it’s explicitly easier to lose passkey access than a password access (assuming that all platforms that implement passkeys implement password management as well, and that every password manager allows “export” by showing password to a naked eye).
One can write a copy of their password in a notebook and use it from anything with a keyboard and network connection. This mechanism is built in.
Passkeys are explicitly worse in this regard, as they don’t address export at all. Some implementations may be at par, but the overall spec is strictly worse, as it fails to address number of obvious issues.
Firefox on Desktop tells me to "touch my security key". Not sure how that works.
Firefox Android gives me a few hardware options to store my passkey to.
Chrome Desktop asks me to enable Bluetooth.
Chrome Android asks which Google Account to use.
I use passkeys everywhere I find them. I do not take control or ownership of backing up - instead I have alternative 2fa or hardware key authentication with all those accounts.
For every account I have a hardware key for, there are 3 hardware keys associated with that account - 2 on-site, 1 off-site.
How do you register your off-site hardware key. Did you have to go retrieve it each time you wanted to make an account?
I suppose every time one makes an account one can register the two on-site keys, and then rotate one of your on-site key to off-site and take the off-site key home with you, and then finally register it.
I think you answered your own question! The three key is optimum for ease of rotating (or so you can carry one on person) - but if your house burns down with your phone in it - you will lose anything set up since your last offsite rotation.
Sounds paranoid / crazy - but I have 0 anxiety about being locked out of an account that matters.
Yubikey keys - zero difficulty adding multiple - if a site doesn't allow multiple I wouldn't lock my account down to a single point of failure. All the big players seem to offer it, and I can not recall any that didn't. Google in the "advanced protection" days forced you to have more than 2 keys for this reason.
By count of sites, most sites don't appear to take security that seriously so anything more than a password is off the cards, but the big ones - the ones that actually matter; email, cloud, etc. should all be able to be secured.
Password managers like Dashlane and 1Password have announced support for storing and synching passkeys. As passkeys becomes more popular I expect more providers to step up as well.
Ecosystem lockin is not how we make a new technology like this successful. And all players in the game understand that.
Appreciate the response. And I wish this message was front and center. The Attestation feature is what worries me, when, say, the bank turns it on for a few 'blessed' providers, or mandate a hardware implementation.
Passkeys represent the cumulative wisdom and experience (and compromises!) of the whole industry on how to keep users safe online. Appreciate your opinions that these efforts are doomed. It is safe to say, "We'll surely find out!"
No... A passkey is specific to a context (RP), which is why they're not stored on things like Yubikeys (which I think a lot of people in this thread are confused about -- the keying material on the Yubikey isn't enough to create the passkey).
Your Netflix passkey is not the same as your passkey to other services. It's generated as soon as you enroll the passkey with Netflix (by calling "navigator.credentials.create()") and is identified by an opaque handle and also the public key (this is important, because you never get the public key again so you must keep both of these: the ID, and the Public Key, otherwise you can't verify a challenge-response, since you're only given an ID and a Digital Signature at that point).
For a site to use a passkey it calls "navigator.credentials.get({ publicKey: { challenge: ..., rpId: "<same_id_as_used_when_creating_like_netflix.com>" }, mediation: "silent" })"
Which returns the key ID and a signed version of the challenge, or an error.
Everywhere you authenticate you have one or more keys, identified by these opaque handles which are stored in the User Agent and associated with some mechanism for performing digital signatures with that unique key. The User Agent, generally, has to store and distribute this information if you want to use the same passkey across multiple devices -- even if you're using a Yubikey (because, again, it's not storing the key being used for the digital signature, it's storing a private key which is used in the process of generating the digital signature, but not the passkey's actual private key -- i.e., the secret part of the public key generated earlier)
> Passkeys represent the cumulative wisdom and experience (and compromises!) of the whole industry on how to keep users safe online.
That is true _if_ you do not highly weigh all the concerns that have been brought up in this thread today. I do not trust Google to help if things go wrong so why would I ever consider such a system wise? Frankly, you seem to be ignoring concerns if they contradict your belief that this system is better. I'm reminded of Upton Sinclair.
> That said, you are bringing up the right questions on the general topic of account recovery that everyone should be asking even without passkeys: "How would I login if I forget my password / lose access to my password manager / lose my second factor devices" and have a plan. Introduction and adoption of passkeys do not completely eliminate the need for thinking about your account recovery situation.
Talk about victim blaming. Google and other companies introduce policies that make total identity lockout both easier and more problematic. Instead of investing in customer service to deal with this issue, the customer needs to "have a plan". What a crazy coincidence that this policy increases Google's profitability by decreasing support.
But you can set family members/significant others/etc as possible recovery mechanisms! This seems like a really workable solution that I don’t see people discussing in this thread?
> What is the account recovery process if I’m locked out and don’t have my phone, say it’s lost or broken and I can’t verify my identity?
> You can always fall back to legacy authentication options such as passwords and traditional 2-step-verification. In a case where you can no longer remember your password, you can also go through Google’s Account recovery flow. We encourage you to add your email and phone number to ensure you can always access your account.
Then what's the point of it all if a hacker can still get into my account using the traditional methods? This seems to be just opening up another avenue of attack.
If I understand it correctly it will avoid phishing, assuming people notice there's something up when they see a page asking for a traditional login for no good reason when they have passkeys. And it may be a transitionary step towards no passwords or something.
My Google account is set up such that account recovery requires me to actually travel to Mountain View and present several forms of ID, and that's just how I want it to be.
The scenarios for dealing with the loss of Passkeys are effectively the same as dealing with the loss of your Password Manager (if you use one) or otherwise stored passwords.
Dealing with the loss of all your devices that use Passkeys
If you manage to lose access to all your devices that are used to authenticate via Passkeys (e.g., a house fire), then there are two main outcomes: either you have your Passkeys synchronized to a cloud provider or other external entity that still has a copy of all your Passkeys, or you do not. If you do not have a backup of all your Passkeys, they are gone, and you will need to fall back to account recovery for each affected account. If you have a backup of your Passkeys, you would need to regain access to it on a new device and then synchronize the Passkeys to it and use them as normal.
Dealing with the loss of your accounts that synchronize and store Passkeys
If you use a synchronization service attached to an account, it is possible that the account can be deleted or access to it otherwise lost. In this event, you would most likely still have a working copy of your Passkeys on your devices, and depending on whether or not you can export them or reconfigure synchronization with a new account, you would be able to add them to a new account, effectively creating a new account to store and synchronize your Passkeys.
Dealing with the loss of all your Passkeys
If your Passkey account is not only deleted but also tells all your devices to delete the Passkeys, or you lose all your devices and the accounts are deleted due to inactivity then you are basically in the same situation as having lost all your devices and not having a backup. You will need to fall back to account recovery for each affected account.
This is accurate, but by putting your passkey backup with that external entity, you are putting all your keys in that basket. Passwords have an obvious, backup option with zero dependencies on third-parties: A printed list in a fire safe. I would not advise users go heavily with any passkey provider that does not provide a physical backup of a similar form that can be secured through non-technical means, and that can be used by an heir or attorney to act as you when you are unable to do so.
The problem with that is people don't have fire safes. Or homes in some cases (e.g. many unhoused people have smartphones now). Also people need to travel and do recovery without having to fly home to their safe.
The idea that printing a backup is easy and an option for many people is often not the case.
And that is why most people use a single, easy to remember password for everything: even if their house burns, their devices are gone and they no longer have their phone number, they can still remember their password.
For all of its many weaknesses, a password has that one major advantage over all the other authentication methods, and unless a new method provides a similar advantage, most people will keep using a password, just like they did even with the appearance of private keys, biometrics, USB tokens, SMS or TOTP.
And it's a hassle to keep it in sync. If you decide to update your password you need to remember to print out a copy and store it in the safe, oh and throw out the old one.
> (e.g. many unhoused people have smartphones now)
I go out on a limb and say one smartphone usually - that is at heightened risk of getting stolen. With passwords, the person would probably just pick something they can remember in case the phone gets stolen. With passkeys, what should they do?
Passkeys aren't inherently un-backup-able. I do agree though that the most common forms of it (e.g., Android/iOS/Windows secure enclave passkeys) need better ways of recovery and remediation.
That said, what you describe is easily doable in other forms. For hardware tokens, you can have a spare Yubikey that's authorized on your accounts and keep that in a fire safe with its unlock PIN. For something like 1Password, you can print out a recovery kit [1] with the secret key and unlock password.
I think you’ll still need a password on your account for cases where no passkey is available, and possibly for other scenarios of heightened fraud risk. That’s why the setting they’re describing in the blog post is named “Skip password when possible”.
Disclaimer: although I worked for Google many years ago in a role entirely unrelated to Google account authentication, I have no inside info on this announcement, could be wrong about what I say in the first sentence of this comment, and am not speaking for Google here.
I agree that recovery is an important question. Maybe they will make sure to prompt for a password at least every N months? I have no idea what their answer for this may be, but they probably have one.
And if I loose for some reason access to my phone number, termination of current number to create a new line with a new phone, I loose access to Gmail forever ?
Possibly. Security has made internet enabled accounts outright user hostile. Try helping a 70 year old guy get into his Gmail again. I despair over the disrespect Google and the other major internet corps show their tech-naive users.
I've heard "I'll call them" far too often, and am perpetually forced to share the bad news.
If they're in your Google/iCloud, you're already in a game over scenario. The point of all this is to prevent that from happening.
You can try to recover by revoking all your passkeys and starting over with hardware tokens, but that's likely what a sophisticated attacker is going to try as well, and they're probably faster than you.
How is that better than passwords? I backup my encrypted passphrase database to a cloud provider. When my house burns down and all my devices are lost, I get a new device, download my own passphrase manager app, download the passphrase document, and continue as before.
If someone breaks into the cloud provider and downloads my passphrase document, nothing happens.
If they break into my iCloud then they’re in my iCloud. They’re not in all my other accounts, because I use an encrypted password manager that isn’t iCloud.
Think of it as using iCloud as your password manager and storing your OTPs - someone breaks into your iCloud, they get access to all the passwords and OTPs to login to any service in iCloud.
Always take the security of your password manager / sync accounts seriously. Use hardwre security keys if needed on the "root accounts".
iCloud is unfortunately impossible to adequately secure for that use case.
If you shoulder-surf somebody's phone unlock PIN and grab their phone, you have everything you need to take over their iCloud account, including their passkeys and the capability of locking out all of the victim's other trusted Apple devices and changing their iCloud password.
This was very surprising for me to witness first hand – fortunately not in the identity theft scenario, but only when observing a relative regaining access to their iCloud account using only their iPad they were logged in on.
It is a fair observation. And I can see why users tend to be alarmed about this. Although in my experience users tend to significantly underestimate the real risks of online attacks relative to these more visceral threats.
Let met ask you: has that discovery made you stop using your iPhone, or storing passwords or other critical data in your iCloud? If the answer is "No", then you're strictly better off moving to passkeys stored on iCloud as well.
> Let met ask you: has that discovery made you stop using your iPhone, or storing passwords or other critical data in your iCloud?
Yes, it has (the latter). I was a big fan of (non-synchronized) on-device passkeys, but this has significantly changed the threat model for me.
I use a third-party password manager exclusively now, and I'll probably be using its synchronized Passkey implementation too if it turns out to be any good.
As soon as Apple starts offering a different set of security trade-offs (e.g. make usage of the recovery key mandatory when resetting my iCloud password, or at least implement a timed lockout), I'd gladly start using iCloud Passkeys and maybe also its password manager.
When you get a duplicate of your SIM card you can then verify it is you with a SMS code.
There are also security questions and alternate email you can configure just in case.
What’s the standard then? Should it be possible to recover your account without possessing any evidence whatsoever that you are the person you say you are?
Other businesses have humans on staff which will verify your identity documents. Google simply chooses not to do this, because it is expensive, and their "users" are not their customers.
Yes, remotely accepting a copy of an identity document from the other end of a wire is not a good authentication method. That's because they're not intended for remote digital authentication. Photo IDs are intended to be validated in-person, using the original document, and the photo visually compared to the person holding it.
I get a call from Google One Support. I explain the situation. They tell me to go to g.co/recover to recover my account (I already did this on my own). Same thing happens as before - same two options are given.
Then I'm told Google has a very strict security policy, and accounts cannot be changed in any way by support. So going through the recovery process is the ONLY way back into my account. So the call ends with them saying "I'm so sorry I can't help you." [1]
They have offered this since 2017, in response to the Podesta email hack. It's free, but it's not the default, because traveling to a Google site is prohibitively expensive for the vast majority of their users.
Is there something there that explains how the recovery process is different? The only thing I see in the FAQ is somewhere that they link to the normal account recovery page, and say that you'd have to order another hardware token.
I've been locked permanently out of a (thankfully tertiary) Gmail account because their ML didn't like that I logged in from my new house. The option was to accept a push notification to a long dead and wiped phone.
Their state handling for the push notification based MFA factors is _atrocious_. I have had to “re-delete” a long wiped phone (or two) multiple times from more than one account. It seems to have finally stuck in the past year, but I’m suspicious that one day it could bite me in the ass.
Given your response you should read up on the reality of Google Account recovery, because the usual horror story is not that you have "no evidence whatsoever" but more like "I have all the evidence in the world including recovery codes, TOTP backups and a valid password and somehow I'm still locked out".
If you travel in an other country and loose your phone or the phone gets stolen. How can you log into Gmail from anything else if you need access to travel or anything else ? Like receiving a confirmation of identity by email from the bank or another service ?
Despite what many companies seem to believe, looking at a copy of somebody's identification presented remotely documents does not constitute identity verification.
Photo ID is (relatively) secure in exactly one use case: Verifying that a person standing in front of you is who they claim to be. Everything else is inane pseudo-security.
Depends on the recovery mechanism. Providing a government credential with a live selfie is the gold standard. If a company doesn't support that, they're being cheap at the cost of security (you can perform such an identity proof for ~$1-2/per successful proof through a vendor like Stripe Identity or ID.me).
Passkeys solves for digital identity compromise (credential theft or stuffing/spraying), but you must rely on other mechanisms (such as a I mention above) if you want to elevate identity assurance higher in the event of credential loss.
(consumer IAM is a component of my work at a fintech; auth/creds security, passkey rollout, high identity confidence when an account is recovered, etc)
How do I actually give them my real government document with it's physical security features through the internet? Just take a grainy photo of it? Really secure!
It at least avoids the user being phished or being compromised by reusing passwords.
But it seems in this case the account recovery is just using the password so the passkey is mostly convenience and maybe Google trying to move things away from passwords more than a complete change.
Passkeys are instead of the password. You can still login using your password. This way, you don't have to keep entering your password if you have access to a device with a passkey and can access that device.
Passkeys don't (only) replace passwords – they usually also replace another authentication factor as well.
That other factor might still be available for account recoveries (together with a password or recovery email etc.), but if either are not regularly exercised, users might forget them or lose access to them and not notice until they also lose access to their passkey(s).
That said, Google's and Apple's passkey solutions themselves are cloud-synced (with no way to opt out), so as long as users of either can still access their Google or Apple account, they would not be totally locked out.
Sure, but is that adequate? Not having people practice their passwords seems to be an anti-pattern for selling premium support in password managers, while many other apps ask with planned frequency.
If you are on Apple ecosystem, iCloud can sync. Other password managers like 1Password can also be used to store your passkeys. If none of the above, you can always set up a physical security key and leave it at home.
IMO if you're reading hacker news, you're fully capable of setting one up and leaving it in a safe locale for recovery.
>Note: To use passkeys, iOS 16, iPadOS 16, macOS 13, or tvOS 16 (or later) is required. iCloud Keychain and two-factor authentication must also be turned on.
A lot of services, but not all, will let you add passkeys which are tied to a password manager (e.g 1password) and not a physical device. If you've got one of those set up, you can download it on a new device and then gain access that way. In the case of 1password, this means you either have to remember your master password and your access key, or you have to have this stored somewhere safe. Perhaps choose a memorable password[1] and then encrypt an sd card and use one of these[2] in your wallet or a keyring usb drive or a yubikey so in the event of a fire all you have to do is grab your wallet or keys and you're good to go. Alternatively you could store this information in a safety deposit box, or with a trusted relative, or even your lawyer if they offer such a service.
At the end of the day, it's the individual's responsibility to determine how much they value their digital security and take what they deem to be the necessary steps, expenses and precautions to protect it. The only other alternative would be for Big Tech to have some kind of integration with the state, so that your digital accounts are tied to something like your passport or social security number, so that there are procedures available for regaining your digital identities in the event of catastrophe, just like you can do with your physical identity.
I personally think that the latter is where we are heading, not necessarily because of scenarios like you've mentioned, but because it's only a matter of time until AI advances to the point where it's going to cause a dangerous breakdown in trust and the only way it's going to be fixable is with some kind of system that is tied to physical reality. The internet will end up splitting into two, with the majority spending their time on the "verified" web, which will be websites using OAuth that will require you to use an account with one of the big providers who will have verified with the government or third party agency who you actually are. And then any websites that don't require this will form a sort of new, more accessible "dark web". I honestly think the majority of people are feeling that wary and weary of the internet at this point that they will happily choose the verified web, regardless of the surveillance implications.
On average, this might increase security (the vast majority of users are terrible at using passwords).
For proficient users who use passwords securely, this is an acute drop in security (if forced to use).
Forced phone number 2FA has the same effect; in Big G's case forcing phone number 2FA is anti-anonymity disguised as security. In this case, it's a bid for biometrics.
> Forced phone number 2FA has the same effect; in Big G's case forcing phone number 2FA is anti-anonymity disguised as security.
It can actually be both; in fact it very likely needs to be:
1. Phone numbers are the best long-term identity most people have
2. Google has billions of users and needs to support account recovery at unbelievable scale
3. Many people lose passwords and devices, but very few lose phone numbers
It logically follows google uses phone numbers to assign and delegate identity on their platform. Is this bad for privacy? Yes, but it's also very good for security because it allows users to control their data using a third-party authenticated "credential" they don't have to manage.
Sign up for Google's Advanced Protection Program. It's been around since 2017, and last I checked, it's the only way to fully disable the use of your phone number for authentication.
> For proficient users who use passwords securely, this is an acute drop in security (if forced to use).
Why? Because the user can have their device stolen and the PIN guessed? Can't you use a long password instead of a PIN if you want to?
And this part I'm not sure of, please correct me if you know. If I understand it correctly there's one security advantage even assuming a sophisticated user who is immune to weak passwords, password reuse or phishing. If there's ever a leak of Google passkeys, the leak would only get public keys, which can't be used for login, making the leak mostly useless.
I live in a country where my phone is forcibly tied to my identity. I will not use it to authenticate anywhere. For business purposes with my business phone perhaps, but certainly not for my private life. That would be a huge decrease in security.
Biometrics are used to unlock an local, on-device key storage mechanism which contains a private key, and from that you can derive a public key, and that's what Passkeys fundamentally are, is a public/private keypair you use to validate you are logging into a website. If Google were harvesting your biometrics they were just doing it already and it has nothing to do with this.
This is an extremely basic detail of the security model that has been true since long before these were introduced, back when the iPhone started using e.g. the secure enclave; I don't know why people on this website talk so adamantly about things they clearly do not understand at all. It's honestly kind of astounding.
> For proficient users who use passwords securely, this is an acute drop in security (if forced to use).
No, it isn't, it's the moral equivalent of an SSH key to login to a server instead of using SSH password to login to a server, but now apply that to a website. And beyond that, it's objectively wrong; for instance passkeys are literally phishing resistant, and no amount of thinking you can "use passwords securely" can change that simple fact.
I'm surprised that they're moving forward with this already. As of last week, there were still enough rough edges on their implementation that I disabled it for my Workspace tenants. The two most irritating:
1. Advanced protection doesn't yet support passkeys. You must keep U2F in place for now.
2. If you have a U2F key configured on your account, Google will prompt you to use it as a passkey before telling you that it's not a passkey and you must login with your password. The net result is that anyone using phishing resistant MFA loses the ability to have their MFA step "remembered" on a device because Google will always prompt for the U2F factor before the password.
This aside, I've been doing a lot of testing with FIDO2 flows using security keys and passkeys across device types and platforms in preparation to roll out passwordless via Okta with a couple of smaller clients. Overall, I love the authentication flow, but there are a lot of gotchas to keep in mind. We've spent a considerable amount of time mapping out the happy path, creating onboarding resources, and documenting business continuity scenarios. The personal use case is actually more of a challenge in some ways, because you need to think about each service rather than just one IdP.
FYI, the easy path right now if you need to support multiple environments is to invest in 1Password or another password manager that supports passkeys. This provides the most consistent user experience and works across most platforms, though we're still having trouble with Android 14.
We're sticking to hardware keys for highly privileged accounts, so admins get a pair of FIDO2 keys. Everyone else gets one Yubikey, which serves as a backup if they lose access to their devices or need to login on an untrusted device. Android is also a problem here. Even in 14, it doesn't seem to support passwordless FIDO2 flows.
I probably could have framed this more clearly. I don’t think my point really supports the lock-in argument.
Google has been a big proponent of FIDO, having been an early adopter of U2F in Chrome and leveraging it for advanced protection. More recently, they have extended Chrome support to FIDO2/passkeys and made this move to make it the favored means of authentication for Google accounts.
Given that strategy, it’s a bit of a head scratcher to see Android lagging behind its desktop and mobile competitors. Why stick your mobile customers with second class support for the passwordless technologies you’re pushing everywhere else?!
This is an interesting direction. It's worth noting that biometrics, like fingerprints or facial recognition, aren't really 'secrets'. They can be observed or leveraged without a users knowledge or consent, and in many ways function more like a username than a password.
Passkeys really aren't biometric authentication per se. If you use TouchID, for instance, Google isn't authenticating you based on your fingerprint. Rather, the fingerprint merely unlocks the cryptographic key pair that's then used to authenticate you.
I use Yubico Security Keys myself as passkeys. They're protected by a 6-digit PIN. But that PIN is strictly local to the device, meant to prevent snoops from logging in just by having physical access to the device (the keys get blown away after 10 consecutive unsuccessful PIN attempts). When I enter the PIN, the keys unlock, and it's those keys that get me into my Google account.
Most accounts with passwords have the fail-safe method of 'prove my identity to company, they reset'. I.e if you can't remember your bank password, there are paths for the bank to reset for you.
Anything that Google controls you have absolutely no way to get in contact to resolve issues. This is already a problem with all of their products. Locking all of your access behind a Google controlled door is just setting yourself up for a future nightmare.
One question I don't often see asked in regards to passkeys: what is the legal standing in regards to law enforcement access to 'passkeys' vs passwords?
For example, it is completely valid to say I genuinely do not know my 1000 long multiple special character password; it could be on a piece of paper, in a file encrypted with multiple layers. Essentially, there is no foolproof way to ever prove whether I know a given password, or not, especially if the password is only ever in my head (assuming the plaintext version is never logged, all you would ever have as 'proof' is a hash to compare it to).
Passkeys make it so that, I imagine, there is an element of 'proof' at all times; your face, fingerprints (which in some countries you are required by law to provide), I can't disprove I "own" my fingers so that element is always there, and you can be compelled to provide your fingerprints at any time for any reason - with a password, it is impossible to know whether I know a password.
In that sense, a password is far, far, far stronger than any other method of authentication.
Take a scenario: Mr Police wants access to your phone, it's protected only by your fingerprint, pretty easy to gain access. Now do the same but with a password that's sufficiently complex, written on a now shredded piece of paper, and there is genuine plausible deniability.
I imagine in a lot of cases this is extremely important and passkeys will be shunned altogether.
>To use passkeys, you just use a fingerprint, face scan or pin to unlock your device, and they are 40% faster than passwords
>We’ve found that one of the most immediate benefits of passkeys is that they spare people the headache of remembering all those numbers and special characters in passwords.
So they aren't considering at all how easy is the autofill password feature with a password manager (that they even have built in Chrome/Android).
>So they aren't considering at all how easy is the autofill password feature with a password manager
Passwords are a nightmare for both users and service providers for a variety of reasons. And password autofill is a bandaid at best.
If I had a quarter for the number of times I've personally used a password manager to auto generate a password which was then either reject by the website due to absurd password complexity requirements, or had the password seemingly accepted but in reality silently truncated behind the scenes....
I know you're commenting on a Google blog post, but FWIW Apple acknowledges password managers/autofill in the "Deploy passkeys at work" talk from WWDC 2023:
"Let’s look at a side-by-side comparison of the experience of creating a new password versus creating a new passkey. As you can see, creating a passkey is significantly faster and easier than creating a password. Just Face ID and you’re done. Now that we’ve looked at creation, let’s compare the experience of signing back in. With a password, the user has to remember and type in the password. With a passkey, they just Face ID and they’re done. A password manager can help improve the experience, but even the best password manager can’t compete with the user experience of passkeys. You are used to having to make tradeoffs between better security and a better user experience. Passkeys achieve something rare: great security and a great user experience."
You're comparing a crappy password filter with an optimally implemented passkey thing, though. If the world's up for improving over status quo by rewriting all login prompts, the comparable options would be making password managers/autofill/autogenerated passwords work well everywhere (which'd be just some light tweaks here and there), or making passkeys work well everywhere (which is an entire new thing, and people would still need to deal with passwords because there's no way that they're disappearing in less than a couple decades).
Passkeys might (or might not) have other benefits, but ease of use is entirely a question of cherry-picking.
I’m not cherry-picking, I’m comparing the actual real-world experience of using password autofill vs. using a passkey.
The significantly better passkey sign-in UX that I’m talking about exists on all major platforms. And the UX is handled by browser and operating system APIs, so it’s not really something the app or website can mess up.
Also, any solution that still involves password-based login prompts would be worse than passkeys because passwords are still shared secrets, and password hashes would remain juicy targets for attackers in server breaches.
Ugh, is this why my FIDO key started making me enter a redundant pin on the company login page (so: enter password, press FIDO key, enter PIN, press FIDO key)?
In my case i was already on passkeys and google decided to just... forget them all on my other computers. I can't use them to get in anymore. Why? Who the heck knows.
This whole passkey shit is going to be a nightmare for UX.
In general, the levels of security that people will increasingly need going forward, and the increasing requirement by companies to use that level of security, will be a usability pain for many people and a nightmare for at least a subset.
Is there any evidence that Google needs to mess with authentication flows? My mental model of the median Google account holder is that they have a bunch of photos/emails/docs/etc that are extremely valuable to them and their family, but of little value to criminals. With a dynamic like that, the security only has to be so high to deter random hackers and making it too difficult or confusing will ruin a lot of valid accounts and do much more harm than the criminals would have.
There are reasons to be skeptical of Google's motives here given their history of wanting to create user lock-in in various ways, and caring more about shiny new tech than general user experience.
There is incentive to gain access to personal emails. Not enough for spear phishing but enough for generic phishing. Access to email allows you to pivot to every online service in a person’s life.
So what happens when I die and my spouse or next of kin has to deal with this stuff? As the executor of my father's estate, he kept a physical password book that was instrumental in making it easy for me to settle his affairs.
There are a lot of interesting points being made in the conversation here.
What I haven't seen yet is a reminder that a Google Account is effectively Google's private property that they're letting you access in exchange for vacuuming up your personal data.
Always remember that passwords are protected by Fifth Amendment and similiar laws in other countries, but there is no law prohibiting officer to put your phone in front of your face to unlock it.
Why make claims for other locations when you don't know about them, and it could lead to serious consequences? In particular the UK has no such compunction.
One, the one to my password manager, where the rest of my passwords are stored--but without the additional part I add after I paste the password that is stored in my head.
Entirely this. I do not trust devices to always be working or on my person. I will only use this if I can generate an offline, perfect fidelity backup of my codes.
“But it’s safe in the Google/Apple/Microsoft cloud” is not an acceptable answer.
Someday, we will have brain reading technology to extract information from a newly dead brain, like we have to extract it from a RAM that was just turned off https://en.wikipedia.org/wiki/Cold_boot_attack
They've been accidentally enabling it for nearly a month if not more. And the UX has been infinitely confusing. I've been using 2fa for a decade (not an exaggeration, an understatement). I've been using u2f since the first month it was available and FUCK Google for this blog post.
A month ago I logged in and tried to check on my security tokens. Their UI was silently upconverting them. Without telling me. And the flow made it look like it was just deleting them. Hours later I realize it had re-enrolled them AND IT LOST THE DESCRIPTION I GAVE TO THEM. To be clear, it trashedt the decription I gave them during (what I didn't know at the time) was re-enrolling them as passkeys, because i sure as hell wansnt in the passkeys area. So not only did I inadvertently change them, they're now indistinguishable and unidentifiable to me. So if I want to ensure my primary and backup tokens are enrolled properly , I have to do it all over again, with all of them in my possession
Seriously, I have defended google against all sort of claims with respect to their 2FA and they can absolutely get up their own after what they pulled, and now this blog post.
Do some god damn basic (user) testing FFS. I would literally pay $1000usd right this second to scream at the people who green-lit and implemented this. And another $1000usd to ensure to people here that I know DAMN WELL what I'm talking about here. It's not like I don't have video evidence of exactly what I'm stating here on an unlisted YT video tweeted at Google Security.
Edit2: to be VERY clear, I have a video I reviewed, just now, that shows me trying to enroll an existing Security Token with a description, it disappearing, it then appearing as a Passkey with no description.
Your comment would be more impactful if it explained clearly what the problem is. What does it mean to upconvert a security token? In fact, what’s a security token?
(I ask mainly so that I can watch out for whatever bit you. On the face of it, the blog post seems pretty anodyne. The screenshot shows that it’s optional, not forced, since there’s a "not now" button.)
I'm sorry, I'm not laughing at you, I'm laughing at the premise of Google acknowledging this, let alone fixing it properly enough to have a "rollback".
As far as I call tell, my physical yubikeys that went though this process have continued working with the same ultimate user experience, thank God. Minus the 45 minutes where I thought I was locking myself out due to them disappearing from the ending landing page that listed my enrolled Security Tokens, due to the buggy upgrade UX flow or the fact that I have no way of confirming which of my primary/secondary tokens are now actually enrolled because it trashed my descriptions during this upgrade.
I am actually infinitely sorry at the times I openly questioned user error when people expressed Kafka-esque nightmares wrt to google auth. I'm actually quite annoyed at myself for ever doubting them.
"Not forced" would mean the dialog has a "Nope", "Not" or "Nuh uh" button instead of "Not now" and permanently goes away when clicked, never to return.
Correct me if I'm wrong but isn't it fair to say that passkeys secured on your phone are more secure than 1FA (password) but less secure than "traditional" 2FA?
Passkey 2FA: unlock your phone and the passkey on your phone can log you in.
Traditional 2FA: remember a password AND unlock your phone (where your TOTP is stored) and you can login
If I were to rate all 3 methods on a scale of 1 to 10, for convenience and security, I'd say:
The reason being is the secret used to authenticate you is non-portable (since it's based on asymmetric crypto, it doesn't need to be shared). On the other hand, portable credentials, like TOTP/HOTP code AND passwords are responsible for almost all compromise today.
Bearer token based authentication will always be inferior to FIDO/U2F - it's not even the same ballgame.
No, if you break into a site using passkeys, it gives you literally zero information that can be used to authenticate as any of the users. Think about the prevalence of data breaches in the past decade, and the sharp rise in the effectiveness of password stuffing, and think about why this change might be a good idea.
WebAuthn almost entirely eliminates phishing risk (at least with respect to credential harvesting), and Passkeys are a really nice, clean UX for using WebAuthn.
>No, if you break into a site using passkeys, it gives you literally zero information that can be used to authenticate as any of the users. Think about the prevalence of data breaches in the past decade, and the sharp rise in the effectiveness of password stuffing, and think about why this change might be a good idea.
An implication of that is passkeys let you use the same authenticators across multiple services safely. Instead of keeping track of unique passwords across all those services (or worse, reusing passwords), you can just have a passkey-registered phone and one or two Yubikeys for backups/convenience. You'd be a very hard target for account compromise. That setup is highly phishing-resistant and immune to credential-stuffing, without the cognitive load of passwords.
> Nobody should be using a remembered password anymore.
Nobody is a strong number, why?
I don't want to use biometrics for logging in to my SSH terminal. I dislike having to use my phone for authentication methods.
I go many places without my phone. Even tempted to gon on holiday without it. Maybe I'm just one of the few who actually enjoys turning it off when coding, developing or whatever.
Not wanting to use biometrics directly for over-the-web authentication is one thing. Not taking the time to understand the technology being employed by Passkeys is entirely another. That’s your fault.
There are plenty of posts in this thread that are misrepresenting the technology, in a few cases deliberately. If you feel strongly enough to comment, you owe it to yourself and the discussion to go to the source and understand what it's about - that's what I mean by that's your fault. You clearly understand enough to A) argue against biometrics over the wire and B) feel you can comment on Passkeys.
Most, if not all (I've not read every post) of the 'flaws' mentioned generally exist in computer security; for example, no one is impervious to a thug and a weapon. The implementation is as simple as generating a key pair; the private key is stored in a secure enclave, either on device or in a secure location, and the public key is shared with the 3rd party. All services provide some recovery method upfront, clearly stating the importance of a backup. There is only so much they can do before you accept the responsibility for managing your security and privacy online. Resorting to "won't someone think of the children" doesn't help either. My mother, who is 74, has no problem with passkeys.
Is it perfect? No. There are 'better' competing standards, but they don't have anywhere near the consensus of the broader security field. Is it better than the current status quo? Definitely. Public key cryptography is significantly better than username/password combinations, even with TOTP or HTOP second factors, though ultimately, it will be a while before they disappear.
Right, in which case passkeys would be equally secure. But if you DO memorize the password (for example for your most sensitive account), then it feels like traditional 2FA is more secure.
That being said passkeys win if you also take convenience into account. I've updated my original comment with convenience scores to reflect that.
The trend from Google continues to be towards "if you lose your phone with your credentials, you will be unable to log in". And Google refuses to create a scalable system that allows you access to your account by verifying your identity in person.
This is a recipe for disaster. And, possibly, a warning to move off GMail before it gets worse.
> And Google refuses to create a scalable system that allows you access to your account by verifying your identity in person.
People complain about government services, but this is something that government is good at. The DMV serves everybody, regardless of personal views, criminal records, etc. Companies can refuse service to anyone for any reason. What happens when you put all your eggs in Google's basket, and then they decide to close your account with no recourse.
Fastmail rocks. I decided years ago to be the customer not the product, so I don't mind paying for services I use.
An added benefit of Fastmail is somehow its calendar is able to sync between my Outlook work calendar and some shared Google calendars I have, while Google is completely unable to reliably sync a shared Outlook calendar for me.
Not parent but the more important thing in "de-googling" is to move your logins to your own domain. That way you are not tied to a single provider and can always switch if your current one starts degrading.
After over a decade of @gmail being my primary personal email it is pretty painstaking to move all of my logins over, and some services do not allow you to change your email at all so your mileage may vary.
Several months ago I moved my family's email hosting to Zoho. Its been pretty solid. The web client is really nice, its got pretty good mobile apps, it provides IMAP/Exchange Sync on their cheapest paid tier so you don't need their apps. Zoho has a 5 user free tier of just email, but you're then limited to their apps. I'm using the Mail Lite tier with the larger 10GB storage which is $1.25/mo/user billed annually.
They have some tools to migrate email. I was migrating from an IMAP source, the migration was pretty quick and painless.
I would recommend Protonmail because you can also have a plan that allows you to use your own domain. The interface is much better than Google IMHO and the spam filtering is up there as well.
"To use passkeys, you just use a fingerprint, face scan or pin to unlock your device, and they are 40% faster than passwords — and rely on a type of cryptography that makes them more secure. "
The point is more so that the pin unlocks a key on your local device and that key is much stronger than the password the typical user would select. Plus it is site specific in a way that your typical user does not do with passwords.
So it's making a system weaker against offline attacks if someone steals your hardware in exchange for making it stronger against phishing. This is probably the correct tradeoff for most people.
A PIN associated with a specific device that been cryptographically linked to your account. So while a seven digit PIN is easier to guess than a password, the physical device is much harder to steal over the internet. It’s defacto 2FA authentication.
Brute forcing offline kinda only works if you have a stolen hash or artifact like that. For a service like Google, they definitely have rate limits on password attempts.
I'm not saying I prefer either one here, just that password authentication doesn't automatically mean you can brute force offline.
Passkeys make accessing all your online services as easy as accessing your phone.
... that is a statement that some people will find convenient and some people will find terrifying. As much as I'm excited for the convenience, this is my primary concern: how easy is it for a stranger to unlock your phone? Most people intentionally keep their phones easy to unlock because they're doing that dozens of times a day.
I wont add on to the technical aspect of the discussion, but this whole article is "its easier and its faster and its less expensive for you!!", a data-harvesting tactic having been done for years. Please think, people. I get the security aspect, but this technology gives up an astronomic amount of personal freedom - even if vendor lock-in is somehow eliminated - and biometric data.
Biometric data is only stored on your device. Logging into an app or website with a passkey just uses bog standard asymmetric crypto (public/private keypair). Also a lot of thought was put into the WebAuthn standard (an open standard) to make sure it can't be used as a tracking vector.
Please think. The biometric data is on-device. This is, in very simplistic terms, public key cryptography where the private key is locked to a device. How that device is authenticated is immaterial to passkey authentication to another service.
Passkeys aren't "finger prints and face scans." They're dolled-up versions of SSH key authentication.
Just as SSH private keys can have passphrases to unlock them, passkeys can have passwords, passphrases, PINs, or biometrics to unlock them too. Servers don't authenticate you on those PINs or biometrics; those merely unlock the associated private key.
As usual, the multi-device/multi-OS and recovery scenarios are simply just glossed over. I'll stick with a password vault I can sync to multiple OSes, thanks.
You can associate multiple passkeys with your account. Your account can have a passkey that is synced across Android/Chrome, and another passkey that is synced across Apple devices and browsers.
My 90 year old mother saw this change, clicked on something she can’t remember, and now can’t login. She’s been able to login using the username and password she keeps on a card next to the computer just fine up to now.
per some support document (sorry lost the link), by default, Android users will have passkeys synced to their google account. So first of all, this is a lock-in play on Google's part. The passkey FAQ only mentions iCloud, so second of all it's a duopoly reinforcement. (This really needed Apple to first release passkey support.)
Beyond that, there are so very many ifs, ands, and buts around recovery and third party device usage that a typical user can't really keep it straight.
I was surprised by the amount of dislike of passkeys in this thread until I realised I had misunderstood what passkeys refer to.
I thought it was the same as security keys, which are like digital, but still physical, keys. They are awesome, one just has to have two and you are set. Passkeys tied to a cloud service or device like a smartphone are a terrible alternative (comparatively), from privacy and security (as in not get locked out) standpoints. At least they use fido2 so pushing for passkeys add support for security keys at the same time..
The PIN (or biometric) is not used to replace your Google account password. The PIN (or biometric) is used to authenticate to your device that holds your Passkeys, which in turn will authenticate you to your Google account (or any account that supports Passkey-based sign-in).
The PIN is checked by the local device. It never goes over the network, and the device can limit the number of PIN attempts to a very small number, because the only way to try PINs is to have access to the device.
The standards group that was behind Fido/U2F has been taken over by people who want to push a new product. That new product is "Log in with your phone" and phone lock screens allow biometrics and pins.
Password managers are not relevant, as you don't use a password manager to unlock your phone.
The people behind the takeover don't really give a shit about Yubikey-style tokens (which haven't achieved much market penetration anyway) but they've left them in to make the takeover less blatent.
More like the other way around -- the existing FIDO/U2F crowd was a bunch of businesses that made money selling keys. And that's why adoption was a rounding error, it was infinitely more expensive than a free password, so few implemented it. This is the obvious solution -- we're already carrying devices with a secure enclave, just use that, it's free.
You can have that by storing passkeys in your password manager, if it has support for that. Currently 1Password does, and BitWarden either does or is suppose to soon. I haven't looked at any others.
How is that different from a password? PIN stands for Personal Identification Number. Words change meaning all the time, of course, but in this case there’s no reason to call it a PIN when there’s already another word for it.
The important difference is that it is stored on the local device, not the remote server.
Since the things stored on the remote server have been called “passwords” for decades, it seems helpful to call the local thing a “PIN” to help more easily distinguish it.
IMO it’s not more silly than calling a hand-held computer a “phone.”
You should be able to use your password manager to handle passkeys. Enter your master password in 1Password, use passkey. And Bitwarden support is coming.
There's one elephant in the room I'm not hearing enough about, namely the legal precedent (at least in the U.S.) that you can legally be compelled to provide a biometric identifier (fingerprint, face scan, etc.), but cannot be compelled to provide a password, as that would be "compelled speech" and violate the first amendment.
I disable all kinds of biometrics from my devices when traveling for this reason specifically. Passwords in my password manager aren't the whole password. There's another component in my head that I won't (and, more importantly, cannot be compelled to) disclose.
Interesting point. Seems like a point where the law lacks behind technological progress. Though, in any case, most people aren’t aware of the detailed laws and when pressured enough by enough authority - perhaps not quite lawfully - they will give in. So, this seems to me a rather niche case where both sides know and follow the law, which is usually not the case.
There's nothing about the PKI aspects of passkeys that requires you to buy into a vendor ecosystem and have them on device, right? They're just key pairs, but I guess it's a good as chance as ever to ram through device attestation.
Can we decide to band together as an industry and call this “zero factor authentication,” since you login without using something you know or something you own/control?
The only way I can think of to explain this to a non-techie is “your account is now tied to your [singular] device, and neither a password nor a replacement device (like a new sim card) will let you in.”
So, it really does remove both factors from 2FA, and the logical conclusion holds.
Either anyone can get into an account with a “I broke my phone” social engineering attack, or the account owner cannot reliably authenticate.
FaceID and pins just unlock the secure enclave, which stores the password^H^H^H^Hkey on the phone that will eventually break.
So, when you are holding your dead phone, you realize that there is nothing you know or have that will let you into the account (and there never was such a thing).
Seems that the recovery if you lose the devices with stored passkeys is still using a password.
And will it be possible to use software keys and backup them to wherever I want and use them with Google or is it going to demand TPMs or that I keep the key in a secure vault in my phone or something or the sort?
There still isn't a way to use this on desktop Linux right?
If I'm allowed to use a software implementation (like with TOTP) so that my private keys can be stored in for e.g. a KeePassXC database so that I can back it up by having multiple copies, then I'm okay with it. Is it possible for sites to deny certain webauthn providers (ignoring scenarios like attestation forcing you to use a locked down system where you can't run keepassxc)?
Hopefully Tor Browser can turn on security.webauth.webauthn in a safe way before sites force it to be used, too.
Hmmm. I don't want to be dependent on any cloud provider for my logins. Any passkey solution must be fully self hosted for me to accept it. Is there such a thing yet?
I use Yubico Security Keys as passkeys. One at home, one in my office, one on my person. All with a local PIN lock (and 10-failure-device-reset) so simply having the hardware is insufficient to log in.
The only annoying thing about this setup is having to manually add each key to each new passkey-enabled account I have.
Yeah I have yubikeys, the problem is that most of the services I use don't offer to enroll more than one. Also there's the issue of limited slots on each key for passwordless.
I like the whole idea of syncing a single key. But the whole chain must be owned by me and me alone.
Isn't it obvious that logging in with your face or your fingerprint is less secure? Sure, it's convenient, but any thug can just forcefully unlock your device.
Most "thugs" interested in data sit in windowless offices in Manila or Delhi and effortlessly spam phishing and other attacks on weak credentials; they do not roam the streets looking for face-unlockable devices to exfiltrate. That is to say, almost all attacks are remote. And just because someone walking next to you on the street might have a black belt in martial arts, does not mean they're going to turn you into a pretzel on sight.
The reality is people are not good at creating, managing and using credentials well - and this is an existential risk for most users not realized until it's possibly too late. Any efforts to assist, support and otherwise absolve users of credential responsibility is a net win for infosec (though likely a loss for privacy).
Thieves can steal a car using tech magic. That is also true about access to accounts. That contradicts your comment. Biometrics, if stolen, can be used to access any of accounts if one obtains knowledge about how to use it for hacking.
Your comment violates HN guidelines, but as guideline says I assume good faith therefore I have provided details about how you're incorrect on that one.
A passkey does not contain and is not derived from biometric data, so one cannot login to an account using biometric data alone.
If one wanted to use biometric data to access a Google Account secured with a passkey, one would:
1. Need to find a device with that passkey on it (or an account like iCloud Keychain or 1Password that contains the synced passkey). Biometric data could be used to unlock the iPhone, in theory. I'm not aware of this being done in practice.
2. Then unlock that passkey. On iOS, biometric data could be used to perform this step, just as accessing the iPhone in step 1.
If you hold the power/volume buttons or do a Find My lock, it disables biometric auth on an iPhone. I assume there are equivalent tools on Android.
So, if I lose my iPhone and someone also scanned my face, they could login to my Google account by generating a face accurate enough to fool Face ID, and only if they did it before I marked the phone as lost.
It does not have to be a thug who makes your picture.
Titanic has crashed. Microsoft has been hacked. There are no solutions that do not contain bugs. There are no drivers for sensors that cannot be hacked.
Sure hacking a device is difficult, sure. Maybe nearly impossible, but I doubt it. All software has bugs. Some even backdoors. Some data are centralized and kept on big tech cloud storage which is a honey pot for hackers. Once hacker has biometrics data on your phone captured, it could be used. Not only to obtain your passkeys, but outside of your phone.
A simple google search confirms that. There was a biometric data breach. Sure this might not be the best result, but I spend 2 seconds searching for it. Quite generic article, but I think it is sufficient.
No one has managed yet to explain to me how you recover access to an account using these passkeys if you somehow lose access to all your devices.
Note that i said "all your devices" so the cloud backup you dream of will also be inaccessible because I can't authenticate to that either.
And I know about backups... what about your average user who is likely to own a single phone and no other device? They lose access to everything if they drop it in the toilet?
A thousand nopes. I don't care if it is 100% secure. This is one instance where "cloud" is better. Having the mother of all failsafes be a device that can be stolen, broken, or just plain borked on a dime, and potentially your entire digital life is now locked from your access for good? Great innovation there google, please kill this in 18 months please.
Is it hard to remember the one password you use for all Google services everyone's already been doing forever and will still have to do for every other site? When's the last time anyone even had to log into Google on any device? I'm signed in everywhere all the time and it almost never seems to expire...
My desktop doesn't have a camera, fingerprint reader or touch screen...
I just tried turning one of my yubikeys into a passkey on my google account to see what will happened. The response was that the device is not valid. I think they are keen on biometrics for their passkey implementation?
I'm probably wrong but I expected passkey and yubikey to be interchangable. So if you are presented with a browser prompt for webauthn, you can use yubikey or passkey
In one of my groups leaders decided to reuse google suite accounts. It was really difficult for me to accept the account from a other person. Google sent multiple notification to other person phone, had to unlogin, configure two factor authentication, the other person had to ignore warnings about Linux access. It was nightmare.
For context, Gibson developed, and completed, an entirely secure and working solution to the problem Passkeys aims to solve, called SQRL (which I argue is better than Passkeys in a few ways). He is familiar with this problem space, and explains Passkeys in a straightforward way.
Will this work for social login, like if I use my iPhone to sign into Gmail with a passkey, can I then sign into Reddit with Gmail and not have to enter a password? I'm assuming so.
The post mentions eBay as a site using passkeys. eBay's implementation on PC accepts Touch ID, while Google's implementation did not the last time I tried it.
Thank you. I am embarrassed to say that using the site reminded me that, actually, I had already created Touch ID passkeys for my Google accounts. I think what confused me is that passkeys were not available for Google Workspace yet, so my account there couldn't use passkeys. That has now changed.
1. Yes! Using resident keys, yubikeys can store a number of them. Not an infinite number. It's 25 resident keys.
2. Most services let you add more than one passkey. Using 1Password, or using iCloud Keychain or similar, you can sync passkeys between devices. Even with iCloud Keychain, if you have only one device, you're given a recovery code that can bootstrap the entire system from zero if your only device is stolen.
ahhhhh! yet another setting I have to go disable in my Google account. I use yubikeys for 2fa for a dang reason, don’t try and force me to do stupid shit like this which will actually decrease my security!
I’m glad I only keep my Google account around for historical purposes and YouTube.
Beware of spreading FUD. Password managers like 1Password sync the data locally. If they are offline, for whatever reason, you can still access the passwords locally. You can easily test this by disabling networking on your device and accessing your data in the 1Password apps.
One of my companies switched to Yubi pass keys. They were super cool -- until I tried to log in on a computer with only USB-A ports. My key is USB-C. I suppose I need to get an adapter now.
They can be, but most people will use what is built into their mobile ecosystem of choice, with built in sync/backup. Physical secure authenticators in general use will likely remain rare, but are still useful for use cases where passkeys that can be synced or migrated are not secure enough (and you want access governed with a simple physical device).
I might regret this but I have an (almost finished) draft of a paper on Passkeys, it is available, with comments enabled (which will be turned off if vandalism becomes a problem) at:
Passkeys level up security, and while Passkeys make some tradeoffs concerning security vs. usability, they do not introduce any new attacks and make many existing attacks much harder or impossible (e.g. brute forcing attacks or credential stuffing)
Passkeys will bypass the hurdle of getting people to start using password managers, and will likely result in the widespread use of biometrics to secure Passkeys
Passkeys can potentially make account sharing harder once attestation is supported, something a lot of service vendors are in favor of. Passkeys are also easier to deploy and reliable due to optional device synchronization, which should reduce the need for account recoveries and lower support costs
Passkey client support in both software and secure hardware tokens is widespread and available now on most platforms, browsers and most third-party password managers
Passkeys are being deployed by major vendors (e.g. Google https://blog.google/technology/safety-security/passkeys-defa...)
============
Conclusion:
No new significant risks or attacks are introduced from the threat model perspective. From a usability and reliability perspective, Passkeys are infinitely better than passwords. Finally, from a support perspective, chances are that if you currently use a system to manage your passwords, it already has Passkey support. For high-security applications, you can also choose to use your hardware token.
Web applications and websites are becoming increasingly critical to everyday life (banking, healthcare, education, shopping, etc.). We must improve security across the board and get rid of old and insecure things like usernames and passwords. The world has also changed, and virtually everyone has a smartphone, something unimaginable even ten years ago, let alone twenty.
Simply put, in every situation where you use a password, you should upgrade to a Passkey if possible.
The problem with Passkeys is not that it's not possible, but that the standard is lacking any guidelines for things like this. There is no interoperability in general, it's accidental at best. And this is concerning.
Same goes for a lot of aspects that are attributed to Passkeys as "this can be solved this way", but in no way documented (in a way promoted by any major vendor), let alone standardized, let alone be required by some standard to be "Passkey-compliant".
In short, I think this can be summarized as "Passkeys lack proper standardized best practices document, encouraged by renown parties".
It is wrong to hand-wave at some specific implementation and say that because that implementation is okay, the whole standard is fine.
----
Also, you may consider adding another concern, "authenticator must be physically present to be registered". This limits ability to add new devices (which was not an issue with other systems, such as TLS client certificates).
In simple terms, one cannot add a Yubikey that lies in a safe in a secure vault under a mountain, they must have it at hand, when they're online.
This Passkeys/Webauthn limitation leads to people having significantly greater difficulty adding backup options, contributing to higher chances of getting locked out (temporarily or permanently) that it could've been, would Passkeys be designed differently.
----
Both things don't explicitly introduce any new weaknesses, compared to passwords. But the problem with Passkeys is that they're here to stay for a long while. So a push towards "you must fix this before it's too late" petitioning collective FAANG (who are the only entities that were able to push asymmetric crypto to web, no grassroots movement was able to do this - many attempts were made and all had died in oblivion) is extremely important.
The biggest mistake that the passkeys movement did is try to make it sound more marketable at the cost of oversimplification.
First up, these aren’t really “no password” mechanisms. They’re closer to ssh certificates. You need to authenticate through some other mechanism and then agree to do the equivalent of creating and installing ssh certificates on your device.
The ssh certificates get synchronized across your devices securely by your cloud provider. But they can never serve as the primary authentication mechanism - that will still have to be a traditional authentication mechanism.
It’s mildly infuriating that someone decided to take this simple idea and confuse the fuck out of everyone by positioning it as some alternative to a password based authentication mechanism. Obviously everyone is going to come and ask a ton of questions about how a mechanism without any passwords should work. And then the responses further confuse everyone because they don’t want to admit “no actually you still need passwords”
Their point was that at some step along the way, you do need to use a password.
Case in point, creating a new google account as a 13yo. If you don’t have a password and you lose your one device, you lose everything. This isn’t hypothetical; it just happened to a family friend.
Not sure why the discussion got booted to the bottom of the thread. Looks like it’s a lesson not to label your comment a rant.
As far as I understand, this is not a viable mechanism.
Consider a shared computer in a university laboratory or at a public library. Or maybe an iPad that is shared by a family.
As a service provider, you usually can not assume that someone using your service will log in with a dedicated device or with a device that has their primary google or apple accounts setup on it. (Some rare exceptions might exist).
I don’t think anyone wants to deal with customer support problems of “oh, I’m stuck in a different country when on a holiday and my phone got stolen, can you please recreate this key exchange process for me on this untrusted device logged in from public wifi at a coffee shop?”
Like with ssh certificates, you create more problems than you solve if you use passkeys as the primary authentication mechanism.
To answer your question, yes it would be primary authentication if you used it that way. But no sane person would. Hopefully.
But do you need passwords? The way things are setup now you do, the password is the recovery mechanism. If the recovery mechanism was instead something like "photo of face next to government ID" then Google could stop using passwords next week.
> But they can never serve as the primary authentication mechanism - that will still have to be a traditional authentication mechanism.
> If the recovery mechanism was instead something like "photo of face next to government ID" then Google could stop using passwords next week.
Think about the failure mechanisms. What government ID? Why might the face change? Etc. Even if these sound like outliers, at scale essentially anything will happen.
Maybe they could have used more marketable terms like "1-time password", or "barely a password", or "mini-password" (to denote minimal expected usage of your password), etc.?
It reflects that the mechanism is a way to securely store some identity related information. It is not a mechanism to establish that identity.
The value proposition is still obvious: You need to establish your identity once, and then you can securely save it and share it across devices and avoid having to reestablish your identity every time.
It also removes the “password” confusion entirely. Establishing identity could be through a fingerprint or verifying a government issued Id card in person etc.
The name also correctly reflects what it is doing while still sounding marketable to non technical users. The mental model that a non technical user will build more closely reflects what is actually happening - which is always helpful to build a good user experience.
If I may, I'll repeat a comment I made a few days ago:
Give me an implementation I can self-host, without Google, Apple, etc. having effective control (including claws in my relevant software supply chain) and with an easy user experience, where I can maintain secure backups (on my own infrastructure, thank you) and smooth transition to future devices, and ideally, if needed, securely export root keys (cause if I don't control them then someone else owns them), and maybe I'll be interested.
In the meantime plain old high-entropy passwords with a good manager gives me all those features and a simplicity that's hard to beat.
In my 30+ years of computing I've suffered more harm from failures of other companies than I have from any failure of my own diligence. The whole lesson learned is to reduce trust in them and, maybe I'm wrong, but everything I've read about passkeys and the like seems to put me at liberty of the companies developing and pushing the implementations of them down my throat. It will take a lot of trust before I give up my ability to copy/paste my credentials.
As I understand it (which mean I can be completely wrong), in order to utilize Passkeys, at least at the browser level, you need support within the browser.
Firefox has a build that supports passkeys, and I believe 1Password has an extension for Firefox that supports passkeys.
If "all you need" for Passkey support is a custom extension, it should be straightforward to create one that does whatever you want (including storing your private keys in plain text in your home directory, which many argue is a bad idea, but that's not the point).
Is 1Password a magically signed and authorized extension, or can any Joe pound out a quick hack using JS and Firefox?
I appreciate that the client and credential management should be sophisticated and secure, etc. But the API is the API, it's supposed to be an open API, and I can understand Chrome, Safari, and Edge, being closed source browsers, may or may not allow anyone to hack their own keystore regimen.
But, I don't think Firefox is doing that (unless the 1Password extension is magically blessed by Firefox somehow). At a minimum, you can always go the source, and rebuild Firefox to do what you want. Involved, to be sure, but possible.
Presumably your current password manager meets those requirements. Why not just use it (if it doesn't support passkeys today, it surely will) to manage your passkeys as well?
> Passkeys are a new way to sign in to apps and websites. They’re both easier to use and more secure than passwords, so users no longer need to rely on the names of pets, birthdays or the infamous “password123.” Instead, passkeys let users sign in to apps and sites the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN. And, unlike passwords, passkeys are resistant to online attacks like phishing, making them more secure than things like SMS one-time codes.
I HATE paragraphs like this. It's as if you're purposely obfuscating what they really are.
A1: If you're authenticating to Google because your $DAYJOB mandates it, contact your Enterprise Administrator. As part of their multi-gazillion deal with the dark side, I'm sure there is some kind of support for a recovery mechanism, and if there isn't: yeah paid holiday until they figure it out!
A2: If you rely on Google for personal-slash-small-business reasons, please refer to the previous writing on the wall, and accept that all is probably lost...
I mean, A2 is a problem. I'd wager that more people are selecting how to manage their personal accounts than selecting how to manage accounts for an enterprise.
Except that Google and everyone else pushing passkeys have been publishing massive volumes of highly technical details about all of this for years.
You're looking at a non-technical blog post targeted towards the general public, and non technical journalists. Any technical details you want are just a search away.
The title triggers me by itself. The article is actually much less problematic.
Anyway, I guess the way people are reacting on the comments is overwhelmingly due to the language. And the fact that it doesn't even try to explain anything.
IMO, the author didn't really know the things the article is about and is writing about some 3rd party information.
Just last month my missus cracked the glass of her iPhone. Apple repaired it under AppleCare, which is great… except… that they didn’t tell her that the “glass repair” entails them replacing the guts of the phone and wiping it in the process.
Apple iPhone backups don’t contain cryptographic secrets like eSIMs!
She got stuck in a loop where she couldn’t activate her eSIM because that needed her email, but her email needed MS Authenticator, which she couldn’t activate without an SMS.
She had to drive to the Telco with a pile of photo ID to reissue her eSIM. Her bank account got locked in the process despite the password being correct because of some sort of phone hardware lock.
This took days to fix and multiple in-person visits to various organisations. If this had happened while overseas on holiday, she would have been screwed.
Times have changed.
Your entire digital identity is now a smart card in your phones
That Smart Card is either a SIM card or an onboard TPM chip, but in any event if you lose it, you may as well be dead as far as anyone else is concerned.
Passkeys make this much worse. At least if you still have a physical SIM you can transfer it from any phone to any other phone.
Passkeys are not cross-vendor transferable!
Run away screaming. Don’t believe the hype. Wait until the vendors get their act together and come up with a solution for transfer and recovery.