I think that 99% will use something they already have like an iphone, an Android phone, touch id on their mac books, or windows hello. Storage should not be a problem.
Passkeys will come at a cost
101–110 of 600 posts
Re: Passkeys will come at a cost
#102Earlier quoted context omitted.
i think they could be great for websites i don't really care about and already use weaker passwords. but for important sites where security matters? nope
Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design. For "important sites where security matters" they are literally better in every way than a password, it doesn't matter how weak or strong. You can use a pure software solution, and soon probably even your existing password manager, to handle them. Again, you should think of them as replacing passw…
> Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design.
Let's assume a "passkey device emulator" written in software; quite realistic IMHO for someone to use, considering the cost of hardware authentication devices (phones, YubiKey etc.)
If someone using such emulator gets hacked and has their passkey emulator data stolen, is there anything preventing a credential leak?
Re: Passkeys will come at a cost
#103The difference between zero and one factor is infinite. The difference between one and two factors is huge. The difference between two and three is almost negligible. Except in Citrix-like situations where you're sharing the actual reader hardware, passkeys are only useful for a device you have physical access to, and that's already one factor. So in that sense they can replace passwords, I guess, but they seem like a strictly worse solution.
Re: Passkeys will come at a cost
#104Passkeys make no sense. Its selling you something you already own, since a fingerprint or a retina scan makes a fine good two factor as well.
biometrics aren't passwords. They are only somewhat useful as authentication if you can verify that they are attached to the person you are authenticating, which generally only works in person.
Re: Passkeys will come at a cost
#105Earlier quoted context omitted.
Can you give me a high level description of why passkeys won't work with my current hardware key, and then explain why they went with that implementation instead of one that works with my current hardware key?
`rk=required` means your hardware is required to store each and every derived key, not just the master key, all in the service of you not needing to remember your username anymore. Current security keys can handle a couple dozen derived keys at most, _if_ they can handle any at all. This flies in the face of previous promises where 'every key can handle an unlimited amount of accounts'. In my eyes, this looks like a…
As someone who doesn't and won't ever have a mobile phone, I can't comprehend why things are going in this direction.
Re: Passkeys will come at a cost
#106Is it even a good idea to use physical security keys as passkeys in the first place? Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them. IMO physical security keys are better left…
When I use a Yubikey for passwordless authentication (FIDO2), it challenges me for a PIN before asking me to touch the device. If I give it too many incorrect PINs, the Yubikey locks up and requires a device reset, which invalidates all previous registrations to use that key for authentication. It doesn't seem like a big deal if someone steals my hardware token. https://support.yubico.com/hc/en-us/articles/4402836718…
It means though that your secure hardware token has a reliable way where the secrets all self-destruct. That someone can easily do if they get even brief hardware access. For people who have a problem keeping sufficient backups (almost everyone on earth) this seems like a horrific blocker, a show stopper for this entire intiative.
I personally think these things absolutely should be able to be exported & backed up separately. Many people guffaw that now the device isn't secure. But I just don't think I could realistically adopt nor do I expect others will unless users get some better affordances, unless we get some capability to manage trust as we see fit, not just be pushed top down into someone else's desired much narrower security behavior.
(Thankfully it seems like there is building interest in exports & portability, particularly as the OS/browser powered PassKeys arrives.)
Re: Passkeys will come at a cost
#107this is probably a dumb question, but why not just store a secret seed that is used with an on device prng to generate as many secrets as you need where a sequence id gets shared with the counterparty?
how does authn happen here?
RP sends ID and I respond with the secret code? that's subject to replay attacks.
Re: Passkeys will come at a cost
#108Earlier quoted context omitted.
`rk=required` means your hardware is required to store each and every derived key, not just the master key, all in the service of you not needing to remember your username anymore. Current security keys can handle a couple dozen derived keys at most, _if_ they can handle any at all. This flies in the face of previous promises where 'every key can handle an unlimited amount of accounts'. In my eyes, this looks like a…
As someone who doesn't and won't ever have a mobile phone, I can't comprehend why things are going in this direction.
Because almost every human who has digital accounts does.
Re: Passkeys will come at a cost
#109Is it even a good idea to use physical security keys as passkeys in the first place? Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them. IMO physical security keys are better left…
I'm not sure that a second factor was ever the goal of 2FA, but rather the desire was a key that users couldn't pick themselves (because they use their birthday, they tell example.com their Google password every time they log in, etc.)
That said, I don't feel great about letting security keys be the only factor. They can be stolen. So can phones, but phones make you unlock them before they'll be your password. (Windows Hello is the same thing.) That seems like the right balance to me. Your phone can authenticate that you are you; a USB dongle can't.
Re: Passkeys will come at a cost
#110Earlier quoted context omitted.
no not far enough residual keys are IMHO a security misdesign and shouldn't exist but now the industry hype is pushing to make the the de-facto mandatory way
I'm not clear on what you mean by this. Do you mean hardware-backed non-extractable resident keys? Or the more simple idea that your WebAuthN agent can store a key? I don't see a problem with a WebAuthN agent storing a key (ideally locally encrypted at rest with a hardware resident key from a user or device TPM). Having users have a passkey database that they sync across devices is not really a problem as far as I ca…
It's suboptimal: it basically creates the same situation as password managers where compromising that database is game over. It's a much better situation if instead you enroll multiple different keys. The main issue is if you want to automate this you need a standard way to enroll one device on all sites another device is enrolled in, which AFAIK doesn't exist. (you'd also want to have an automated way to revoke another device in the case that it is compromised).
Having multiple keys enrolled would also allow for better recovery from websites in the case of a suspected compromised device: they can simply disable one key, allowing another key to still log in (and either vouch for or disable the other). You could also have flows where certain actions require multiple keys for authentication.