[kdklol]

I knew I should've explained myself in more detail. Sorry.

>Basically you need to trust more vendors of security solutions than before

Yes and no. You may have to trust the vendor of your hardware key, or you can get one that has open source firmware, like NitroKey.

Regarding the number of trusted parties - it depends. To have a account that use passwords, you must trust them to handle your password well. You can mitigate this trust need somewhat by using a password manager and strictly using unique passwords (and ideally usernames and emails too!), but this now requires trust in your password manager. Again, OSS solutions like BitWarden, KeePass and pass make this less of an issue. My point is, if you are handleing your passwords well (ie you are using a password manager), you are not really required to trust more parties, only change which ones. Furthermore, WebAuthn is stabdardized, so unlike with password managers, there's less room for "creative" programmers to make mistakes (like lastpass did).

Regarding DNS security,

I meant that highjacking a company's domain, be it trough compromising their account with their registrar or by non-validated or even non-existant DNSSEC can enable attacks. This is true of other forms of identifocatin though. I just want to be fair and not oversell this tech as a silver bullet. If all things are done right however (like they must be with other forms of id.), this does significantly increase security.

>borrow your friend's laptop for 5 min to check your email any more

In general, no. Assuming they run a reasonably recent version of Chrome and Windows/Linux/Android* (I don't have apple so idk), it will work driverlessly.

You may be surprised to know this, but it's fundamentally a fairly old technology at this point. Hardware keys have been supported in some capacity by systems for over 10 years now, and WebAuthn essentially just standardised what was already there. It was a fairly easy adjustment. At this point in time, I don't know of any hardware key being sold that does not support this nor any common OS (again, besides Apple stuff, they should supported but I cannot test it.)

*Ah, yes, Android is a wierd one. Technically it's not yet in android, but it's been in the Google Play services for years now. But thechnically, there are android devices without those (like mine).

[nottorp]

> In general, no. Assuming they run a reasonably recent version of Chrome and Windows/Linux/Android* (I don't have apple so idk), it will work driverlessly.

What will work driverlessly? The generating of new keys that still will take an hour?

Also excuse me, but did you just say Chrome? I should send Google my browsing so I can use passkeys?

Edit: forgot to mention their AI bans with no appeal process. Do you really want your sole login means in there?

[kdklol]

>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 some other Chromium-based browsers. I personally tried Brave, which worked flawlessly everywhere. Firefox (which I personally use) works with standard WebAuthn, but some big players (Google) seem to have older implementations predating the standard, so it doesn't work with some clients (Firefox) yet. I've watched a conference some time ago where they said they're working on it™.

If you want to know how exactly it stuff works, Mozilla has a nice and easy to comprehend description on their developer site. It's one search away (in your preffered search engine).

>The generating of new keys that still will take an hour?

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.

Please just read the Mozilla website.

[nottorp]

> 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? It's being touted as a security feature. I'm guesstimating that at 1 hour of the user clicking through various interfaces.

But anyway, my concern is passkeys are adding too many dependencies on devices/providers. Giving me a list of possible devices/providers does not address my concern.

[Dylan16807]

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

[kdklol]

>Aren't the keys device specific so you need to generate new keys on a new device? It's being touted as a security feature

Yes, the keys are device specific. This is a feature and the reason why it's more secure. If it could be backed up (exfiltrated), it would not protect you in case your device is compromised, which is one of the design goals. You could probably work around this by using an emulated key (which is what Apple does I think?), but that would obviously eliminate this key security feature.

> I'm guesstimating that at 1 hour of the user clicking through various interfaces.

I see, sorry, I missunderstood.

Again, it's just like changing a password or a TOTP secret. Unfortunatelly, no standard can fix bad UX design, but I sympathize. Silver lining is that even cheaper hardware keys are built like a tank, and software is... well... software.

> my concern is passkeys are adding too many dependencies on devices/providers.

Which is reasonable. The question is, is the dependency worth the security benefit? It seems many major device makers/service providers think so.

> Giving me a list of possible devices/providers does not address my concern.

Well, I can't do anything about that, can I? Nor can anyone else.

I think this is, again, a question of priority. TLS is now essentially a dependency for using the web at large, but it wasn't in the 90s. I'm sure that is of concearn to some people, but most agree it's a net benefit.

[tptacek]

You say "even non-existant DNSSEC" here, but, as a reminder: virtually none of the most popular/important/commercial/whatever-ranking-you-like zones on the Internet are signed. DNSSEC signing is not the norm.

[kdklol]

Not quite true, many popular services do have it. Especially the big ones.

The thing is, I was mentioning DNSSEC as a "full disclosure". Any attack enabled by non-validated DNSSEC on passkey applies to any other form of verification too. I just wanted to make sure I'm not overselling the technology, it's not a silver bullet, but it's orders of magnitude better than anything else.

[tptacek]

Name the popular services that have it. Here's a start: collect a list of popular domain names --- any of them will do --- and write a bash script that loops `dig ds $domainname +short` over all of them. You'll find that I'm not exaggerating, and that my summary of the state of play was in fact accurate.

There is no value to DNSSEC, which is why virtually nobody seriously uses it.