Live data from Hacker News

Tailscale doesn't want your password

tailscale.com

271–280 of 316 posts

Re: Tailscale doesn't want your password

#271

Earlier quoted context omitted.

Writing your own is only an option as long as everyone ignores attestation. Which might be what everyone does -- but the standard absolutely supports attestation, so there's no guarantee.

I don't see attestation as such a big problem. If a site doesn't support your (perfectly compliant) client because of attestation, complain to that site so they know they lost a sale because of it. Companies aren't willing to lose customers for no reason.

> Companies aren't willing to lose customers for no reason.

If only companies would've known this... Can you please start by explaining this to the infamously ass-backwards banking industry? ;)

Re: Tailscale doesn't want your password

#272

Earlier quoted context omitted.

I don't understand the issue here. Passkeys are just a way for a site to ask your browser for credentials. If you don't like the current solutions, write your own, and it'll work with all Passkeys-enabled sites. Why do you need the standard to be different?

> If you don't like the current solutions, write your own Do you see all the large vendors cooperating on letting third party Passkey implementations seamlessly replace their own? I don't. Do you think it is realistically (and not theoretically) possible to implement a new solution that would provide the security properties as good as sum of all individual fragmented options? I'm not sure. And even if someone spends…

> Do you see all the large vendors cooperating on letting third party Passkey implementations seamlessly replace their own?

Yes, given that I use my open source Solo 2 to log in to any Passkeys-supporting site already. It's not about whether they will support it. It's an open standard, you can use whatever you want.

Re: Tailscale doesn't want your password

#273

Earlier quoted context omitted.

I don't see attestation as such a big problem. If a site doesn't support your (perfectly compliant) client because of attestation, complain to that site so they know they lost a sale because of it. Companies aren't willing to lose customers for no reason.

> Companies aren't willing to lose customers for no reason. If only companies would've known this... Can you please start by explaining this to the infamously ass-backwards banking industry? ;)

You mean the industry nobody can leave because there's no way to live modern life without a bank account and they know it?

Re: Tailscale doesn't want your password

#274
post #30

I haven't yet looked into the inner mechanics of passkeys, and the link only talks about the first login. What is the experience like when a user wants to log in from a different system? They press the "Login with Passkey" button on Device 2, and then...?

It presents a qr code you can scan with the other device. You can try it on https://passkeys.io

> It presents a qr code you can scan with the other device.

What about devices that have no camera?

Re: Tailscale doesn't want your password

#275

Earlier quoted context omitted.

Writing your own is only an option as long as everyone ignores attestation. Which might be what everyone does -- but the standard absolutely supports attestation, so there's no guarantee.

I don't see attestation as such a big problem. If a site doesn't support your (perfectly compliant) client because of attestation, complain to that site so they know they lost a sale because of it. Companies aren't willing to lose customers for no reason.

> they know they lost a sale because of it.

Most of the sites I worry about aren't commercial in nature. They aren't getting "sales".

But I'm not going to complain to any company-run websites about anything anyway, because the odds are overwhelming that they simply don't give a shit. That's been my experience over years, anyway.

Small human-run websites are a different matter. They tend to care quite a bit. But they're also the least likely to stop accepting passwords.

Re: Tailscale doesn't want your password

#276

Earlier quoted context omitted.

> If you don't like the current solutions, write your own Do you see all the large vendors cooperating on letting third party Passkey implementations seamlessly replace their own? I don't. Do you think it is realistically (and not theoretically) possible to implement a new solution that would provide the security properties as good as sum of all individual fragmented options? I'm not sure. And even if someone spends…

> Do you see all the large vendors cooperating on letting third party Passkey implementations seamlessly replace their own? Yes, given that I use my open source Solo 2 to log in to any Passkeys-supporting site already. It's not about whether they will support it. It's an open standard, you can use whatever you want.

This means you have one single Passkey system. I'm talking about multiple Passkey systems and that there is no way to make it work without a very inconvenient process.

Three arguments:

1. Redundancy and failover. Without backups, "if I'll lose access to that account" is not even a question, "when" is. Unless you have a second Solo 2 in your safe - some day, you will lose that account. You may be able to recover it, of course, but that's another story (a story of security properties of your account and ability to access it without having credentials).

