Hacker News Reader

Comment by esseph | Hacker News Reader

Passkey on NFC/USB hardware token (x2)

They're cheap enough if you lose one it's not the end of the world. Goes on your keyring. Doesn't require esim management. Use NFC swipe/usb-plug-in + pin to use.

View on HN

The problem with hardware tokens is that they 1) Only store a limited number of logins, 2) It is very difficult to keep them in sync- every time you need to add a passkey, you have to get them both out, which makes it difficult to keep one a in a secure safe to keep it safe from damage/loss

This two fatal flaws are what limits their usefulness to enterprise SSO and perhaps some other limited uses where the organization has the ability to replace tokens. (Even in a distributed enterprise, enterprise SSO may not be a good fit for hardware tokens, if they can't get replacements out to employees fast enough).

> the problem with hardware tokens is that they 1) Only store a limited number of logins,

1) It's one passkey used over and over, so it only takes 1 slot.

> 2) It is very difficult to keep them in sync- every time you need to add a passkey, you have to get them both out, which makes it difficult to keep one a in a secure safe to keep it safe from damage/loss

2) With SSO used across enterprise exactly like you're talking about, works fine without having to reregister over and over. Been using this and have implemented it myself for years.

3) much cheaper than a phone with a much cheaper recovery path

4) no path is a free lunch, you're always going to be making compromises somewhere, it's the nature of security - it is adversarial

> it's the nature of security - it is adversarial

Yes, this is the issue. People don't like how adversarial security people act, and how they force things onto people. It's fine if a corporation wants to have some internal policy since they're the ones eating the cost if an employee can't work or whatever. Less so if individuals are forced into these wonky setups for no benefit. e.g. now I have to run and maintain and backup a Vaultwarden server just to log into my HSA, which is absurd (I also have to keep an old version of the bitwarden extension around and use that because the latest requires TLS, which is another piece of infrastructure that I don't want). My password manager already generated random site-specific passwords. And for some unknown reason, browsers didn't start with the obvious step of software passkey support in password managers, and then allow hardware keys for the nerds that want that.

Oh, right, because it's actually a lock-in play, and it's designed to be unusable unless you tie your entire life to Google or Apple's cloud platform.

The problem isn't the cost of replacing it, the problem is - how do you log in when all your passkey-bearing devices just got flushed down the toilet?

How is that different from accidentally deleting your keepass database? Or forgetting your password? I think it’d be easier for me to forget than find myself trying to flush all my hw tokens…

I can back up my keepass database, and I can write down my passwords.

Same way. A majority generally have a old phone that was already signed in to google. Or if they remember only Apple ID and password (one very difficult password) + sms. They can login on to a new phone.

Everything is SYNCED immediately.

What if you have a ransomeware that destroy everything on the same day your house and all backups burn down. And you cant get it from immutable backups as you wrote that decryption key in paper. And the bank will not allow you to access it as the govt deported you elsewhere.

I can back up my FIDO2 (non-)resident keys too. In the end it's just a piece of HW with some secret material inside. non-resident FIDO2 keys are easier to back up, because the master secret seed is fixed and shared for all origins and there's nothing stored on the key.

I can get another hw key (if one of mine breaks, which I, surprisingly enough, have not yet managed to achieve)

And since I have at least two at all times, the possibility of one of them breaking changes… not much really.

Paper can burn or get tossed, backups files can go corrupt, and I really don't understand what is that extra risk hw keys introduce…

There is at least one valid (in my opinion) reason to not like hw keys though: they cost real money to acquire, so you probably want an extra margin in your budget for the unlikely case they indeed decide to break.

You have more than one key right?

Also... Is flushing your whole keys down the toilet a problem you run into often?

> Also... Is flushing your whole keys down the toilet a problem you run into often?

It's a potential catastrophe I'd like to avoid if possible, but the catastrophe is not inherent to any other key I have.

House key: Make new copy for 10 USD. Alternatively, get a locksmith to unlock the door and change the lock. Even more alternatively, break a window or door. I still get into my house.

Car key: Make a new copy for >10 USD. Alternatively, call roadside assistance and get them to tow me somewhere I can get a new key. More inconvenient, still very possible.

TOTP 2FA and passwords: Password databases can be backed up, and so can TOTP seeds. It's inconvenient to do so, but I can at least still just leave copies around everywhere I can, so that it's extremely unlikely that I'll be completely locked out.

Yubikey: Making copies is literally impossible, so I'll need to buy two or three keys from the get go, and get them all out every time I need to add a new key. This is a huge inconvenience that no casual user will ever do (they might do 3-2-1 if it was set-and-forget, but Yubikeys aren't). If I don't do this, I lose permanent access to my accounts. There is no safety valve built in to the system. If I lose my key, I'm fucked.

