It’s best practice, don’t you know.
Yeah i mean Toyota Australia is not the only company that has never taken notice of xkcd: Password Strength
What’s next? “please use a password you’ve used in the past so you don’t forget it”.
There’s no hope for passwords at this point passkeys are the only salvation
Are passkeys any more deanonymizing than passwords?
When you log in you inherently link all your sessions together. You generate a new passkey per account so there’s no way for services to link you to your other accounts just from your passkeys, but you will be reidentified every time you log in of course, and if services require other identifying info like a phone number or email then passkeys can’t help you there.
Passwords can be used to link your accounts though if you reuse the same password over and over. So I would say passkeys are superior to passwords if you want to prevent services from linking your accounts together.
I agree this is the case for most people. But for those who use 12-16 character randomly generated alphanumeric passwords + TOTP that seems stronger.
I like passkeys but I don’t like that there’s no MFA, and that you need a browser extension. So if someone gets access to your Bitwarden vault for example through a browser extension they can have unhindered access to everything. Otherwise it’s hardware based which is better for security, but of course not very flexible.
Ultimately though if it’s between a passkey and Password1! I choose passkeys every time.
Depending on the settings MFA is actually enforceable with passkeys. It can require hardware bound keys (no sync) and require a pin or a biometric. So something you have (the device) and something you are (biometric) or something you know (pin).
Yeah, unfortunately there’s a problem with credential managers not actually properly enforcing user verification. But assuming they do, then yeah it basically does cover MFA.
Well yeah that is with synced passkeys not with hardware bound onces.
Everyone pretty much uses a password, so you are in a universal set of one.
For passkeys, the relying party can often obtain an AAGUID from the WebAuthn registration/authentication data. That AAGUID can be looked up to map to the authenticator’s maker/model class, so you can theoretically be put into smaller sets. In fact, I have recently noticed that relying parties have started making the passkey UI nicer by showing labels like “Windows Hello” or “from … password manager,” which suggests they’re using the metadata available to them. You can be made more common or less common—at least from the RP’s perspective—by the combination of authenticators that appear in your account.
Password policy is good but…
ts happens when engineers are not security engineers..
That’s what I was wondering about, thanks.
Ah that’s pretty lame. Ideally they should all behave the same anyway and it shouldn’t matter who made it, I thought that was the whole point of a universal standard.
Yeah, they don’t have to keep the info; the info that is given and requested should supposedly be used to verify that your authenticator fits with the RP’s security policy (and then discarded), but you know how that goes…
Yeah surely they could just have an API that estimates the entropy. KeepassXC does this locally.