2. Availability. If some device (e.g. an iPhone) won't support your Solo 2 (e.g. you don't happen to carry that Lightning-to-USB-type-A adapter) - you don't have access anymore, even if you have your key with you.

3. Convenience. You may log in only with your single Solo 2 key, but you'll probably want to be able to log in to your websites from your phone, without having to walk to your desk (even if for a few feet) to grab the physical key for every single new website.

I can think of a scenarios where you won't hit those limitations. The problem is, they're not some weird ass case for silly nerds - they're real situations that are gonna happen to your average Joe (but he, unlike nerds, won't really think about those until they happen).

Re: Tailscale doesn't want your password

#277

Earlier quoted context omitted.

> Do you see all the large vendors cooperating on letting third party Passkey implementations seamlessly replace their own? Yes, given that I use my open source Solo 2 to log in to any Passkeys-supporting site already. It's not about whether they will support it. It's an open standard, you can use whatever you want.

This means you have one single Passkey system. I'm talking about multiple Passkey systems and that there is no way to make it work without a very inconvenient process. Three arguments: 1. Redundancy and failover. Without backups, "if I'll lose access to that account" is not even a question, "when" is. Unless you have a second Solo 2 in your safe - some day, you will lose that account. You may be able to recover it, o…

Again, though, that's beside the point. If you want a system that provides that, use one. You aren't locked in to any single company. It's an open standard.

Re: Tailscale doesn't want your password

#278

Earlier quoted context omitted.

This means you have one single Passkey system. I'm talking about multiple Passkey systems and that there is no way to make it work without a very inconvenient process. Three arguments: 1. Redundancy and failover. Without backups, "if I'll lose access to that account" is not even a question, "when" is. Unless you have a second Solo 2 in your safe - some day, you will lose that account. You may be able to recover it, o…

Again, though, that's beside the point. If you want a system that provides that, use one. You aren't locked in to any single company. It's an open standard.

Again. No system that I know about provides those properties today, so your "use one" advice is, unfortunately, impossible at the moment. Well, without having that rite I've already mentioned a few times (which violates the "convenience" property).

It's an open standard that everyone are building siloed systems on. It's exactly as you have said - I'm not locked in to any single company, but if I have devices or programs from multiple companies that bundle different implementations and don't let others in, I don't have any means to make them interoperate.

This could change someday. Fortunately, there is no fundamental design issue that prevents it. But I'm talking about what exists today and how the standard is bad for not even trying to address it, despite this being a very obvious issue.

Re: Tailscale doesn't want your password

#279

Earlier quoted context omitted.

Again, though, that's beside the point. If you want a system that provides that, use one. You aren't locked in to any single company. It's an open standard.

Again. No system that I know about provides those properties today, so your "use one" advice is, unfortunately, impossible at the moment. Well, without having that rite I've already mentioned a few times (which violates the "convenience" property). It's an open standard that everyone are building siloed systems on. It's exactly as you have said - I'm not locked in to any single company, but if I have devices or progr…

I don't think that's the case. Yes, you'll have to wait a little while, but it's not like many sites support this today anyway. Very soon, most password managers will support it (KeePass does today, AFAIK), and then you can use your password manager as your Passkeys provider on all your devices.

Re: Tailscale doesn't want your password

#280

Earlier quoted context omitted.

> Companies aren't willing to lose customers for no reason. If only companies would've known this... Can you please start by explaining this to the infamously ass-backwards banking industry? ;)

You mean the industry nobody can leave because there's no way to live modern life without a bank account and they know it?

Exactly! :-)

Companies aren't willing to lose customers at scale, but they aren't doing anything for the customers if they won't lose them anyway. For most services, most customers except for some diehard ideologists would just bend over and begrudgingly go with the attested option. And a company won't bother using engineer's time if it's only a few people.

So minimum-value random internet blog is probably not going to require attestation - except if they have no idea about it whatsoever and will just use some off-the-shelf solution and enable it because it sounds more secure, without realizing the issue. Anything that has significant value will do as they please and customers may voice some unhappiness, but will obey. And as long as voiced unhappiness is minor (there are always other issues) it will be ignored as not something worth spending resources on (even understanding the issue requires some valuable time).

Post reply on HN