Hacker News Reader

Comment by Shank | Hacker News Reader

> 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.

View on HN

> I believe all of the issues you've described, but you can usually add multiple passkeys to each service.

How does this work? Do I have to visit the website of each service from my secondary device for it to get the alternate passkey?

Yes. You go an add secondary passkey when logged in on another device. Or with another tubikey.

But not all setups support this. Some only allow one. Obvious issues abound.

> But not all setups support this. Some only allow one. Obvious issues abound.

I'd go as far as to say "most setups don't support this. Most only allow one".

The services I've seen so far that support multiple passkeys are in the minority.

I can't stand services that only support a single U2F key (cough AWS cough)

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.

Is the app the only way you interface with your bank? It doesn't have a website?

All of the things I've used passkeys on support both web and mobile auth, which necessitates two keys.

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.

Yup. I've inadvertently done this, and should probably add a third device.

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.

Still beats passwords in ever meaningful way.

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.

100%.

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

I strongly recommend the book. It’s considerably better and gets into the dystopia better.

Yeah, off-topic but I definitely agree. The book is an easy read and good. I didn't know there was a movie; I should watch it.

Thank you for the recommendation. It's now on my list.

The initial poster described that process - you bring government IDs in person to an office.

If you want to avoid that, just set up multiple devices.

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.

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.

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.

Phones? You can buy a yubikey

What difference does it make? You still have all the same disadvantages.

There's a huge gap in price between a phone and a yubikey.

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.

Yubikeys can have PIN and biometric protection.

> 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.

> A main idea of passkeys is that the private keys are bound to hardware and cannot be copied.

This seems incorrect. “ Like passwords, passkeys are encrypted and stored in your iCloud Keychain”

I also just recently set up some passkeys via 1Password and they are also not hardware bound.

Why is a piece of paper not a piece of hardware? We do this for TOTP too as a last resort, nothing wrong with that.

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.

Passkeys are stealable no? If I have you phone...

You still need my password or fingerprint to usea passkey, and can't transfer it from my device to yours.

Doesn't sound a whole lot different from TOTP to me.

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.

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.

> 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.

Why do you care?

> The real, simple solution would be a way to write down the passkey, similar to an SSH private key.

Except shorter for convenience. Something you could even memorize.

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.

Reply on news.ycombinator.com