HN2new | past | comments | ask | show | jobs | submitlogin

I haven’t dug into this but I must be missing something with passkeys.

It’s the same issue I had with getting a Yubikey.

The odds that I lose a piece of hardware that I’m carrying on me seems orders of magnitude greater than the odds of having my password cracked.

How does one recover from a lost device (other then backing up to Apple’s private cloud in which case you’re beholden to them forever to be able to access your own accounts).



> The odds that I lose a piece of hardware that I’m carrying on me seems orders of magnitude greater than the odds of having my password cracked.

I 100% agree with you, but the counter argument I've heard is that "it's worse if someone else gets into your account than if you get locked out."

This does make sense to me in some scenarios. Like, if the author of some core Javascript package gets locked out of their Github, they can't push updates to the package; if a hacker gets into that person's Github account, they can push malicious updates to said package. Better to be locked out!

If this describes you, I think a Yubikey makes sense. Personally, I am not in this category!!!


I have two Yubikeys, one of them never left my home


The "have a backup token" workflow seems like tedious make-work. I have to remove it from its "safe place" and keep it proximate to my primary token while I enroll it in everything my primary token is enrolled in.

The workflow to enroll a new backup token (when the primary is lost and the backup becomes the primary) also seems like tedious and error-prone make-work.

It would great if I could load my backup token's public key into my primary token and export a copy of the primary token's secrets, encrypted with the backup token's public key. When I lose my primary token I would only need to restore my backup token and be back in business. That eliminates the make-work of enrolling on the backup token.

Of course, this scheme allows for "cloning" of a token so it'll never be allowed by the "security" nannies who know better than us.


> It would great if I could load my backup token's public key into my primary token and export a copy of the primary token's secrets, encrypted with the backup token's public key. When I lose my primary token I would only need to restore my backup token and be back in business. That eliminates the make-work of enrolling on the backup token.

Yes, exactly this. At one point I had a list of services that I utilize along with a list of the yubikeys I had enrolled on each. My plan was to enroll my backup key periodically (retrieving it from its safe place to do so). This ended up being a giant pita, and despite my best efforts, the list became out of date. In the end I just use Google Authenticator for everything since I can back it up.


My Yubikey is only used as a factor to enable access to my password manager from a new computer. I only need it when I reinstall my computer or buy a new one.


The things you use only once every so many years is typically the kind of things you can't find the day you need it. Unless it is stored in a safe in a bank.


I'd have to lose BOTH to lose access to my password manager: the one that's attached to my keychain in my pocket, AND the one that's at home in a drawer. That'd be quite the bad luck.


I have a second one but its pointless, I'm bad about registering it as a backup token in the few places that even have UIs for doing it, most places don't even let you register more than one.


So do I, but this is annoying because I need to have physical access to both of the keys when setting up 2FA on an account, or hope that I remember to add the backup yubikey when I get back home.


I have 3, yet having two pretty important systems where only one (a single 1!) yubikey allowed to be registered or only support phone app based MFA. (having the misfortune being made to work with about two dozens of web services, it is soooo twentyfirst century putting everything into the clouds regardless if it is a good idea or not)

I ended up disabling MFA in one case - with the most terrible flavour of implementing MFA - because f you!, they ask me to re-login on my stationary main home computer repeatedly for 'security reasons' (idiots) and I too many times end up the particular MFA gadget being somewhere else than at the reach of my hand, obstructing my efforts and workflow too often. Using computer systems are wasting efforts nowadays rather than helping, with the forcing through of cutting edge advanced 'solutions' without thinking about the broad picture (the curse of single-mindednes).

And then we did not even talk about my bank, completely different animal giving no shit about third party physical keys, yet another different way to get blocked if not done exactly as those particular fellas dreamed of in cheerful company meetings not caring collaborating on generic approaches.

MS is particularly bad and not to be trusted with their "insightful design" (it is told this way in the article, HAHAHA, funny guy) solutions f-ing up two things while pushing a marginal one through. With important ones the ratio is higher.


The great thing about bitcoin crap is that it's real world public/private keys used by the general public.

And oh man tons of almost millionaires have lost their backups. Tons of people still have stolen credentials. Basically nobody can "do it correctly".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: