[n42]

if you're someone who uses a password manager already, and is generating unique random passwords for every website, the only appreciable difference between a passkey and what you do today is:

- the passkey is never transmitted anywhere when logging in, eliminating the largest attack vectors for stealing passwords

- you can no longer manually type the passkey in on random devices that don't have your password manager on it

it's basically a really really long password you don't know with some added security guarantees.

if you are not already doing this, then it requires adaptation to a world where you do not know your passwords and they are stored in a vault. this does mean ironing out account recovery for the account the vault is associated with. passkeys don't change that, though.

[somehnguy]

> you can no longer manually type the passkey in on random devices that don't have your password manager on it

This answers a question about them that I've been unable to find a clear answer for anywhere. My passwords are all randomly generated and stored in my password manager. It's cumbersome to type them in on some device without my password manager and I don't do it often, but at least I have the option!

I really don't like the idea that my passwords/passkeys are some thing to just be abstracted away to the point that I have no idea where they are or how to access them manually if needed.

[crote]

Not quite.

The biggest difference is that websites seem to trust a passkey as both a password and a 2FA token at the same time. So security-wise it essentially means giving up 2FA altogether, as passkeys are about as secure as a password manager.

So for anyone with a password manager and 2FA tokens, passkeys are a downgrade.

[stavros]

This is wrong. Everyone here confuses "Passkeys the standard" with "some hardware implementation they've heard of".

Yubikeys require a PIN, and the key is wiped if you enter it wrong ten times. Nobody stops you from making a hardware key that requires a long password to access it. You can do whatever you want, the standard doesn't care how you want to secure your keys. The standard just asks for a key at enrollment and then asks you to sign something with that key at signup.

Anything after that is up to you and your choice of device.

EDIT: I've written a short post to clarify a few misconceptions:

https://www.stavros.io/posts/clearing-up-some-passkeys-misco...

[n42]

that'd be more of a choice by the service operator than a design detail of passkeys, right?

[JohnFen]

> you can no longer manually type the passkey in on random devices that don't have your password manager on it

This is a huge problem, though. My password manager has no online component, and only runs on my phone. On purpose.

When I use it, the password manager shows me the password that I need, and I type it in manually.

I could change to a different method, but then I lose a lot of flexibility. I can no longer log into things from machines other than my own.

Things like Yubikey address some of this, but then I can no longer log into machines unless I have sufficient physical access to plug the key in.

To be clear, I'm not arguing that any of this means passkeys aren't desirable, but I am saying this to point out that passkeys are not functionally equivalent to passwords, and passkeys do restrict some kinds of use.

[kdklol]

No, it's not "just a long password". Here are the main benefits not mentioned, which a password cannot offer, regardless of how securely it is stored: - Phishing protection - passkey credential will be uniquely bound to a domain, so you cannot be phished - Keys cannot be exfiltrated from the hardware, so even if your password manager is compromised, your key would still protect you - Duplication protection - synced counters are stored on both the key and the server, so even if somebody does clone your key (very difficult), you'll know about it (unlike passwords)

Obviously, there are some necessary assumptions made, about security of the passkey implementation, DNS security and so on.

>if you are not already doing this, then it requires adaptation What doesn't?

>ironing out account recovery for the account the vault is associated with Agreed. This is currently the weakest point in web security in general.

I'd also like to mention (for everyone else reading this) that a unique set of credentials is generated per account, so this cannot be used to track you. Also, it's an open standard and open imolementations exist. It is bot reliant on google/yubico/"big tech". They're pushing it because it works.

[nottorp]

> Obviously, there are some necessary assumptions made, about security of the passkey implementation, DNS security and so on.

Basically you need to trust more vendors of security solutions than before, isn't it?

Plus you cannot access your accounts from any random device without an intricate security setup that eats at your time and messes with the device.

As in you cannot borrow your friend's laptop for 5 min to check your email any more. You have to set up your keys on said laptop and then remove them, which makes it a 2 hour affair?

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

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

[n42]

I was speaking about the experience of a user who doesn't care about the details :)

[kdklol]

I understand. In that case I still think it's a bit of an understatement to call it a password, since especially inexpirienced users are more vulnerable to phishing, and this does protect against it, unlike a long password (even paired with other MFA methods!) Also there's nothing to remember or to install, so again, more normie-friendly. Sorry if I came of as too agressive, maybe I should've put in some smiley faceses too :)