But a majority don't do that. For them let them use passkeys. If the possibility is once in 10 years then I am happy to do that. A majority is happy to do that.

And yes, Google or Apple - dont say you should not keep passwords in your database and sync it with dropbox. DIY.

Rest of us want convenience.

Copy pasting my other comment from an earlier thread

FIDO2 USB Security key -> Bitwarden (With master password) -> Every other method (topt/password)

I have 3 FIDO2 USB Security keys, One I carry with my persons at all times, one that stays with my main machine at all times and an offsite backup that is sitting in a friend's server, if my house burns down, I can either physically collect the key or use USB-IP to authenticate back into bitwarden and enroll a new key. (Actually all 3 are at home right now but that's ok)

Its going to be hard to flush my desktop and my laptop down the toilet.

I recommend a reciprocating saw with a metal cutting blade to get them into small enough pieces. Do not try to flush them all of the pieces at the same time. It's not just about whether they fit or not, they also need to be light enough for the water current of the flush to carry them all the way through. Otherwise, they may end up in the water trap and hinder your future use of the appliance. For small partial blockages, it may be possible to consume some extra fiber in order to be able to "sweep" some of the metallic remnants along, but this will void both your warranty and your bowels.

I am a doctor -- and a lawyer and an orbital mechanics specialist, as well as a highly respected behavioral therapist -- so you can trust my advice. Also, feel free to consult an AI on this topic; it would make for an amusing benchmark.

I believe in you.

Pretty easy for a lightning strike to simultaneously destroy both though unless you always unplug your computers during a storm.

My point is if you just flushed your keychain, maybe some terrible accident while drunk at a pub, you should still have at least 1 more hardware key somewhere else. And by the way, your phone is also a viable key. Having a passkey on your phone and a physical one on your person solves most issues, with the rest being covered by having 1 or more in a safe or other secured storage location.

Enrolling two devices stored in different locations for every sign up is extremely annoying.

I suspect that most people that ostensibly do this actually only enroll one for non-critical accounts and then depend on some fallback mechanism.

This is a legitimate problem, and one of the few cases where a third party login provider makes sense, at least for non-critical “apps”. If both tokens can be authorized to that provider, then you don’t need to enroll any more tokens for apps using that provider. The difficulty is creating a trustworthy provider system without weakening security (the provider shouldn’t be able to login without you) that doesn’t collect information about you and which can’t lock you out from all your accounts.

I’m not sure what work has been done on this since Mozilla Persona. I certainly wouldn’t want Google and Apple, or governments, to be the sole gatekeepers.

Why would you choose that over a synchronizing passkey manager?

A third party OAuth provider puts you at the mercy of the service provider, the other can work fully on your client side even if the app provider were to disappear tomorrow.

The only advantage I can think of is that you have a centralized place to revoke credentials in case your password manager does get compromised.

> Why would you choose that over a synchronizing passkey manager?

No second factor, compromised passkey manager leads to compromise of all accounts. This is a huge problem.

> A third party OAuth provider puts you at the mercy of the service provider, the other can work fully on your client side even if the app provider were to disappear tomorrow.

Yes that’s what I was saying, it needs some thought and careful work. It would need to be decentralized, and I’m not sure that current standards are up to the task.

"A third party OAuth provider puts you at the mercy of the service provider" This is they key issue with trusting a third party to manage my passkeys, they can also BLOCK them and lock me out. An exception is if the passkeys are synced to all your devices and cannot be remotely wiped. I think this is how Apple works.

I didn’t think of this in the moment, but you’re right, this is an even bigger risk than compromise. There’s regularly a thread here about someone getting locked out of their cloud accounts, and now we’re going to gate everything behind those same accounts? Horrible idea.

Yes, I'd absolutely not use Apple or Google for my passkeys, even though they now at least seem to support exporting them to other platforms.

Then don't, there are several open source synchronizing passkey implementations!

Reply on news.ycombinator.com