Live data from Hacker News

Tailscale doesn't want your password

tailscale.com

251–260 of 316 posts

Re: Tailscale doesn't want your password

#251

Earlier quoted context omitted.

That's up to you, but "that isn't possible yet with this two-month-old technology" is very different from "that isn't possible".

Well, that's my point. People are referring to what is possible today but your "misconceptions" are responses to what could be possible in the future.

Well, I disagree. People aren't saying "I want to use this today and can't because X is missing", they're saying "I'm opposed to this technology because X will never be possible", when it will be.

Look at this comment, as the first example I found:

https://news.ycombinator.com/item?id=36237683

It basically says "Passkeys = USB keys", which is wrong. If you don't like the tradeoffs that specific authenticator makes, use another passkey authenticator type.

"Passkeys are strictly less secure" is just objectively wrong.

Re: Tailscale doesn't want your password

#252
post #139

There are still a lot of questions I'm not clear with passkeys. How do you recover your keys if you lose your hardware? What happens if you lose your phone and have no extra trusted device? There will be no more phone number, and no more trusted device. Most MFA implementation, which heavily rely on phone number, will no longer work. And, for Yubikey, how do you backup? Do you need multiple Yubikeys? Do you need to m…

The passkey people won’t give you a straightforward answer because you won’t like the answer. If the passkey is truly secure, you don’t get your key bak if you lose the passkey. If you make a copy of the passkey, the passkey purists will say it’s not “secure”. If you lose your phone and delete your existing login cookies you don’t get access again. If email or sms is the recovery method, you might not be able to logi…

So here's how I implemented the recovery in my proof of concept. Your backup is performed using your backup private key, and the encrypted passkeys (private keys) are backed up to the server. If you lose your device, you obviously can't login and need your back up private key to recover. I implemented shamir secret sharing, it splits your passwords and you select from your contacts (other users who will agree to serve as your backup). So let's say you have 4/7, that means 4 people out of 7 people is all you need to recover your private key.

When you lose your device and reinstall the app. It asks you if you are recovering or a new user. If you select recovering your key. We will generate a new pub/private recovery key. Remember we are assuming you lost your phone. The app will then ask you to enter the phone number of the 4 people that will vouch for you. When you select those 4 people, a call is initiated to them where you must read off a code that the restoration server gave to you on your new device, they will then select that they are vouching for you. The idea is that these are your friends or people you trust. You have to convince them. Not just automated think. At that point their phone will send the pass key fragments to you (encrypted using your new pub key). When enough people give you the info you need. Your phone will decrypt with your recovery private key and then recover the backup private key.

It will then request the encrypted backup from the server. The server will provide it with the encrypted back at which point it will use the recovered private key to decrypt the backup and recover all pass keys.

Re: Tailscale doesn't want your password

#253
post #42

Earlier quoted context omitted.

How do you bootstrap it? You get robbed at gunpoint by some ruffians and they take your wallet, cellphone, keys, and laptop. Hopefully they can't get into your accounts, but never mind that, how do you get back in to everything?

Recovery code system? Like 2FA today, generate a special bootstrap key you can print and save. This isn't that uncommon. Things like disk encryption also do this (e.g. bitlocker)

> generate a special bootstrap key you can print and save

So ... a password?

Also in this scenario you've been robbed. It's quite possible that either they took your printed out passkey also since it was in your wallet, or you're not at home where you can get the pass key from your file cabinet or safe.

Re: Tailscale doesn't want your password

#254
post #139

Earlier quoted context omitted.

The passkey people won’t give you a straightforward answer because you won’t like the answer. If the passkey is truly secure, you don’t get your key bak if you lose the passkey. If you make a copy of the passkey, the passkey purists will say it’s not “secure”. If you lose your phone and delete your existing login cookies you don’t get access again. If email or sms is the recovery method, you might not be able to logi…

> If the passkey is truly secure, you don’t get your key bak if you lose the passkey. If you make a copy of the passkey, the passkey purists will say it’s not “secure”. That's an uncharitable interpretation. A more charitable way to say this is: You can choose between secure/uncloneable and less secure but more flexible. Passkeys let you make the choice and don't dictate it for you. Choose whatever better suits your…

Who gets to choose?

If it's the user, how do I as a user choose right now?

If it's the service implementing passkeys, why wouldn't they force a solution that's easier for them (less testing/less support/less maintenance, by forcing attestation to a specific list of providers), instead of letting users have an option?

Passkeys are an awesome solution to a difficult problem. But they are one bitflip away from eliminating user choice. Fix that problem, and I think folks here will jump on it in a hearbeat.

Re: Tailscale doesn't want your password

#255
post #191

Earlier quoted context omitted.

