Comment by seemaze
5 days ago
Smells like FUD. Who's providing the ability to ban software? Providers are free to implement authentication requirements like SDC vs MDC the same way they can enforce minimum password entropy or maximum password age.
In practice I'm aware of more 'lock in' behavior in the form of restricting which TOTP client is accepted than for Passkeys. There are many more bespoke 'Authenticator' apps than there are passkey implementations, many of which disallow registering codes in third party wallets.
Bitwarden also syncs TOTP. Given it's the same client, why push folks to opt for a provably weaker protocol with higher potential for user harm?
> Who's providing the ability to ban software?
The people who wrote the spec. If the spec didn't care about what software was being used to handle passkeys, they wouldn't have written in the ability for whatever you're authenticating to to know that.
The spec is bad and the people who wrote it should feel bad.
> In practice I'm aware of more 'lock in' behavior in the form of restricting which TOTP client is accepted than for Passkeys.
I've never seen this before. This reads like FUD to me. Every single site that I use TOTP with (40~ going by the number of secrets I have) didn't give a shit, and I don't see how they could, unless they use Super™ Special™ TOTP™ just because they're so special and wish pain and suffering onto their users. It's just a QR code you scan or a secret you manually type in, which then gives you some numbers you use later, and that's all it should be.
> Bitwarden also syncs TOTP. Given it's the same client, why push folks to opt for a provably weaker protocol with higher potential for user harm?
TOTP doesn't have a higher potential for user harm. If you use it with Bitwarden, the phishing resistance passkeys tout is something you already mostly get (you can still manually copy the code, which I believe to be a good thing, believe it or not).
Given how inconsistently passkeys are implemented and how it's more difficult to get at the actual data being used (unless you export them with Keepassxc (or Bitwarden?), the potential for fuckups is much higher with passkeys.
I'm yet to see someone get phished. It must happen, given that's how passkeys got started. But the far more common ways I've seen are sessions getting snatched and data leaks, neither of which passkeys protect against. It's a marginal benefit in exchange for so many downsides.
It's not FUD. It's just my opinion and a bad spec.
>I've never seen this before
Microsoft, Apple, Adobe, Cisco, Steam to name a few.
>It's just my opinion
Fair enough. I find TOTP to be a PITA. I share your ire with user hostile platforms, but I see the passkey protocol as a net benefit to the status quo. It's unclear how a platform's choice to use a stricter version of the protocol is any different than their choice not to implement RFC 6238 at all.
> Microsoft, Apple, Adobe, Cisco, Steam to name a few.
I use normal TOTP with Microslop. Presumably you can opt into a worse version if you use their enterprise software, if you're evil or whatever.
The rest I presume fall into the bucket of 'wants to cause their users pain and suffering'. That's the normal modus operandi for Adobe and Cicso at least. The only one of those I use is Steam, and I haven't needed to log into Steam in over 2 years, since I'm just always logged in. Fair point though.
> Fair enough. I find TOTP to be a PITA.
I do too. Yet passkeys manage to be even more of a pain in the ass with ominous potential consequences on the horizon. If it was TOTP plus some phishing resistance without any actual downside, I'd have no beef. If it was TOTP but simpler, then there's be negative beef. There are however several clear and present downsides to passkeys. That just makes for a worse tradeoff (depending on your values) rather than a genuine improvement.