Because passkey is owned by you (as in - whichever software vault you're using) and not Facebook.
It's no different than stored random 32 character passwords in a password manager... it's pretty much the same really, just that you don't have to copy/paste it in a form.
Do consumers perceive a significant difference between "login with Facebook" and "login with LastPass"? In both cases I'm delegating my security credentials to a cloud service I have limitted influence over.
In theory, no, but in practice if I don't have a cloud provider backing up my passkeys, I'm just going to lose them all next time my phone/computer dies (same problem as with local-only 2fac code generators today).
It's more like a 1000 character password that can only be extracted or transferred to other devices via methods provided by the developer of the software vault. The purpose is lock-in, not security.
Wouldn't that give somebody having access to your FB account access to every website you used FB login for? At minimum you'd still need 2FA with that to avoid this.
I deleted my Facebook account. I lost access to several accounts that way, luckily none of them were important.
At least this time I chose to close my account. Next time it can be Facebook/Google/Microsoft/Twitter/Apple who decide that you're a robot/fraud/whatever after receiving a bunch of automated reports.
If Google ever bans me, I'm screwed in many different yet interesting ways.
What's really scary is how account access can be lost in retaliation for exercising your rights as a customer (e.g. chargebacks, "too many" returns, lawsuits, etc).
As FAANG expand into more parts of our lives there are more and more things you're legally allowed to do but shouldn't do if you want to maintain access to all your shit. The TOSs of these vendors can become a de-facto legal regime that limits your rights in new and exciting ways.
Part of the problem is that right now the most convenient use of things like yubikeys is that the most convenient use of them is just leave them in your computer wherever they may be.
That makes them a pretty hard sell for any workplace environment, but also makes them a significant security risk on-par with writing your passwords on a post-it note for anyone looking to burgle... Seems like 2FA is the future...
- The biggest threat almost all users face is in the form of remote attackers: password phishing, database leaks + password reuse, tricking users into installing malware, etc. Local attackers are so far down the list of concerns that, really, using unique passwords and storing them on Post-Its is, for most people, an improvement in security!
- Leaving a Yubikey in the computer is, in fact, the normal, intended mode of operation--that's why Yubico makes low-profile keys that you can just leave in your USB port. Yes, an attacker can just steal the key, but the key alone is insufficient to authenticate in most uses; almost all relying parties using keys that don't support user verification will also require a password.
- The article was about passkeys, not FIDO security keys. Subtle difference, but, importantly, passwordless authn using passkeys requires the authenticator to support "user verification" mode (like a PIN/screenlock/biometric).
> The biggest threat almost all users face is in the form of remote attackers
I'm not sure what users you interact with most on a regular basis, but for a pretty significant portion of the population, the most likely threats to their online (and offline) safety are jealous boyfriends/spouses/parents
Actually a valid point, but if you're gonna be that condescending about someone not considering that part of the population you should have something better than weasel words to argue how big it is.
You certainly have to consider your situation. If you live alone or with someone you trust (who you want to have access to your accounts if something happens to you), writing down passwords on paper and sticking that in a drawer or in some book on a bookshelf somewhere is likely pretty reasonable. Maybe have them backed up in an encrypted file in the cloud someplace as well.
Live in a house with a bunch of other people out of school? Extended family some of which you don't get along with in and out of the house a lot? Certainly for work stuff in an office. Probably not so much. The risk may not be that great in absolute terms but I'd absolutely think twice.
> if you're gonna be that condescending about someone not considering that part of the population
We're talking about somewhere around 65% of the overall population. Entirely ignoring women and children from your target market warrants a little condescention
It's possible that I'm just missing the distinction here between passkeys and FIDO security keys. Because all of the things I'm seeing in this space fall into just one factor of authentication.
I will point out that I explicitly called out 2FA as being necessary. And any of PIN/Biometric (not sure what screenlock is), seems like that 2nd factor to me. So if these are different things, then the rollout is going really rocky (on par with Wii vs. Wii U), and they should probably come up with a better naming schema.
Passkeys (as password replacements) generally require user verification (like a PIN or fingerprint) to unlock the secret.
I don't think very many people know what "security keys" or "FIDO" are, to be honest, so you're probably in the tiny part of the Venn diagram of people who a) know what those things are but b) don't know that they support user verification. ;)
> also makes them a significant security risk on-par with writing your passwords on a post-it note for anyone looking to burgle...
May I humbly suggest you RTFM before posting FUD.
You can set a PIN on the Yubikey (or on the Yubikey Bio's, your fingerprint).
Further, the PIN will block after three failed attempts, requiring the PUK to reset the PIN.
Key loggers are of course defeated by the Yubikey's touch requirement (which you can make mandatory for all actions irrespective of time between actions, i.e. a no temporary cache policy).
Complete noob, stupid question re keyloggers: when YubiKey inserts its token doesn't it go through the same mechanism as keyboard entry? if so keyloggers would work as before
> Complete noob, stupid question re keyloggers: when YubiKey inserts its token doesn't it go through the same mechanism as keyboard entry?
It only uses the keyboard in the OTP mode[1] (which you don't have to use, and you can even configure to completely disable). I guess OTP mode is probably the one you were thinking of ?
To be honest other than the Yubico demo website, I've never come across a resource in the wild that uses Yubikey OTP mode login anyway. :)
I'm not familiar with the technicalities of OTP mode but I'm guessing its resilient to replay attacks, so key loggers could still be limited that way.
For all other modes (PIV, FIDO, PGP) it doesn't.
I believe there is an option to store a static string in the Yubikey and replay that on-demand when you touch it ... but, well, I'd say you're on your own if you choose that option !
> To be honest other than the Yubico demo website, I've never come across a resource in the wild that uses Yubikey OTP mode login anyway. :)
A company I worked at years ago used Pritunl as its VPN (which uses OpenVPN under the hood), with Yubico OTP configured.
It was a good-enough UX, and the user enrollment procedure downloads a certificate for connecting to OpenVPN which only works for one user, so when people inevitably spammed their Yubico OTPs into Slack, you couldn't use those to log in to the VPN as them since you wouldn't have their certificate.
A keylogger would probably be able to access the certificate. To get around that you'd need to do something completely out of band like acknowledge a push notification on an authenticator app on the user's phone.
The possible factors are:
Something you know
Something you are
Something you have
Choose 2.
A PIN would be something you know
A fingerprint would be something you are.
The key is something you have.
I'm saying in the post that we're never going to just a passkey for this. And the yubikeys I have used in the past have all been just "something you have".
For most digital services, physical theft is one of your least concerns. Someone can just take your laptop and extract your session token, who even needs a Yubikey?
The problem these keys solve is that humans suck at managing passwords. Password managers are nice, but they're also protected by passwords, and humans suck at using those protective passwords.
I'm all for 2FA, but I'd like to see websites switch to key-then-password rather than password-then-key. Most people won't turn on 2FA and physical keys are a lot safer in today's world of leaked passwords galore than passwords.
If you don't enable 2FA and default to using a key, you can still do the whole "forgot password" (or rather, "lost my key") routine to reset your authentication through email.
I work in a lab that requires fingerprint login (TrustKey FIDO keys) with no fallback.
Every 6-8 weeks I need to have my keys reset with new prints, which is a process that involves meeting a member of the security team in a room for 20 minutes so my key and the backup key (kept in a safe by the firm) can both be reset.
Everyday, without fail, I sit there like a chimp taking on average 2 minutes to unlock my workstation. This happens maybe 5 times per day.
A sane setup would provide an alternative to unlock the passkey, with a PIN.
Yes, you're back to entering a password, but you don't have most of the weaknesses and pitfalls of password-based logins in distributed systems (phishing,credential stuffing,keyloggers probably a few others).
Any time I use shellac as a wood finish, I get a layer of shellac on top of all my fingers. There’s no way the fingerprint scanning would work after that.
happily for you, you have the problem AND the solution!
next time, (besides using gloves for once) drop a blob of shellac on a shallow container with flexible sides (silicone or any flimsy bottle cap). After a few hours, take off gloves and thumbprint for several minutes with very light pressure on the blob of shellac. after another few hours, tie some nylon ties to the side of the container and tighten every now and then so that the end result is a convex plane with your finger prints. you want it slight convex but still mostly plane.
Done. now wait for that to dry. apply some harder finishing synthetic laqueur to preserve it longer. just keep that in your pocket and you will be able to unlock most phones.
note that some phones (correctly) do not mirror your prints, thought most do for some reason... for those you will have to first cast you prints and then cast the reusable token. which make getting a convex token in the end easier tho... but for the dozen of devices i've tested, they all mirror just fine.
... and that's reason #1239090 why using biometrics as passwords are a really stupid idea. it's only good for convenience shortcuts, so fine on phones, bad on anything else.
I believe this does not apply to ultrasound-based fingerprint sensors like the ones we have below the screen on Samsung's [0]. Not sure how other manufacturers are doing their fingerprint scanning nowadays.
None of these newer solutions do anything but convince me that passwords are the democracy of authentication - the least bad of several bad options. But hey, things are going to become so secure that nobody can get into anything anymore, so I guess that's a win. :)
Oh how I wish we could get password auth back everywhere. We're working towards 6FA, they have to know your backup email address, your phone number, your location, your device, your security question.
At some point security is a trade-off with convenience, I have a randomly generated >20 characters password that I use only for gmail but right now I'm in the hospital and they won't accept it because I'm not on my usual device and I didn't activate 2FA ... because it's exactly the kind of problem I wanted to avoid.
I know users reuse passwords, I don't, let me use my god damn password.
And my password vault is on my google drive ... someone come euthanize me please.
Microsoft "consumer" (live.com, etc) accounts are like this. They have a whole set of advanced, secure options like security keys, TOTP, etc but they force you to have either an email or SMS recovery option configured :(
Google on the other hand, do this correctly. You can configure a consumer Google account to only have secure options listed.
> Google on the other hand, do this correctly. You can configure a consumer Google account to only have secure options listed.
Are you sure about that? I couldn't activate 2FA in my Google account for years because they didn't enable the option without giving a phone number first. Based on my HN experience, many users gave their phone number from the get go and therefore didn't notice that they couldn't activate 2FA without it.
> Are you sure about that? I couldn't activate 2FA in my Google account for years because they didn't enable the option without giving a phone number first.
Just checked, and yes, no phone or email recovery methods configured.
The trick with a newly created google account (assuming the regular account creation flow) is to give a phone number at signup and then remove it. There are some non-standard account creation workflows that used to work without a phone number at all but I haven’t tired recently and iirc the last time I did it didn’t take long for google to require me to “verify” my humanity with a phone number.
SMS requires a phone number which is an excellent user tracking signal. I don't know why ad companies like Google and Microsoft would want to give that up.
Why is there no discussion on users losing their private keys? Ask all those cryptocurrency users who lost their private keys. Now don't tell that there are crypto wallets/vaults that manage private keys; there are many ways key can be lost even when using wallets/vaults.
We engineers live in a different world, disconnected from the regular users who have no clue what public-private keys are!
The standard mantra for physical key-based 2FA has always been "register two keys and keep one in a safe", which seems doable for important accounts (like banks and government stuff) but no way am I going to get a key out of my safe when I want to order a replacement part on JoesDiscountDishwasherParts.biz. I really wish there was a way to register your backup key through your primary key.
Luckily, FIDO2 can fix a lot of these problems. People who don't have significant security needs can use a trusted service (currently Apple, Google, and a few small companies) rather than a physical device. Lose your phone? As long as you can get your account onto a new one, you can still access all of your stuff.
Once this type of auth will take off, I can imagine a business model for a FIDO2 company that focuses on customer service. The only problem with the system right now is that if you can't log in to your Apple/Google/whatever account, there's no recovery. Try contacting customer support and see how long it takes until they just block your number, because there is nothing they can do.
Having a business where you can go to a physical office and show up with ID so you can get your account back would solve this problem. Recovery would still be a massive pain, but it's better than spending years on a legal battle like some people trying to get their pictures back from their cloud providers after getting locked out.
Wait - the way this works is you have a backup key, if you lose your primary you replace it using your backup. NB this is only needed when you move to a new device with a new secure enclave too, so at no point is this pizza situation likely.
I have to admit that I don't own an hardware security key. But since those let you use public key cryptography to login, you could at least theoretically use the same public key for multiple services. Whether the FIDO2 protocol lets you do that or not, I admit I don't know.
The keys are baked in to the devices and are tamper proof. So two devices means you have two different public keys.
I use YubiKeys for accounts I consider important and they're a pretty huge hassle compared to a password manager. I'm also scared to get rid of any of the old ones I've got just in case they're linked to an account I forgot about.
It’s possible, at least for GPG. I’m not sure about WebAuthn. Regardless, generating the key right on the device is the most secure way of doing it.
It’s also hard to manage keys you’re loading yourself. Once I loaded a private key onto my YubiKey and accidentally failed to backup the private key because I used the wrong syntax when I exported it. I didn’t even realize until I got a new YubiKey and went to load my GPG keys onto it. I was only using it for signing, so it wasn’t a huge deal, but if I’d been using it for encryption / decryption it would have been a disaster.
It doesn’t, which would make disaster recovery a huge pain. You would have to register your backup key for every account you have.
The Apple/google “passkey” approach lets you use WebAuthn while having encrypted, cloud stored, private key escrow. It is much more convenient. Obviously with the downsides that implies.
> Having a business where you can go to a physical office and show up with ID so you can get your account back would solve this problem.
I've wanted something similar, combined with a tree approach to account recovery where the effort for recovery can vary depending on the importance of the account.
Say I lose access to my McDonald's account. That's not a very important account. It just contains some reward points that would get me some discounts at McDonald's. That account would be a leaf on the recovery tree. It's parent node would be my email account, currently at Fastmail. Recovery of my McDonald's account would just require responding to a recovery email McDonald's would send to my email.
My email account is much more important. Its parent node would be my domain name, currently registered at Namecheap. Recovery of my email account at Fastmail would involve demonstrating to Fastmail that I control my email domain.
My domain name is so important, since it is in the ultimate recovery path for so many descendant nodes, it would probably have at least two parent nodes (I didn't say anything about the tree having to be a binary tree).
They would be businesses that can verify my ID in person using government documents like my passport, and provide a way for me to prove that identity to third parties.
Banks would be good candidates to run such a business. Post offices would also be good candidates.
The protocol between the root verifiers and their direct child nodes could be a zero knowledge protocol so that the child node doesn't get your real identity and the root verifier doesn't know who the child node is. All the root needs to learn is that you are being verified for some site, and all the site needs to learn is that you are the same person who set up the account.
Such a zero knowledge protocol could also be good for age verification, which more and more jurisdictions are requiring from some sites. With such a protocol between the age verifiers and the sites you could have age verification without giving up anonymous accounts.
> My domain name is so important, since it is in the ultimate recovery path for so many descendant nodes, it would probably have at least two parent nodes (I didn't say anything about the tree having to be a binary tree).
If your domain name can have multiple descendant nodes and multiple parent nodes, is that still a tree?
Probably not. I should have said directed acyclic graph.
Actually I guess it doesn't even have to acyclic. You just need a directed graph where that has a non-empty set R of nodes such that (1) nodes in R do not have incoming edges, and (2) every node that has an incoming edge can be reached by some path that starts in R.
From what I can understand from the wikipedia page for the graph theory trees https://en.wikipedia.org/wiki/Tree_(graph_theory), what I'm used to calling tree ("computer science trees"?) are rooted trees, and what you described could be called a tree.
Which kind of makes sense, because a tree has stuff that branches out at the top (the branches) and at the bottom (the roots). The trunk has multiple parents and multiple children.
Definitions aside, I like your idea a lot. I feel like it's one of the few propositions that recognizes how important proving your identity already is, and how it will only become more important. The system is flexible and makes sense. It's the kind of thing that I think most people could understand, and thus use.
> Luckily, FIDO2 can fix a lot of these problems. People who don't have significant security needs can use a trusted service (currently Apple, Google, and a few small companies) rather than a physical device.
And from the article:
> “If I'm Google implementing passkeys, I cede a lot of control to Apple if my user is on an Apple device, I cede a lot of control to Microsoft if the user is on a Windows device, I cede a lot of UX control to Android and browsers,”
To me it sounds like Google, Microsoft, Apple, etc. seizing the last bits of control away from the average person. Everyone will be absolutely beholden to a few big tech companies. Using a fake name or birthday on accounts will be unthinkable because a locked account will mean losing access to your life and the only way to get it back will be to verify your identity which better match the info you provided initially.
We used to have outrage over things like using real names and now we've somehow fallen to the point where everyone is going to mindlessly accept a scheme that could easily morph into verified identities managed by private companies. Participating online will require a verified identity and everything you do will be mapped back to it.
Passkey is a concept that even the majority of tech enthusiasts seem not to have groked as of today. The thing that google/Apple have brought to the table is cloud backup of your private keys (yes, you should have lots of questions about how that is managed). This should enable disaster recovery/device transition for people using a phone as one of their passkeys. You’d probably add a fingerprint from your laptop for convenience, and if that laptop is all you have then no disaster recovery for you.
However, to be fair, if people have one of something it’s going to be a phone. If you use google or android, then those keys are backed up into the cloud “securely”. Those keys are also “secured” on the device. Not as good as HSM, but if you dig into the details it’s probably much more solid than you’d expect.
> The thing that google/Apple have brought to the table is cloud backup of your private keys (yes, you should have lots of questions about how that is managed).
Absolutely. I keep my BitLocker keys in my Microsoft account because it's a simple solution that provides good enough security for me. If someone wants access to my data they have to get the key and my disk. I understand it and I'm satisfied with how it works.
With passkeys, having a cloud backup doesn't even make sense to me. If I'm using a YubiKey or a TPM, the private key can't be extracted to back it up, so what do they back up? Do I have to opt in to a weaker system to get cloud backups?
At the very least, I should be able to designate trusted parties (parents, siblings, kids) where at least one of them has to approve the recovery of a cloud backup. Microsoft, Google, etc. shouldn't be able to access it at all. I trust my family, not big tech.
Should you trust Apple? Is this secure enough if a password can still be used that recovers all these keys?
Ultimately there is always a convenience/security trade-off. The “passkey” concept has it right for the 99% of users case (in my opinion). For that 1%, it’s still WebAuthn, so nothing stops you from using a Yubikey with a second safe-held Yubikey for disaster recovery.
I’m guessing that means there’s some kind of key derivation happening which means it’s super similar to modern password managers IMO. I realize there are some benefits, but in a password based world I can memorize my highest value passwords and salt others with a common password.
I don’t see the value in making such a big change for such little gain.
A web password is effectively a private secret, that can be used, for example, to derive a ECC keypair, but this secret is passed around in plain text between your device and the target site or service. It might be encrypted on the wire, but it must be known by both.
So any system that replaces web auth passwords is, worst case, just as bad as a password from a key-ownership perspective. Such a system also has the potential to be much better than a password, for example your auth secret is only entered on a secure keyboard (thumb reader, etc.) and used locally on a device you own, which then handles all auth tasks.
The question is how do you recover it when you lose it?
For a password I just click the “I forgot my password” link, I get an email with a link to click, and my account is recovered within minutes. I have recovered 15 year old accounts this way.
If you can’t do that with passkeys, then the system is doomed to failure because people lose their credentials and devices all the time.
Surely a system where you have a single point of trust and key backup is better than the current mess of using a single password on multiple sites, like most people do.
And no, the solution to that is not security education, people don't change and a system that expects behavioral changes without enforcing them is simply an insecure design. The truth of the matter is that passwords are insecure and problematic for the vast majority of non-technical people.
You authenticate to a cloud escrow provider using any of your account's other associated devices. If you have none, because Yellowstone erupted while you were away, and someone also yoinked your phone in the ensuing chaos, then you input either (A) your device's passcode and an SMS code, or (B) a recovery key. If you have neither, then you use an established recovery contact. If those steps didn't work, then it's not too late to visit Wyoming.
I am in IT but not this side and I must admit I do not grok this move... At all. I don't understand the risk to Benefit story. It seems (possibly incorrectly) to put all my eggs into one basket - whether phone (which annoys the heck out of me as it is NOT my primary device) or some cloudy account I'm supposed to trust with my life. It also seems to impose geographical dependencies (I want to check my email at my friend's but my phone is at home which is precisely why I want to use their computer etc). It also seems to bring terrifying consequences of losing some ethereal items nobody (regular) understands how to safekeep.
I feel like I'm an old grouch who wants things to stay the same... And that's kinda the case :-)
The device is not mandated to be a phone. A hardware passkey is also an option. You carry the keys to your home everywhere, don’t you? And you take good care of them? Why would carrying a webauthn-compliant hardware key be any different?
Twice in college, where I needed to have a roommate let me in.
Once at my first home, where I climbed in through the bathroom window (this was a PITA - it was some 12 feet off the ground and just barely big enough to get through.
Once at my current home, where I just used the porch door that I literally never lock.
----
And I'm actually pretty good about not losing my things. But over a 20 year span, I would have been permanently locked out of digital accounts 4 times if you want to play this game.
For me, that's a complete non-starter. So recovery flows will HAVE to exist. At that point, we're right back to where we are now, where I'm much less worried that someone is going to crack the salt+hash of my password, and I'm much more worried that someone will call customer support and pretend to be me.
If you are homeless or your current housing is unstable or unsafe what do you do? Not everyone has a safe place to keep physical objects. Homeless individuals already have communication issues because they usually don't have a reliable long term phone or phone number.
> Homeless individuals already have communication issues because they usually don't have a reliable long term phone or phone number.
And that locks them out of most email providers and online services, especially if their only source of internet access is a public library that "looks like a robot" because a lot of people use it simultaneously.
If you lose your keys, you can replace them pretty easily. The mental model for doing so is pretty simple and doesn't require contacting tens or hundreds of websites.
I'm pretty skeptical that passkeys are going to yield much benefit. Websites will still have to maintain a "recovery" flow for the reason above and this is already the weakest link a lot of the time.
Maybe think of the "recovery" flow as authentication itself and the passkey as a cache of the most recent valid check. Put you passkey manager under the same umbrella as your "recovery", or sync you passkeys through another service you trust.
Under this model, new authentication pretty much should always leaves a paper trail, while passkey login, could be more like the "remember me" cookie from the old days.
Sorry for the tangent, but has anyone ever heard anything about cross-device cookie synchronization?
In its core, WebAuthn is a way for a site to say "I want to authenticate" and the browser/device to say "OK, here are my credentials".
Nothing is stopping you from generating a private key from a password that you have in your head, and using that to authenticate to every site.
Obviously, if that password gets stolen, the thief can get into any of your accounts, but that's a choice you have to make. WebAuthn doesn't mandate a specific way of storing credentials.
>You carry the keys to your home everywhere, don’t you?
Nope. If I don't need my car keys I don't carry my keys. I do tend to carry a small wallet and my phone but also carrying a separate hardware token routinely would actually be a pain for me.
> You carry the keys to your home everywhere, don’t you?
Perhaps most people do.
There's also quite a few people that lose those keys - perhaps through neglect or being stupid, perhaps through an accident or getting mugged.
Note that of those unfortunate people that lose their keys, very, very few of them lose their house and everything in it as well - there's many paths to normally quick recovery that would need to be replicated digitally.
I guess it's tricky because at work, a central secret store with permissions and some kind of audit trail is a good idea. At home some cloud backup / syncing should be done, but I don't think that replaces local backups and everything.
What's the issue here, people can't export backups of the passkeys?
> What's the issue here, people can't export backups of the passkeys?
Quite the opposite. You can, and are always advised to, have a second key as backup that you can keep in a secure location. So in the same way as you don't lose your home if you lose your home's keys, you don't lose your digital access if you have a backup passkey. There is a slight difference between the two scenarios as in the case of your home, you wouldn't lose it regardless of whether you have a backup key or not. But since you can easily have a backup passkey the difference is very small.
The difference is that normal people don't have 50-200 houses and don't have to toy with the main/backup keys for every single one of those + each time they add a new "house", which may be often.
I think the issue here is we don't understand how to.
I can, and do, backup and safeguard my KeePass database in ways many and various. I have a fairly robust system to backup "traditional stuff" - including sync to my local NAS, a monthly off-site exchange of external drives with my best friend, and a cloud sync.
I have NO clue how to backup my whatever this is keystore or database or whatever, in a way that I'll feel confident I can seamlessly resume my life. It all seems to be embedded in some cloudy or device-internal ethereal opaque invisible places that make my life super easy when they work and when I do predictable things, and make my life devastating when they don't work or I do unpredictable things. I'm literally and genuinely and actually scared of these changes - not for when they work well, which is apparently magical; but when they don't work well or I fall through system cracks through some unknown change or issue.
Passkey objects on macOS are encrypted at rest within the iCloud Keychain sqlite database in Library/Keychains/*/. It shouldn't be too hard to adapt the keychain extraction tools that exist.
I don't know why you would want to though. Since (1) passkeys will rarely be a required nonreissuable credential, and (2) losing access to iCloud Keychain is extremely improbable. For many users, showing ID to a phone store clerk is sufficient for iCloud recovery. For others, it's using their laptop, a recovery key, or a recovery contact.
> showing ID to a phone store clerk is sufficient for iCloud recovery
Can you walk me through how that works? I don't know how Verizon, for instance, could get me that access. Or did you mean at an Apple store or something?
Basically: For some subset of iCloud Keychain users, SMS is used in combination with the lost device's passcode (or a user-chosen password) to recover the keychain. Since the device is lost, you re-issue the phone number with a carrier. I think 2FA or ADP may require another device or a recovery key, but my memory is hazy on this.
> Passkey objects on macOS are encrypted at rest within the iCloud Keychain sqlite database in Library/Keychains/*/. It shouldn't be too hard to adapt the keychain extraction tools that exist.
Really? That sounds awful. So now everything is passwordless and tied to a single database that can be stolen?
I thought the whole point of passkey was to tie the login to a TPM, Secure Enclave, HSM, etc. managed key because that means the private key is in hardened, tamper proof storage that simply signs challenges.
Sorry, that's only speculation, since I haven't had more time to analyze the database. If you read Apple's passkey security document, it claims that passkeys are distributed identically across devices. And that you can recover the passkeys even in the event that all associated devices are lost. It's also possible to share passkeys at any time.
passkeys.com:
> When a user sets up a passkey, a key is generated and synchronized to the cloud. When the user connects from another device in the same ecosystem, it will use the same key.
WebAuthn supports verified attestations for hardware-backed authenticators. Passkeys seem to be designed for normal consumers, who worry about losing authenticator devices.
i have a bunch of copies of my house key, including one at a neighbors house and one in a realtor-style lockbox in my back yard. If I somehow lose all of them, I can still call a locksmith who can re-key my locks for maybe $300ish. There is no conceivable circumstance in which losing my key(s), no matter how badly I mess up, even if I only had one copy and threw it in the ocean in a fit of rage, will permanently deny me entrance to my home.
> I make a hobby of defeating them at friends' houses. Takes a few minutes.
Fair and good warning, but I'm curious, how long would it take you to pick my front door lock instead? Are you saying those lockboxes are significantly easier to defeat than a standard front door lock? (I am genuinely curious! I imagine it could depend on both the particular brand/model of lockbox and door lock!)
(Plus I have bars on some basement and first-floor windows in places that aren't easily seen from the street so seem especially vulnerable, but not on all my windows, someone could always break a window instead. I do not live in a secure military facility).
Most houses aren't all that burglar proof anyway. I personally really don't care about the quality of my locks, since they're installed on a glass door...
Previously, in Northern Europe, I had a condo where the door+lock manufacturers literally cautioned you that the fire department cannot force a quick entry in case of emergency. Think bolts on hinge side of door, etc.
> I feel like I'm an old grouch who wants things to stay the same...
It does seem like it. The things you mention aren't drawbacks of this technology, and this is par for the course for whenever I see discourse on WebAuthn. People just mention random fears that they have, the vast majority of which aren't true.
Sure, but "I don't understand" cannot reasonably be followed by "therefore I will inject my own fears into this". WebAuthn is just a way for a website to tell your device it needs to authenticate. It has nothing to do with a specific company, hardware or software, etc.
If you want, you can keep on using your existing password manager for WebAuthn, or use a password. The standard doesn't care.
Cryptocurrencies are a spectacularly bad counterexample. If password-derived private keys had ever become commonplace, the ensuing theft would have absolutely dwarfed the losses from lost wallet keys. I'm not sure if there's even a comparable instance of successful widespread public-key cryptography adoption.
I have always maintained that 3rd party password managers were a bad idea because now you've got three parties heavily involved instead of two.
For most, this is that but worse -- you have essentially have three parties, and the least savvy is the one with the most to lose (maybe the ONLY one with something to lose) -- and is now the one with even less understanding and control.
Across the board, getting rid of passwords is a stupid idea. I get that what we have now isn't great, but this is way worse; I am certain this fails repeatedly and badly, unless we do the thing we haven't yet done, which is real cost/penalty/liability for the 3rd parties who get it wrong.
> Why is there no discussion on users losing their private keys?
I think that's best handled through some iteration: We don't need to flip a switch and make the whole world change to this system overnight. Instead, we could roll it out in managed environments, like companies and schools with IT departments.
I suspect that, for consumers, something like a (the horror!) government agency could handle this. Or a bank. Or your ISP. Or your phone service provider. Or the AAA (who handles passport and license renewals in the US.)
I run a company that cracks passwords for people that have lost the passwords to their crypto wallets.
Since the early days in Bitcoin people have been talking about backing up their private keys, and the methods of doing that have become simpler and simpler. Yet we talk to people every day that didn't realize that they can't just "contact Bitcoin" and ask them to reset their password.
Some platforms for creating "secure" backups of wallets apparently had back doors built in (BitcoinPaperWallet dot com I'm looking at you!)
A non-trivial portion of the population (based on my personal experience) is struggling with mental health issues and true analytical weaknesses that make it really hard for them to understand what's happening, or correctly recall what did happen.
Is all of that really compatible with moving secrets into the background (instead of remembering passwords)?
The root issue here is that most people do not know how identities based on public/private keys work. So the stuff about using bluetooth and and QR codes is just a pointless and meaningless ritual. If anything goes wrong the user will have no idea about what they should do to resolve that issue. They won't know what they have to do to prevent things from going wrong.
The modern cryptography that this stuff is based on was invented only 40 years ago. There is as of yet no useful cultural context to base systems on. You can't expect people to be able to use concepts that don't really exist yet.
Maybe we should create a religion around cryptography and share the knowledge as sacred books, this way the knowledge won't be lost regardless of context or culture and will be subconsciously in everyone's minds (even the atheists since they will also be exposed to it).
Name one system that accepts passkeys and allows you to setup two of them. as is the recommended best practice everywhere.
even OTP tokens generators goes to great lengths to give a false sense o security that their seed is unique simply by hiding it from the user UI. Google authenticator will happily save the seed and seed tokens in their cloud and allow you to restore. all while still hiding it from the user.
if you have twenty accounts on your OTP, and get a new phone, you have to log in on each site/product. Disable and re-enable 2fa. That's some 2~5min each.
back to passkeys... do you think this will last when google is getting tons of spam on gmail because microsoft is not careful on their spam bot protection? likely google will just shutdown the integration and demand you use google or apple for gmail. This will happen all over all the time.
Yes. Depending on the threat model, it may or may not be better. Many organizations won't be allowing remote passkey sign-in for employees. For people at home, the elimination of passwords will reduce rates of phishing and credential-stuffing attacks.
It seems like most people commenting here don't know what passkeys are. I'm seeing a lot of complaints about things that simply aren't a problem with Passkeys, only with plain WebAuthn.
Passkeys are based on WebAuthn, but they are not the same from a user experience perspective. The simplest way to describe Passkeys would be "WebAuthn, but with the keys stored in a password manager instead of being tied to a specific device."
Apple has a pretty good overview of how things look from a user's perspective: https://support.apple.com/guide/iphone/sign-in-with-passkeys... Note that while that while that article is about Apple's specific implementation, passkeys are an open standard with multiple independent implementations.
The biggest issue with Passkeys right now (aside adoption by sites) is vendor lock in. Many implementations don't allow the key database to be exported or transferred to a different Passkey client. That's an issue with those implementations though, not an inherent problem with the protocol.
> Passkeys on iPhone require that you use iCloud Keychain. If you don’t have iCloud Keychain turned on when you try to save a passkey, you’ll be asked to turn it on. Passkeys also require that two-factor authentication is enabled for your Apple ID.
Nope, sorry. Enshittification makes this entire concept, as-presented, a non-starter.
Use a different Passkey client then. This is like complaining that the "entire concept" of password managers is "a non-starter" because you don't like Lastpass.
Indeed I do not like LastPass and I have taken my business elsewhere. But it’s not on me to sell myself a passkey solution, it’s on the snobby folks like you who are so sure it’s obviously better. And I’ll repeat my previous comment: you all are doing a piss poor job of explaining that to the rest of the world who aren’t going to get on board. Betamax was better, VHS won.
> Many implementations don't allow the key database to be exported or transferred to a different Passkey client. That's an issue with those implementations though, not an inherent problem with the protocol.
I don't get it. As soon as a key database can be exported, that means it can be stolen, doesn't it? How is Passkey so much better than a password manager with a good implementation that it warrants all the added complexity?
BitWarden already uses my TPM to gate access to the password database.
> How is Passkey so much better than a password manager with a good implementation
Because:
1. Passkeys have better UX, on account of them being able to interface with websites through a standard API rather than through text boxes.
2. Password managers are incapable of eliminating user-memorized passwords, again on account of them interfacing with sites through text boxes designed to facilitate that particular insecure practice.
153 comments
[ 3.9 ms ] story [ 232 ms ] threadIf I wanted passwordless login, why wouldn't I just hit the big 'sign in with facebook' button practically every website has these days?
It's no different than stored random 32 character passwords in a password manager... it's pretty much the same really, just that you don't have to copy/paste it in a form.
Do consumers perceive a significant difference between "login with Facebook" and "login with LastPass"? In both cases I'm delegating my security credentials to a cloud service I have limitted influence over.
No, on this website I signed up with Github. I think?
At least this time I chose to close my account. Next time it can be Facebook/Google/Microsoft/Twitter/Apple who decide that you're a robot/fraud/whatever after receiving a bunch of automated reports.
If Google ever bans me, I'm screwed in many different yet interesting ways.
As FAANG expand into more parts of our lives there are more and more things you're legally allowed to do but shouldn't do if you want to maintain access to all your shit. The TOSs of these vendors can become a de-facto legal regime that limits your rights in new and exciting ways.
That makes them a pretty hard sell for any workplace environment, but also makes them a significant security risk on-par with writing your passwords on a post-it note for anyone looking to burgle... Seems like 2FA is the future...
- The biggest threat almost all users face is in the form of remote attackers: password phishing, database leaks + password reuse, tricking users into installing malware, etc. Local attackers are so far down the list of concerns that, really, using unique passwords and storing them on Post-Its is, for most people, an improvement in security!
- Leaving a Yubikey in the computer is, in fact, the normal, intended mode of operation--that's why Yubico makes low-profile keys that you can just leave in your USB port. Yes, an attacker can just steal the key, but the key alone is insufficient to authenticate in most uses; almost all relying parties using keys that don't support user verification will also require a password.
- The article was about passkeys, not FIDO security keys. Subtle difference, but, importantly, passwordless authn using passkeys requires the authenticator to support "user verification" mode (like a PIN/screenlock/biometric).
I'm not sure what users you interact with most on a regular basis, but for a pretty significant portion of the population, the most likely threats to their online (and offline) safety are jealous boyfriends/spouses/parents
Live in a house with a bunch of other people out of school? Extended family some of which you don't get along with in and out of the house a lot? Certainly for work stuff in an office. Probably not so much. The risk may not be that great in absolute terms but I'd absolutely think twice.
We're talking about somewhere around 65% of the overall population. Entirely ignoring women and children from your target market warrants a little condescention
I will point out that I explicitly called out 2FA as being necessary. And any of PIN/Biometric (not sure what screenlock is), seems like that 2nd factor to me. So if these are different things, then the rollout is going really rocky (on par with Wii vs. Wii U), and they should probably come up with a better naming schema.
I don't think very many people know what "security keys" or "FIDO" are, to be honest, so you're probably in the tiny part of the Venn diagram of people who a) know what those things are but b) don't know that they support user verification. ;)
May I humbly suggest you RTFM before posting FUD.
You can set a PIN on the Yubikey (or on the Yubikey Bio's, your fingerprint).
Further, the PIN will block after three failed attempts, requiring the PUK to reset the PIN.
Key loggers are of course defeated by the Yubikey's touch requirement (which you can make mandatory for all actions irrespective of time between actions, i.e. a no temporary cache policy).
Hence your "security risk" is non-existent.
It only uses the keyboard in the OTP mode[1] (which you don't have to use, and you can even configure to completely disable). I guess OTP mode is probably the one you were thinking of ?
To be honest other than the Yubico demo website, I've never come across a resource in the wild that uses Yubikey OTP mode login anyway. :)
I'm not familiar with the technicalities of OTP mode but I'm guessing its resilient to replay attacks, so key loggers could still be limited that way.
For all other modes (PIV, FIDO, PGP) it doesn't.
I believe there is an option to store a static string in the Yubikey and replay that on-demand when you touch it ... but, well, I'd say you're on your own if you choose that option !
[1] https://developers.yubico.com/OTP/OTPs_Explained.html
I don't use either of them through choice though...
I've seen it used in terminal applications.
A company I worked at years ago used Pritunl as its VPN (which uses OpenVPN under the hood), with Yubico OTP configured.
It was a good-enough UX, and the user enrollment procedure downloads a certificate for connecting to OpenVPN which only works for one user, so when people inevitably spammed their Yubico OTPs into Slack, you couldn't use those to log in to the VPN as them since you wouldn't have their certificate.
A keylogger would probably be able to access the certificate. To get around that you'd need to do something completely out of band like acknowledge a push notification on an authenticator app on the user's phone.
You moved one of the factors.
The possible factors are: Something you know Something you are Something you have
Choose 2.
A PIN would be something you know A fingerprint would be something you are. The key is something you have.
I'm saying in the post that we're never going to just a passkey for this. And the yubikeys I have used in the past have all been just "something you have".
The problem these keys solve is that humans suck at managing passwords. Password managers are nice, but they're also protected by passwords, and humans suck at using those protective passwords.
I'm all for 2FA, but I'd like to see websites switch to key-then-password rather than password-then-key. Most people won't turn on 2FA and physical keys are a lot safer in today's world of leaked passwords galore than passwords.
If you don't enable 2FA and default to using a key, you can still do the whole "forgot password" (or rather, "lost my key") routine to reset your authentication through email.
Using a keylogger and then stealing the key will work but it requires a lot more than stealing a password
I work in a lab that requires fingerprint login (TrustKey FIDO keys) with no fallback.
Every 6-8 weeks I need to have my keys reset with new prints, which is a process that involves meeting a member of the security team in a room for 20 minutes so my key and the backup key (kept in a safe by the firm) can both be reset.
Everyday, without fail, I sit there like a chimp taking on average 2 minutes to unlock my workstation. This happens maybe 5 times per day.
Yes, you're back to entering a password, but you don't have most of the weaknesses and pitfalls of password-based logins in distributed systems (phishing,credential stuffing,keyloggers probably a few others).
Cut your thumb slicing tomatoes? Have fun logging in for the next few days.
Took up a fun new hobby, like, say, blacksmithing, or ceramic sculpture? Say permanent goodbye to your fingerprints ever scanning correctly again...
next time, (besides using gloves for once) drop a blob of shellac on a shallow container with flexible sides (silicone or any flimsy bottle cap). After a few hours, take off gloves and thumbprint for several minutes with very light pressure on the blob of shellac. after another few hours, tie some nylon ties to the side of the container and tighten every now and then so that the end result is a convex plane with your finger prints. you want it slight convex but still mostly plane.
Done. now wait for that to dry. apply some harder finishing synthetic laqueur to preserve it longer. just keep that in your pocket and you will be able to unlock most phones.
note that some phones (correctly) do not mirror your prints, thought most do for some reason... for those you will have to first cast you prints and then cast the reusable token. which make getting a convex token in the end easier tho... but for the dozen of devices i've tested, they all mirror just fine.
... and that's reason #1239090 why using biometrics as passwords are a really stupid idea. it's only good for convenience shortcuts, so fine on phones, bad on anything else.
[0]: https://www.cnet.com/tech/mobile/galaxy-s10-has-ultrasonic-f...
At some point security is a trade-off with convenience, I have a randomly generated >20 characters password that I use only for gmail but right now I'm in the hospital and they won't accept it because I'm not on my usual device and I didn't activate 2FA ... because it's exactly the kind of problem I wanted to avoid.
I know users reuse passwords, I don't, let me use my god damn password.
And my password vault is on my google drive ... someone come euthanize me please.
Google on the other hand, do this correctly. You can configure a consumer Google account to only have secure options listed.
Are you sure about that? I couldn't activate 2FA in my Google account for years because they didn't enable the option without giving a phone number first. Based on my HN experience, many users gave their phone number from the get go and therefore didn't notice that they couldn't activate 2FA without it.
Just checked, and yes, no phone or email recovery methods configured.
Why is there no discussion on users losing their private keys? Ask all those cryptocurrency users who lost their private keys. Now don't tell that there are crypto wallets/vaults that manage private keys; there are many ways key can be lost even when using wallets/vaults.
We engineers live in a different world, disconnected from the regular users who have no clue what public-private keys are!
Luckily, FIDO2 can fix a lot of these problems. People who don't have significant security needs can use a trusted service (currently Apple, Google, and a few small companies) rather than a physical device. Lose your phone? As long as you can get your account onto a new one, you can still access all of your stuff.
Once this type of auth will take off, I can imagine a business model for a FIDO2 company that focuses on customer service. The only problem with the system right now is that if you can't log in to your Apple/Google/whatever account, there's no recovery. Try contacting customer support and see how long it takes until they just block your number, because there is nothing they can do.
Having a business where you can go to a physical office and show up with ID so you can get your account back would solve this problem. Recovery would still be a massive pain, but it's better than spending years on a legal battle like some people trying to get their pictures back from their cloud providers after getting locked out.
I use YubiKeys for accounts I consider important and they're a pretty huge hassle compared to a password manager. I'm also scared to get rid of any of the old ones I've got just in case they're linked to an account I forgot about.
It’s also hard to manage keys you’re loading yourself. Once I loaded a private key onto my YubiKey and accidentally failed to backup the private key because I used the wrong syntax when I exported it. I didn’t even realize until I got a new YubiKey and went to load my GPG keys onto it. I was only using it for signing, so it wasn’t a huge deal, but if I’d been using it for encryption / decryption it would have been a disaster.
The Apple/google “passkey” approach lets you use WebAuthn while having encrypted, cloud stored, private key escrow. It is much more convenient. Obviously with the downsides that implies.
I've wanted something similar, combined with a tree approach to account recovery where the effort for recovery can vary depending on the importance of the account.
Say I lose access to my McDonald's account. That's not a very important account. It just contains some reward points that would get me some discounts at McDonald's. That account would be a leaf on the recovery tree. It's parent node would be my email account, currently at Fastmail. Recovery of my McDonald's account would just require responding to a recovery email McDonald's would send to my email.
My email account is much more important. Its parent node would be my domain name, currently registered at Namecheap. Recovery of my email account at Fastmail would involve demonstrating to Fastmail that I control my email domain.
My domain name is so important, since it is in the ultimate recovery path for so many descendant nodes, it would probably have at least two parent nodes (I didn't say anything about the tree having to be a binary tree).
They would be businesses that can verify my ID in person using government documents like my passport, and provide a way for me to prove that identity to third parties.
Banks would be good candidates to run such a business. Post offices would also be good candidates.
The protocol between the root verifiers and their direct child nodes could be a zero knowledge protocol so that the child node doesn't get your real identity and the root verifier doesn't know who the child node is. All the root needs to learn is that you are being verified for some site, and all the site needs to learn is that you are the same person who set up the account.
Such a zero knowledge protocol could also be good for age verification, which more and more jurisdictions are requiring from some sites. With such a protocol between the age verifiers and the sites you could have age verification without giving up anonymous accounts.
If your domain name can have multiple descendant nodes and multiple parent nodes, is that still a tree?
Actually I guess it doesn't even have to acyclic. You just need a directed graph where that has a non-empty set R of nodes such that (1) nodes in R do not have incoming edges, and (2) every node that has an incoming edge can be reached by some path that starts in R.
Which kind of makes sense, because a tree has stuff that branches out at the top (the branches) and at the bottom (the roots). The trunk has multiple parents and multiple children.
Definitions aside, I like your idea a lot. I feel like it's one of the few propositions that recognizes how important proving your identity already is, and how it will only become more important. The system is flexible and makes sense. It's the kind of thing that I think most people could understand, and thus use.
ic@fastmail-co-uk
And from the article:
> “If I'm Google implementing passkeys, I cede a lot of control to Apple if my user is on an Apple device, I cede a lot of control to Microsoft if the user is on a Windows device, I cede a lot of UX control to Android and browsers,”
To me it sounds like Google, Microsoft, Apple, etc. seizing the last bits of control away from the average person. Everyone will be absolutely beholden to a few big tech companies. Using a fake name or birthday on accounts will be unthinkable because a locked account will mean losing access to your life and the only way to get it back will be to verify your identity which better match the info you provided initially.
We used to have outrage over things like using real names and now we've somehow fallen to the point where everyone is going to mindlessly accept a scheme that could easily morph into verified identities managed by private companies. Participating online will require a verified identity and everything you do will be mapped back to it.
They wrote about it here in 2020: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
I’m not clear on whether it has gained any traction, and it’s not something I see a lot of my peers in security aware of.
However, to be fair, if people have one of something it’s going to be a phone. If you use google or android, then those keys are backed up into the cloud “securely”. Those keys are also “secured” on the device. Not as good as HSM, but if you dig into the details it’s probably much more solid than you’d expect.
Absolutely. I keep my BitLocker keys in my Microsoft account because it's a simple solution that provides good enough security for me. If someone wants access to my data they have to get the key and my disk. I understand it and I'm satisfied with how it works.
With passkeys, having a cloud backup doesn't even make sense to me. If I'm using a YubiKey or a TPM, the private key can't be extracted to back it up, so what do they back up? Do I have to opt in to a weaker system to get cloud backups?
At the very least, I should be able to designate trusted parties (parents, siblings, kids) where at least one of them has to approve the recovery of a cloud backup. Microsoft, Google, etc. shouldn't be able to access it at all. I trust my family, not big tech.
Should you trust Apple? Is this secure enough if a password can still be used that recovers all these keys?
Ultimately there is always a convenience/security trade-off. The “passkey” concept has it right for the 99% of users case (in my opinion). For that 1%, it’s still WebAuthn, so nothing stops you from using a Yubikey with a second safe-held Yubikey for disaster recovery.
That means single device users are in for a bad time if they lose their device.
I don’t see the value in making such a big change for such little gain.
No.
Some of us, engineers, live in a world where 512b RSA is mandatory to order a pizza. Most of us are sane.
So any system that replaces web auth passwords is, worst case, just as bad as a password from a key-ownership perspective. Such a system also has the potential to be much better than a password, for example your auth secret is only entered on a secure keyboard (thumb reader, etc.) and used locally on a device you own, which then handles all auth tasks.
For a password I just click the “I forgot my password” link, I get an email with a link to click, and my account is recovered within minutes. I have recovered 15 year old accounts this way.
If you can’t do that with passkeys, then the system is doomed to failure because people lose their credentials and devices all the time.
And no, the solution to that is not security education, people don't change and a system that expects behavioral changes without enforcing them is simply an insecure design. The truth of the matter is that passwords are insecure and problematic for the vast majority of non-technical people.
I feel like I'm an old grouch who wants things to stay the same... And that's kinda the case :-)
Once at my first home, where I climbed in through the bathroom window (this was a PITA - it was some 12 feet off the ground and just barely big enough to get through.
Once at my current home, where I just used the porch door that I literally never lock.
----
And I'm actually pretty good about not losing my things. But over a 20 year span, I would have been permanently locked out of digital accounts 4 times if you want to play this game.
For me, that's a complete non-starter. So recovery flows will HAVE to exist. At that point, we're right back to where we are now, where I'm much less worried that someone is going to crack the salt+hash of my password, and I'm much more worried that someone will call customer support and pretend to be me.
But all of these digital techniques also allow multiple keys and / or key recovery.
[citation needed]
And that locks them out of most email providers and online services, especially if their only source of internet access is a public library that "looks like a robot" because a lot of people use it simultaneously.
I'm pretty skeptical that passkeys are going to yield much benefit. Websites will still have to maintain a "recovery" flow for the reason above and this is already the weakest link a lot of the time.
Under this model, new authentication pretty much should always leaves a paper trail, while passkey login, could be more like the "remember me" cookie from the old days.
Sorry for the tangent, but has anyone ever heard anything about cross-device cookie synchronization?
Nothing is stopping you from generating a private key from a password that you have in your head, and using that to authenticate to every site.
Obviously, if that password gets stolen, the thief can get into any of your accounts, but that's a choice you have to make. WebAuthn doesn't mandate a specific way of storing credentials.
Nope. If I don't need my car keys I don't carry my keys. I do tend to carry a small wallet and my phone but also carrying a separate hardware token routinely would actually be a pain for me.
Perhaps most people do. There's also quite a few people that lose those keys - perhaps through neglect or being stupid, perhaps through an accident or getting mugged.
Note that of those unfortunate people that lose their keys, very, very few of them lose their house and everything in it as well - there's many paths to normally quick recovery that would need to be replicated digitally.
What's the issue here, people can't export backups of the passkeys?
Quite the opposite. You can, and are always advised to, have a second key as backup that you can keep in a secure location. So in the same way as you don't lose your home if you lose your home's keys, you don't lose your digital access if you have a backup passkey. There is a slight difference between the two scenarios as in the case of your home, you wouldn't lose it regardless of whether you have a backup key or not. But since you can easily have a backup passkey the difference is very small.
I can, and do, backup and safeguard my KeePass database in ways many and various. I have a fairly robust system to backup "traditional stuff" - including sync to my local NAS, a monthly off-site exchange of external drives with my best friend, and a cloud sync.
I have NO clue how to backup my whatever this is keystore or database or whatever, in a way that I'll feel confident I can seamlessly resume my life. It all seems to be embedded in some cloudy or device-internal ethereal opaque invisible places that make my life super easy when they work and when I do predictable things, and make my life devastating when they don't work or I do unpredictable things. I'm literally and genuinely and actually scared of these changes - not for when they work well, which is apparently magical; but when they don't work well or I fall through system cracks through some unknown change or issue.
I don't know why you would want to though. Since (1) passkeys will rarely be a required nonreissuable credential, and (2) losing access to iCloud Keychain is extremely improbable. For many users, showing ID to a phone store clerk is sufficient for iCloud recovery. For others, it's using their laptop, a recovery key, or a recovery contact.
Can you walk me through how that works? I don't know how Verizon, for instance, could get me that access. Or did you mean at an Apple store or something?
https://support.apple.com/guide/security/secure-icloud-keych...
https://support.apple.com/en-us/HT213305
Basically: For some subset of iCloud Keychain users, SMS is used in combination with the lost device's passcode (or a user-chosen password) to recover the keychain. Since the device is lost, you re-issue the phone number with a carrier. I think 2FA or ADP may require another device or a recovery key, but my memory is hazy on this.
Really? That sounds awful. So now everything is passwordless and tied to a single database that can be stolen?
I thought the whole point of passkey was to tie the login to a TPM, Secure Enclave, HSM, etc. managed key because that means the private key is in hardened, tamper proof storage that simply signs challenges.
passkeys.com:
> When a user sets up a passkey, a key is generated and synchronized to the cloud. When the user connects from another device in the same ecosystem, it will use the same key.
WebAuthn supports verified attestations for hardware-backed authenticators. Passkeys seem to be designed for normal consumers, who worry about losing authenticator devices.
So... it does not seem like a very good analogy?
FWIW be sure to assign proper expectations of security to those lockboxes, i.e. very very low.
I make a hobby of defeating them at friends' houses. Takes a few minutes.
The last time I sold a house, I brought the lockbox to the closing to hand to my real estate agent. He was perplexed.
Fair and good warning, but I'm curious, how long would it take you to pick my front door lock instead? Are you saying those lockboxes are significantly easier to defeat than a standard front door lock? (I am genuinely curious! I imagine it could depend on both the particular brand/model of lockbox and door lock!)
(Plus I have bars on some basement and first-floor windows in places that aren't easily seen from the street so seem especially vulnerable, but not on all my windows, someone could always break a window instead. I do not live in a secure military facility).
The real estate agent lockbox can be defeated by a random ten year old kid in less than ten minutes. Watch out TikTok!
Previously, in Northern Europe, I had a condo where the door+lock manufacturers literally cautioned you that the fire department cannot force a quick entry in case of emergency. Think bolts on hinge side of door, etc.
It does seem like it. The things you mention aren't drawbacks of this technology, and this is par for the course for whenever I see discourse on WebAuthn. People just mention random fears that they have, the vast majority of which aren't true.
If you want, you can keep on using your existing password manager for WebAuthn, or use a password. The standard doesn't care.
I have always maintained that 3rd party password managers were a bad idea because now you've got three parties heavily involved instead of two.
For most, this is that but worse -- you have essentially have three parties, and the least savvy is the one with the most to lose (maybe the ONLY one with something to lose) -- and is now the one with even less understanding and control.
Across the board, getting rid of passwords is a stupid idea. I get that what we have now isn't great, but this is way worse; I am certain this fails repeatedly and badly, unless we do the thing we haven't yet done, which is real cost/penalty/liability for the 3rd parties who get it wrong.
I think that's best handled through some iteration: We don't need to flip a switch and make the whole world change to this system overnight. Instead, we could roll it out in managed environments, like companies and schools with IT departments.
I suspect that, for consumers, something like a (the horror!) government agency could handle this. Or a bank. Or your ISP. Or your phone service provider. Or the AAA (who handles passport and license renewals in the US.)
Since the early days in Bitcoin people have been talking about backing up their private keys, and the methods of doing that have become simpler and simpler. Yet we talk to people every day that didn't realize that they can't just "contact Bitcoin" and ask them to reset their password.
Some platforms for creating "secure" backups of wallets apparently had back doors built in (BitcoinPaperWallet dot com I'm looking at you!)
A non-trivial portion of the population (based on my personal experience) is struggling with mental health issues and true analytical weaknesses that make it really hard for them to understand what's happening, or correctly recall what did happen.
Is all of that really compatible with moving secrets into the background (instead of remembering passwords)?
I couldn't find a single open source hardware FIDO L2 implementation.
Looking at the specification, is it even possible for an open source implementation to gain L3+ certification?
Authenticator certification is inherently incompatible with open source, so you are forced to use a proprietary implementation.
The modern cryptography that this stuff is based on was invented only 40 years ago. There is as of yet no useful cultural context to base systems on. You can't expect people to be able to use concepts that don't really exist yet.
even OTP tokens generators goes to great lengths to give a false sense o security that their seed is unique simply by hiding it from the user UI. Google authenticator will happily save the seed and seed tokens in their cloud and allow you to restore. all while still hiding it from the user.
if you have twenty accounts on your OTP, and get a new phone, you have to log in on each site/product. Disable and re-enable 2fa. That's some 2~5min each.
back to passkeys... do you think this will last when google is getting tons of spam on gmail because microsoft is not careful on their spam bot protection? likely google will just shutdown the integration and demand you use google or apple for gmail. This will happen all over all the time.
If they can be distributed they can be stolen, right? I don't see how it's any better than a password manager at that point.
Passkeys are based on WebAuthn, but they are not the same from a user experience perspective. The simplest way to describe Passkeys would be "WebAuthn, but with the keys stored in a password manager instead of being tied to a specific device."
Apple has a pretty good overview of how things look from a user's perspective: https://support.apple.com/guide/iphone/sign-in-with-passkeys... Note that while that while that article is about Apple's specific implementation, passkeys are an open standard with multiple independent implementations.
The biggest issue with Passkeys right now (aside adoption by sites) is vendor lock in. Many implementations don't allow the key database to be exported or transferred to a different Passkey client. That's an issue with those implementations though, not an inherent problem with the protocol.
Nope, sorry. Enshittification makes this entire concept, as-presented, a non-starter.
I don't get it. As soon as a key database can be exported, that means it can be stolen, doesn't it? How is Passkey so much better than a password manager with a good implementation that it warrants all the added complexity?
BitWarden already uses my TPM to gate access to the password database.
Because:
1. Passkeys have better UX, on account of them being able to interface with websites through a standard API rather than through text boxes.
2. Password managers are incapable of eliminating user-memorized passwords, again on account of them interfacing with sites through text boxes designed to facilitate that particular insecure practice.