>What will work driverlessly? WebAuthn. So, registration and authentization. I'm not exactly sure if which standard deals with changing PIN, but it worked everywhere I tried it out of the box. >OMG did you say CHROME??!!! Yes, how dare I... It was an example. I don't use Chrome either, but not many people do use other stuff, so that's why I mentioned Chrome specifically. Currently, the support is best in Chrome and s…

> Are you trolling? No. Also, only nonces are generated for each new _credential_, so you don't need to store so much data on the key. You should be more worried about how long it will take to do the authentization exchange, which takes under a second from my experience. I'm not talking about the CPU time needed to generate the bits... Aren't the keys device specific so you need to generate new keys on a new device?…

The keys are authenticator device specific. So if you put it on your keychain you never need to generate anything to check your email on random computers. If you use a software solution, then you need to sync the vault in some way, and again don't need to generate anything here.

If you're worried about making a brand new passkey because you're logging in from scratch, that means you need some other kind of authentication to start the process. And that's solidly outside the scope of passkeys, so it's hard to say how difficult it would be. (But if you have an alternate login method, a good system wouldn't force you to make a temporary passkey, it would just let you check your email and log out.) (Also it shouldn't take more than a minute to do key creation/deletion in any reasonable implementation.)

Re: Tailscale doesn't want your password

#256

Earlier quoted context omitted.

> If the passkey is truly secure, you don’t get your key bak if you lose the passkey. If you make a copy of the passkey, the passkey purists will say it’s not “secure”. That's an uncharitable interpretation. A more charitable way to say this is: You can choose between secure/uncloneable and less secure but more flexible. Passkeys let you make the choice and don't dictate it for you. Choose whatever better suits your…

Who gets to choose? If it's the user, how do I as a user choose right now? If it's the service implementing passkeys, why wouldn't they force a solution that's easier for them (less testing/less support/less maintenance, by forcing attestation to a specific list of providers), instead of letting users have an option? Passkeys are an awesome solution to a difficult problem. But they are one bitflip away from eliminati…

The user gets to choose. When enrolling an authenticator, you can choose what the authenticator is. I don't like Google's, so I use my phone and my Solo 2 as authenticators.

Re: Tailscale doesn't want your password

#258
post #176

Earlier quoted context omitted.

> The passkey people won’t give you a straightforward answer because you won’t like the answer. Well, then this culture needs to be condemned strongly.

Why? Security isn't an opinion, it's a science and art. It doesn't care about what you think of it. Perfect security leaves no room for user friendliness. The most secure system allows no users to use it. Only by reducing security do you gain user friendliness. The most user friendly (as in, triviality of use) system requires no security. The art comes in when trying to create more usability whilst giving up less sec…

> If you don't "like" that, then stick to passwords.

But the passkey crowd is overtly aiming at eliminating passwords.

Re: Tailscale doesn't want your password

#259
Modern password managers run into issues regularly that still require a user to copy/paste a password out of a secure location. I don't know what the solution is for these situations with passkeys, but I know I don't trust password managers to do it right.

I've used iCloud, Google Chrome, Lastpass, and 1password, and they all break consistently in a few scenarios. Three that come to mind are:

  - SSO or other systems where multiple logins are linked to the same account on different host names. The password manager will require you to essentially create a separate entry for the new site that becomes disconnected from the original. 

  - Having multiple logins for the same site.  This breaks especially with services that use a multi-stage login, but in general it breaks frequently.  If you have kids or parents whose accounts you manage, password managers will invariably ask to update the wrong password, or attempt to auto-fill the wrong password regularly.

  - Sites that request you enter the old password at the same time as you enter your new password for verification when changing a password.  Password managers can't figure this out, and as a result whenever I have a password manager generate a new credential, I also make sure to copy it to a temporary location until I've verified that it was saved. Typically, because you entered the old password on the password change page, that save doesn't go through.

In the end, all these security features just boil down to how secure your password reset/customer support function is. If you're going to require people to reset their passkey every time they log into your site, why not just use a "magic link" email session initiator and be done with it?

Re: Tailscale doesn't want your password

#260
post #176

Earlier quoted context omitted.

> The passkey people won’t give you a straightforward answer because you won’t like the answer. Well, then this culture needs to be condemned strongly.

Why? Security isn't an opinion, it's a science and art. It doesn't care about what you think of it. Perfect security leaves no room for user friendliness. The most secure system allows no users to use it. Only by reducing security do you gain user friendliness. The most user friendly (as in, triviality of use) system requires no security. The art comes in when trying to create more usability whilst giving up less sec…

I like the part about passkeys where they avoid having a shared secret. Not so much the platform lock in and creeping remote attestation. Oh, don't worry, it's just in the spec, we're not going to do anything with it... yet. Seems like they're gunning for a world where if you're not using a blessed Microsoft/Google/Apple device you're locked out of it.
Post reply on HN