4 ms·
Your two arguments are actually arguments against using any password/passkey manager at all. So it seems like you are actually arguing that people should not be
by jesseendahl 2y ago
Your two arguments are actually arguments against using any password/passkey manager at all. So it seems like you are actually arguing that people should not be using password managers, which is pretty bad advice given how we've seen how that turns out for the world: most people using weak, reused passwords, falling prey to phishing attacks, and all of the above resulting in tons of compromised user accounts.
- drdaeman 2y agoSorry but this is completely wrong. Passwords are not device dependent. Save for some user-hostile enterprise environments that try to implement passwords without letting user "see" them, you can store passwords on any medium, with as many copies as you deem necessary, and use them however you want. Passwords are vendor independent. They're just a shared secret piece of information, there is nothing whatsoever that can even theoretically tie them to any provider. My "hunter2" secret is not and cannot be held hostage by Apple or Google or 1Password or anyone else. Passkeys in their current state lack both of those properties. If the Passkey committee would've explicitly made it in the spec that: 1) any compliant non-HSM-backed Passkeys SHOULD be exportable in a standardized text-based container format; 2) any compliant Passkey implementation MUST be capable of importing passkeys in the same standardized container format; 3) any compliant Passkey accepting service MUST provide means to authenticate via a QR code, Bluetooth connection, or, in absence of either, MUST provide a way for a manual fido:/ URI input as a last-resort measure; and lastly 4) there must be no way to distinguish between a hardware and software based Passkey - all those issues would be solved. But that's not happening.