I’m sure a lot of people (like myself) would refuse to install a special custom TOTP app just to be able to use one site. They’re only hurting TOTP adoption by doing that, and thus increasing the amount of support resources they need to allocate to account hacking / hijacking.
I’m sure there are other companies too willing to go against their economic interests for various reasons, but they’re going to be in the minority.
Once you can correctly answer the question you responded to, you’ll see why its against their material interests to EEE logins, whether its TOTP or passkeys.
No, but the “normal, worst case” usage of passwords is still far worse than even that case. Most people just re-use the same password for everything. This is why almost all companies use phone numbers and text messages as a totp now.
If we’re comparing worst usage of passwords vs worst usage of passkeys, passkeys still wins.
Question: Why did these corps implement TOTP? You should be able to answer this from an economic perspective of them trying to save money.
Another question: why aren’t these corporations locking down TOTP to restrict them to their own validator apps, in the same way you’re proposing that they might do for passkeys?
That’s entirely optional and not forced. You can use FOSS password managers that store your passkeys, that can log into all those services.
If you’re referring to proprietary password managers (IE like google or apples), then that concern applies equally to all the passwords you’re storing with them. So that concern is not specific to passkeys.
I’m using a FOSS password manager for like 6+ passkeys right now, on some of the biggest sites. So this is just demonstratably false.
but in practice they’re being pushed as a way to increase lock-in
Which ones are doing this? Give specific examples of sites that are forcing you to use a specific TOTP or passkey validator.
Those two categories aren’t really meaningful, but even if you consider them to be, passwords (apart from a master password for your password manager) also should never be in the “things you know” category, because then it means you’ve memorized them, and are not using a password manager to generate completely random ones.
And unless you’ve got an incredible memory that can memorize unique passwords like “+28x@!8eaEak!” for 10+ sites, then you’re likely using a pattern or single password than can be compromised.
If you use a self-hosted password manager like bitwarden, then its there. If you use a file-based password manager like keepass, then you can use any syncing method you choose, and its no different from passwords.
Passkeys also aren’t lock-in. You control them, and your FOSS password manager likely already supports them.
Passkey is stored on propietary, trust me bro, “we will never share this with the NSA or FBI” Apple or something account where you can’t export them
No. Most FOSS password managers support them, even keepass and bitwarden. You control them, you can export them as you wish, and even use them across multiple devices. I know because I do this.
The concern is valid, but we should also look at these company’s interests in pushing passkeys, which first and foremost is avoiding all support and resources they have to dedicate to password resets and account hijacking, of which TOTP was the band-aid for, which they also push.
The software or hardware attestation is IMO a non-issue for most public sites. We have a precedent in TOTP, and they haven’t locked those down either to specific software, because they care more about adoption (to avoid the costs above) than controlling what software you use to validate.
If someone wants to say that these companies will turn on this attestation for passkeys in the future, and break a ton of logins and decrease adoption, then they should have a reason why they haven’t done so for TOTP.
Another point someone brought up in one of these posts: the remote attestation (IE locking your passkeyto a specific app or software) issue is highly unlikely to be used for public websites, because it would block / halt the adoption they’re trying to promote, and its against their interest. No website that I know of has done this for TOTP either.
They push TOTP and passkeys now because they want to avoid the costs and support around resolving hijacked accounts, and password phishers.
The use-case for remote attestation is a valid one also: say you have a really secure internal system that you want to lock down to only users of your specific passkey validator, and make sure its that specific app, unspoofed.
An absolutely crazy and true factoid from wikipedia:
I haven’t found this to be the case in practice (IE passkeys are plenty portable). I’ve successfully used passkeys on multiple browsers, OS’s, and apps, all stored using a FOSS password manager (keepass). Any FOSS password manager that is either self-hosted, or syncs, should work just as well with passkeys as it does for regular passwords or TOTP.
Which are those? I haven’t had one that rejected keepass so far.
Despite the attention-grabbing headline, the only negative thing I can find in the article about passkeys are this section:
Attested passkeys7 are the last but most important type of passkeys you need to know about. These types of keys use what’s known as remote attestation to cryptographically verify – using the aforementioned tamper-proof cryptoprocessor that lives in all your modern devices – that you are using one of the several approved passkey managers, and not using a custom one that you vibecoded yourself and which can lie.
This is the feature that means you no longer get to make the calls about your passkeys. Fortunately, attested passkeys are not yet required on most websites.
I don’t see why we should assume this hypothetical is going to happen. There is a lot of different software that supports passkeys (I use keepass for example), and going against the open standard and forcing all their users to use a specific software would basically make them unusable.
Overall every password / login style has its dangers and bad ways to use it, including passkeys. That doesn’t make them “traps”.
Here, but as davel stated these are pointless. The sidebar of all comms shows activity.
I’m not sure what you mean by integrated into the OS. I use a FOSS password manager on android (keepassdx), storing passkeys both for apps and websites. When the browser or an app asks for a passkey, android uses the password filling service you’ve chosen (in my case keepass), and it loads up, no differently from when there’s a password prompt. I’m not sure how it works on other platforms like iOS, windows, or linux, but at least on android, you can use a FOSS password manager not integrated into the OS.
Specific sites aren’t locking down TOTP, this seems to be an EEE scheme of Authy specifically, since as you say the TOTP codes provided by sites still work with other authenticators. I’m referring to the case where say, amazon forces you to use their app to login, or creates their own custom TOTP or passkey app, and won’t let you log into their site without it, and then you have no control over your login method or codes.