Can someone explain to me, what is the recovery process if I lose my phone when all my accounts are passkeyed? Just create new accounts on everything, full new digital life?
A couple years ago I broke my phone and was unable to access my gmail account thanks to 2FA. This seems like that nightmare scenario on steroids.
Roughly half of new phones are purchased because the previous one was broken.
I don't get the need to rely on hardware passkeys. I prefer password managers. I guess I can accept using hardware keys as a fast means to access my password managers, but I will not rely on them. The only thing that no one can take from you is the things in your brain. I have a number of 10 character alphanumeric random passwords memorized, and I can use one of them as a master for a password manager, which is backed up in a bunch of places, so I don't lose it while maintaining good security.
Not just phishing, server side attacks can hoover up passwords all day long. Also XSS can extract passwords from password managers, etc. Passwords are dumb. The static/symmetric nature of passwords makes authentication fully transitive, where if A can be tricked into logging into system B, then an attacker on system B can use A's credentials to log in to system C. This is fundamentally broken.
We've had asymmetric authentication for nearly 30 years now, it's insane that people are still using passwords to authenticate to stuff.
> We've had asymmetric authentication for nearly 30 years now, it's insane that people are still using passwords to authenticate to stuff.
The thing is, anything but passwords is extremely challenging for non-tech users. Even SMS-based 2FA is too much for tech illiterate people.
You do not want to be the support staff for a service that has 2FA enabled. It's utter madness - people lose their 2FA devices, get them stolen, drop them in water, run over it with their cars, have them eaten by your pets (Yubikeys seem to have a particular attraction to cats and dogs as toys), forget them at home before a vacation, of course no one prints out their 2FA recovery codes... and then there are the scammers who pretend one of these events has happened and the account needs to be unlocked, or those who fell victim to a phishing scam and now 2FA is under the control of the attacker.
> The thing is, anything but passwords is extremely challenging for non-tech users.
People usually manage to not loose/destroy the keys to their houses/cars very often. A FIDO token is very similar. You just need to understand that it's important to not loose it and that you should have a second backup key. I don't think this problem has anything to do with being a "non-tech" user.
> People usually manage to not loose/destroy the keys to their houses/cars very often.
Lol. Friend of mine works in real estate... losing keys is very common.
> You just need to understand that it's important to not loose it and that you should have a second backup key.
And how many people have that? Know that? Don't skip the dialog warnings because they've been conditioned to do so? And on top of that, what about the services that only support one 2FA device like Amazon AWS with Yubikeys?
> Lol. Friend of mine works in real estate... losing keys is very common.
Ok, fair point. That's why it'd be good to have a second key somewhere safe. The FIDO token also is just one key that can be used for multiple websites. That's like having many houses and all can be unlocked with one key.
> And how many people have that? Know that? Don't skip the dialog warnings because they've been conditioned to do so?
I don't know, you're right perhaps not that many. But the problem is maybe also that people do not want to pay ca. 60$ for two yubi-keys just to be able to use the same websites their using with a password already. Perhaps the passkeys login using android/ios (e.g. authentication via fingerprint with your smartphone) is going to be much more popular because it's more convenient and "free" (except you pay with your data).
> And on top of that, what about the services that only support one 2FA device like Amazon AWS with Yubikeys?
Yeah, services that do that or even have 2FA as a paid-only feature need to change that. It's just a system flaw on their side in my eyes. Hopefully, such bad practices will bring those services a big enough competitive disadvantage in the future that they're forced to implement 2FA properly.
The attacker controls the login form. They could use javascript to just scrape it out of the password field if they wanted to. Those solutions might get in the way of existing tools for logging password forms, but there are trivial workarounds.
Hardware keys are vulnerable to other things. Like getting stolen, getting lost, getting broken or getting hacked. Uasually at a moment where you can't readily replace them.
"Phishing is possible to avoid" is almost as true as "it is possible to write safe C code." Technically true, but practically not so much.
Now, I grant that for most of us, if you are the target of any nation state level actor, not much you can do. For the most part, they can just compel the party that has your data. That said, security keys are far safer than portable data.
I don't mind to differ on this one. Your reaction certainly didn't address any of my concerns about practicality of HW keys in any scenario where you're not just sitting at home and can lose your key, and will be fucked if you'll not be able to recover or downgrade your security for a little bit until everything's normal again.
Maybe to secure corporate accounts against phishing, or whatever. But for my personal stuff, I need to be able to recover in many ways at any time with just a random computer and internet access without any special HW that may not be readily obtainable the moment I need it.
I don't think you are wrong, but I do find it funny how the threat models get built so differently.
My personal feel is I'm ok not having my key with me when I'm "out and about." Is no different than my not having some of my ID cards with me. Such that, I'm already "locked out" of many of my financial accounts and such when I am not at home. But, I fully ack that that is a personal choice here. I just can't think of any situation I've been in, in a LONG time, where I was needing to randomly use a computer.
Edit: It also occurs to me that keeping keys to get back into your home is almost certainly similar in concern here. As somewhat crazy as I think the "keychain" nature of these tokens is, it does address a large part of this problem.
I just realized that there are a lot of kids out there with all the balls necessary to hold their parent's keys hostage.
Even if you would never be tricked into giving up or losing your key, there are other people in your life who can do it either for themselves or be tricked or compelled into doing it for someone else while you're asleep or in the shower or any of 1000 opportunities every day. Would you immediately detect a good fake substitution? When would be the next important login that needed it?
Phishing/MITM-resistance is not specific to hardware keys. Software can implement the same primitives that a hardware key does. Indeed, the phishing resistance of WebAuthn comes from the browser rather than anything really specific to the authenticator.
I think(?) token binding would have moved more of the validation to the authenticator, but I'm not sure, and I think it was dropped.
What a hardware key can do is make it so even if someone has your device and PIN code, they theoretically _still_ can't steal or clone your passkeys, and the RP can implement attestation which is very useful in an enterprise scenario. Though, I wouldn't trust either of those guarantees in the case of a state level adversary...
True, but password managers can potentially reduce the risk of phishing, since they're the ones autofilling. There's probably work that would improve the UX here but even still.
Of course, it's not nearly as good as being totally phishing resistant like U2F, but IMO it's a big enough win that we should still be pushing password managers very hard.
> The only thing that no one can take from you is the things in your brain. I have a number of 10 character alphanumeric random passwords memorized, and I can use one of them as a master for a password manager...
Because keyloggers don't exist, and privileged processes can't read from ram?
I love bitwarden - but there are many ways my passphrase might be compromised. This is a little alliveated by 2fa - but unless the 2fa comes from a second hw device, there's almost complete overlap between threats that compromise my passphrase (for bitwarden) and my 2fa secret (in bitwarden or another 2fa app)...
I really dislike the spare key solution. It forces users to either carry both keys with them all the time (and risk losing them together), or introduces massive friction into the account creation (have to fetch the spare key from whatever safe or friends house you store it in).
I don't understand why better solutions are not considered. Why not derive keys deterministically, so that you only have to backup the seed (a lá SQRL)? Or encrypt the new account with a public key, and store the private key in a safe.
To me, "use a spare key" is on the same level of unpractical advice as "just memorize long unique passwords".
What I really want is duplicate keys. I should be able to order a set of 2-3 Yubikeys that are identical.
It's getting better, but for a long time the majority of places that supported hardware keys only supported adding one. Places that support multiple keys are better, but they require that I go through the "add a key" process twice and that I be at home (or wherever I store my second key) in order to add it.
If I had one key on me and one identical key at home. Losing a key still means I can't log in until I retrieve my spare key, and I should replace the set, but it's a much better situation than having a single key and roughly no worse than losing one of two unique keys.
my solution is a combination of all of these things:
- I have three yubikeys — one at home, one on keychain, and one backup
- I have three accounts that are secured by these yubikeys: my email, my password manager, and my Apple ID. these are the core accounts that are Game Over if access is compromised or removed to/from all three.
- for these three accounts I have recovery codes printed
- the recovery codes and the backup yubikey are stored in a safe deposit box at my bank
- for literally everything else I use my password manager (1Password) with its built in 2FA
the idea is, anything other than those three accounts getting compromised is not a risk since they all have unique email address (Fastmail masked emails) and passwords. software 2FA is Good Enough since it is backed by hardware 2FA for my password manager. and if I lose access to one of those three core accounts, I should be able to finagle my way back in.
since I'm not adding hardware 2FA to new accounts, I don't need readily available access to all yubikeys at once.
as soon as passkeys are pervasive I will generate and store them from 1Password.
this lets me have relative convenience in a majority of scenarios with focus on reducing risk of being totally fucked out of everything. it's obviously too much for a normal person, but for a professional in tech, I find it appropriate for my threat model/risk tolerance
> The chance of loosing all of them are really slim.
True, but you sacrificed some safety for that. If you're not home, you can only create accounts protected by the keys in your person, and you're one robber (or fall into a pool) away from losing those accounts.
I'd never accept a password manager with such limited sync, and those are usually free. Paying for three hardware keys and still having such limitations is beyond me.
I'm all for hardware keys, and I'd love to use them to replace all my passwords, but I still wouldn't call your setup "adequate" in terms of either cost, friction, or safety.
How often do you create new accounts at FIDO-supporting sites? You must have a different internet usage model than I do.
You can also add the additional keys later. If it's a serious enough account to be protecting with hardware keys, and you only have a couple keys with you, add a note in your password manager to remind you to add your other FIDO keys. You could add that note to the username so you can't login without editing the username and acknowledging it.
It sounds like a non-issue you're turning into a hypothetical concern because... I don't know, you don't like paying a quite modest amount of money for increased security?
Falling into some water won't brick a yubikey anyway.
> How often do you create new accounts at FIDO-supporting sites? You must have a different internet usage model than I do.
It’s introducing one more frustrating make-work item for the human. Now I have to remember to enroll all my keys at all the sites I’ve used them for. Totally manual. Totally forgettable.
These keys should act like HSMs and have proper backup and restore. Even if it locked me into a specific key manufacturer (like lost HSM backup/restore functionality does) I’d take that over the idiotic “just have multiple keys and manage keeping them all enrolled manually” story.
Here's an example of what I consider a reasonable hardware key security model:
I can initialize a Nitrokey HSM on a disconnected PC with whatever device key encryption key (DKEK) I want (128-bit AES key). I can write that key down and store it in a safe place (broken into chunks, if need be, for my security model). I can backup my keys generated by the Nitrokey to export files that are completely useless w/o my DKEK. I can store those backups wherever I want without any loss of security.
If I lose my Nitrokey device I can buy another, initialize it with the same DKEK, and restore my key backups. (If I really want to I can decrypt my backups using my DKEK.)
If I don’t want to do any of that I can have the Nitrokey generate a random DKEK that is never exposed. Then I lose all my keys permanently when I lose the key. I have the option to choose the model that allows me to backup my keys if I want to.
If the point of the hardware key is to put the owner thru pointless make-work and risk then the hardware key is serving somebody other than the owner.
> If you're not home, you can only create accounts protected by the keys in your person
I'm not often creating many accounts away from home, and I'm not often then away from home for long periods of time where this matters. I'm also just not often creating that many accounts.
If I'm out someplace and I need to create an account but don't have all my authenticators, I'll either just go without 2FA for that brief period of time or just go with the authenticators I have with me. Then when I'm home (probably within a few hours) I'll add those extra authenticators.
I also use a password manager. Yukikeys are a poor choice for authentication despite what the article says.
But they are good for 2FA, which is what I need them for to mitigate the risk of phishing, siphoning credentials from my phone or just stupidity on my part.
A robber would still need the password so I'm safe for my threat model, which doesn't include state actors.
But you are right about one thing: adding those keys to all the important account, and adding a new one when you lose one, is a pain in the butt.
But it's similar to other 2FA methods. First you can use alternative 2FA. When you don't have any more, you can use your recovery codes. If you don't have those, you have to rely on wetware - call support, prove your access in some other way.
> After the tenth failed attempt, the escrow record is destroyed.
This reads like literal nightmare fuel. Something out of a dystopian sci-fi novel. You get ten attempts to remember your PIN or your entire life will be utterly destroyed. You are locked out of society.
Also, what about if I break my iPhone and buy an Android[1]? Just SOL? That seems pretty anticompetitive
Tried once to see what access to a human I had with a personal GCP account billed a few hundred bucks every months, and the answer was “not much”, except for specific technical categories defined in the contact form.
Google provides backup keys you can print out and place in a safe. I find that to be the best solution generally.
I also think there is room for different methods for different services. For work accounts, I can contact my boss and have them ship me a new hardware token if necessary- losing only a day or two worth of access (It is even possible for the company to temporarily remove the Hardware Token requirement- or to allow me to enroll a Hardware Token I can purchase locally if necessary). That may work okay for a bank account too- where the bank can verify my identity.
For services with not human interaction, pre-generated backup codes seem the most sensible to me.
I was relying on backup codes until I recently learned (via a PSA on HN) that you should actually backup the TOTP QR codes and not rely on the 2fa backup codes because they may not provide the same level of access.
Specifically, the HN post claim was that using a backup 2FA code to get into your Google account won’t allow you to add a new authenticator app.
Phones don't act as authenticators for FIDO2 yet AFAIK. You usually have either a separate hardware dongle or the OS implements passkeys (WebAuthn in software), which are cloud synced.
The way to deal with losing an authenticator is you have multiple of them, including several backups, one in your home safe, one at your friend's place etc.
No, they do now. Both iOS and Android have full support. Look up “passkey” for more info. Basically, google, apple, MS, etc etc are all supporting this tech now.
The recovery process is defined for both Apple and google, as is the device transfer process.
But then you have to make sure you're home when you setup any new online account (so you can go into your safe and add your backup key to it), or remember to do so when you get home :/
This new passkey stuff adds use of your phone as an authenticator with a laptop or other system via bluetooth with (unfortunate) cloud-mediation.
Before that, some phones could already offer their embedded security chip as a U2F authenticator with the browser app. E.g. I setup the Titan chip in my Pixel 5a as another authenticator with a Google account. But, it only works with a browser on the phone itself. Since the phone browser can also access a Yubikey, I could use the Titan chip to enroll a new Yubikey or vice versa.
I do wish there was a standalone "security key" USB mode I could select alongside file transfer, picture transfer, tethering, or charge-only. Then, I could more reasonably use the phone's embedded security chip as a redundant U2F key for many different services I would normally only access from a PC.
> This seems like that nightmare scenario on steroids.
I'm an oddball in that I'm using a U2F (for SSH) / webauthn (Google, domain name registrar, etc.) device on which the master key can be reset.
It's a tradeoff: I now better make sure nobody steals my "paper seed" in the real world and I better make sure I don't lose it [1]. But in exchange should I lose/break/someone steal my device (which is protected by a PIN btw), I can initialize a new one.
Now there are schemes (like m out of n) where you can distribute, say, part of the paper seed to several siblings/family members/friends or store a part in the safe at the bank, etc. Making it highly unlikely you'll ever lose access to your master paper seed (which is a list of 12, 18 or 24 words out of a vocabulary of 2048 words).
As a bonus the device has a tiny screen which tells you if you're registering to a new service or authenticating and tells you the name (if it's a known service, hardcoded in the device) and/or ID of the service you're authenticating too.
It is protected by a PIN.
It has a plausible deniability feature where you can unlock a fake master key.
And I can buy as many of them as I want and initialize them all with the same seed and then hand them to family members/friends/put one in the safe at the bank. They're all protected by a PIN anyway. So if my house burns down, I'm not sorry out of luck: I can be back in business immediately (i.e. without needing to order one, wait for it to arrive, then find back my paper seed and reinitialize it).
Originally it's a cryptocurrency hardware device but I don't care about that. The CTO of that company was part of the original FIDO alliance.
The device I use is a Ledger Nano S (cost $79 bucks or so) and I load one "nano app" on it, the "U2F" one (works for SSH and works for webauthn).
Now I don't know exactly what's going to happen now that Google, Microsoft and Apple are teaming up to embrace FIDO2 with their new "passkeys" standard (which AFAIU ain't 100% finalized yet).
From the testing I did it looks like Google removed the "counter" verification from their site, which allowed to detect cloned security keys. They used to check for clones, but don't anymore (or at least don't warn the user anymore). I'm nearly sure this removal of clone detection is related to the upcoming "passkeys" thinggy.
I don't know if the older U2F devices (which are compatible with Webauthn as Webauthn is only a server side protocol change) shall still be usable once the "passkeys" is finalized: if anybody has infos on this, I'm all ears.
Meanwhile SSH since 8.2 can use all U2F keys (including the Ledger Nano S) and that is a godsend already.
[1] although if I realize I lost my "paper seed" and I still happen to have my FIDO2 device (or any cloned one I prepared in advance), I can enroll a new device so I'm not totally screwed. And I'll had that many people using a security key that cannot be clone do still use "backup codes" they write down on a piece of paper, which is not safer than writing down a list of words allowing to reinitialize a FIDO2 device.
Yeah I use the GPG functionality for a lot of stuff. SSH keys, file encryption, my password manager (which is zx2c4's pass, basically using GPG file encryption). The software toolchain is anything but friendly indeed. On Android it's the easiest with Openkeychain but in Linux and Windows it's hard to get gpg running with CCID key support (USB smartcard which is what the Yubikey emulates). It's also pretty buggy, gpg's scdaemon tends to crash a lot.
Technically I could move some of this stuff over to FIDO2. Like SSH logins. But I don't see the point until I can move all my usecases over, and older SSH servers don't support it, like the ones in my HP iLO boxes which I can't update. So I'd still have to keep 2 separate systems side by side which isn't worth it.
So on I go but yeah it isn't for everyone. FIDO2 will make this a lot better. Eventually. Right now Firefox doesn't even support passwordless FIDO2 logins (CTAP2) on Linux or Mac, only on Windows... This really keeps me from implementing it because I use Firefox on FreeBSD and Linux. I really don't get why Mozilla doesn't prioritize this.
I haven't tried using the GPG mode on mobile, but I've had absolutely 0 issues with it on Linux. Just followed the arch wiki setup and this random guide I found: https://github.com/drduh/YubiKey-Guide. I use it daily to ssh into hosts and sign git commits.
On Windows, it's a bit more involved, of course, especially for SSH. I seem to remember that I did find at one point some hack which allowed ssh to use the GPG agent. Since I only rarely use Windows, I didn't care enough to test it through. Code signing seems to work well enough. SmartCard emulation also works well enough, but it does seem to conflict with some other mode, either U2F or GPG, can't remember which. You have to un/replug the key to switch modes.
I am also quite... surprised at Firefox's apparent lack of priority for supporting CTAP2. I've seen there are long-open bugs, but not that much interest. My understanding is that on macos and windows, it delegates the user verification to the os, and on linux there isn't anything for that. FWIW, chrome seems fine with implementing their own.
Thanks for the link! The main problem I have is that gpg-agent won't start in ssh-agent mode automatically. I noticed on Ubuntu that there's some scripts that check if this directive is present in ~/.gpg/gnupg-agent.conf and then start it accordingly (and not load gnome-keychain) but this is not working correctly. I spent ages messing around to get it to load.
These days I use FreeBSD with KDE and it was a bit easier to get it to work. But I still have the scdaemon crashes a lot.
But yeah I really wish they would finally fix CTAP2 on Linux. I think the problem is a bit chicken and egg / there's not many services actually supporting it yet. Microsoft 365 is the only one I use that has it. And there it's in 'preview' so my work doesn't allow it, on my personal instance I do have it enabled though.
Passwordless U2F is no longer in preview on Microsoft 365, at least when I look at the config through the Azure AD interface.
However, the situation is actually worse than that on the MS front. Because it actually requires user verification even when used as a second factor, you cannot use such a token at all with MS's ecosystem. Which basically means that if you use Firefox on Linux, you're stuck with less secure second factors.
Paradoxically, MS Edge on Linux doesn't support CTAP2, either, although it's based on Chromium, which works OK.
Ah, great point. I forgot they have basic FIDO only keys. I have mostly the NFC and micro ones. I also picked up the Google Titan keys back when, but since they are FIDO only... it greatly limited my use of them.
Can someone explain why people seem to be so happy with hardware tokens that they're okay with doing away with a password entirely? Doesn't that bring us back down to single factor authentication (now just 'something you have')? Or is the argument that if the majority of users only have a single factor anyway, hardware tokens are a better single factor than passwords, and that ideally everyone would still have two factors?
Does nobody else here have an actual key to unlock their car / housing?
Like this was a solution that has worked for a long time. Sure houses/cars get broken into all the time but so do online accounts and judging my my spam mail, more people I know have had their online account hacked than their car/house broken into. And I know many more instances of people forgetting their password and reseting it than them locking their keys in the car.
The difference between houses/cars and online accounts is that a physical key must be joined to the single matching physical lock, which reduces the number of possible attackers dramatically and forces them to operate in meatspace.
This means that a less secure solution is viable because there are fewer attackers and they are more likely to get caught. It also means that an easily-lost solution is more acceptable because it's easier to persuade a locksmith or police officer that I actually own the property: I can hand them my driver's license in person, and I'd be risking immediate arrest by even trying to pull off a social engineering attack. This allows recovery of a key to be far easier in the real world.
Physical keys to digital accounts cannot be as easy to replace because if they were, anyone anywhere might be able to persuade the digital "locksmith" that they're me, and the worst case scenario for the social engineer is that their attack fails and they try again later.
> The difference between houses/cars and online accounts is that a physical key must be joined to the single matching physical lock, which reduces the number of possible attackers dramatically and forces them to operate in meatspace.
Sure but a digital physical key uses a much more difficult password than you could memorize so even though there are more attackers the difficult of breaking the key has gone up.
> Physical keys to digital accounts cannot be as easy to replace because if they were, anyone anywhere might be able to persuade the digital "locksmith" that they're me, and the worst case scenario for the social engineer is that their attack fails and they try again later.
I fail to see how this is different from the current password status quo. This is quite literally a well published attack vector into accounts, call up support and pretend to be the other person using their data from w/e leak happened recently enough.
With a physical key there's going to be way less people forgetting their password so the same staff can spend more time verifying that somebody is who they say they are (or a company can do the same quality will less staff).
With devices that have biometric validation it becomes something you have (unextractable private key in secure enclave in laptop, phone, or hardware token) + { something you are (face or fingerprint that unlocks secure enclave) || something you know (pin or password that unlocks secure enclave) }
Of course recovery codes are a single factor, so to have it be 2FA still they should not be memorised (to keep them as something you have, not something you know) and be locked away in a way that adds a second factor, e.g in a safe locked by biometric or gated by an id check (bank, notary office) for something you are, or a pin/code/password for something you know.
Sounds cumbersome? Maybe, maybe not. It all depends on your trust model + threat model. Maybe a bank is too much and a trusted friend or neighbour is fine for "id check", maybe not. The less you trust the less options you have for recovery.
As an example: What if one dies? Is there a recovery procedure? Does it entail someone mentioned in a (paper or digital) will having a death certificate at hand? Then one has to trust the designated person not to fake a death certificate, and so on and so forth.
There is a standardisation process with multiple stakeholders.
Some stakeholders want hardware devices that are secure even if the OS has been completely compromised - even if they have to trade off usability and price to achieve it.
Other stakeholders think iPhone biometrics are pretty great, and if you've logged in with full credentials and indicated indicate the phone is trusted, going forward the combination of recognised phone + biometrics is good enough, even if it doesn't secure against a compromised OS.
And in a spirit of standardisation and vendor independence, if iphone face recognition is good enough, why shouldn't the face recognition on a phone from Honest Abraham's Used Cars And Android Phones also be good enough?
It is the latter group of stakeholders that are currently ascendant.
Passwords are a bad way to authenticate. They allow stealing, hard to keep up and easy to forget. Also they are not very comfortable... With FIDO, your device can be stealed but it's much harder to penetrate. It also allows easy sync between multiple devices, and you don't have to worry about having high entropy.
Characterising FIDO2 as a single factor is over simplifying it.
You have to convince the FIDO2 token to prove it's presence. Yes, for many, all it takes is plugging then into a USB socket. And yes that's just one factor - having the token. But some tokens ones require a fingerprint. That's two factors - having the token, and a fingerprint it recognises.
But move to a device like a phone and the games changes. It could just be the presence of the phone. More likely it will probably insist the phone is unlocked. But the app could demand a fingerprint, or face recognition, or a PIN, or be in a particular location, or see other devices it knows, or some combination.
It depends on how you're using it, but the hardware token generally requires a pin for most operations. I think the real argument is that hardware tokens absolve the web host/service of responsiblity for passwords. With tokens I'm just presenting the challenge given a public key. Nobody can hack all the tokens at once like they can a database full of passwords.
Would love if my security token could unlock my house/car. Would go a long way for me to convince others that keeping one of these keys is meaningful.
As it is, the ones that go on a keychain are basically useless for the vast majority of people. Even folks that will be using a key often, are best off getting the micro that you leave in the device.
While I'm glad to see this be dome with the W3C (that way it can actually be standardized and used by more than just two platforms), I find it kind of odd that something like the Secure Remote Password protocol (SRP) hasn't seen much use. Or at least I haven't seen it, correct me if I'm wrong.
That way the password is never known to the server and we also don't have to rely on hardware keys. Personally I don't know anyone using hardware keys, they're just annoying to use...
You can rely on individuals doing sane things, but you can never rely on 'everyone' to do sane things. Hence recovery options exist, and those always cause security problems.
I think a really amazing application for this technology is in places where people are unable or face challenges to manually passwords. For example due to equipment such as gloves, or extreme weather conditions etc. or even disabilities... - it's a good secure way and slotting in a device in a port can sometimes be much quicker and easier than taking off equipment and entering passwords. Furthermore, a physical device can be easily destroyed if it needs to be. If its in your brain... you can't destroy your brain and someone can always get to it... Extremely stressful conditions can also make it hard to enter or even remember passwords... Lastly, a robot or even flying drones can be used to slot in a key to a device. entering some code on a keypad would be more of a challenge in such cases. radioactive, chemical or gas leaks and other hazardous circumstances might prevent an operator from entering a password...
I think technologies like this should first aim to be implemented in places where to original methods we use aren't applicable, or face challenges. Once those areas are covered, it could be considered to be pushed to more mainstream applications if indeed it is found suitable and understandable, and people have had time in real implementations and operations to iron out the creases that 'regular people' will definitely trip over. Also, having it applied in certain fields might help to convince people it's actually more practical, and not prone to account loss as the default sentiment always seems to be.
in short: Like with a lot of technology it should a) first find a place where it's really urgently needed, and has obvious benefits, and little downsides.
b) through that, earn trust of potential consumers in order to apply it more broadly.
It might sound a bit off the ball, as essentially the aim is to increase security for all people in interacting with services / devices / data etc., but you need to start somewhere more practical rather than trying to immediately come up with that golden solution which will put a lot of people out of business. such solutions ,even when achieved, are rarely implemented in the real world or face adoption issues anyhow. (due to 'harsh competition' usually... )
A couple years ago I broke my phone and was unable to access my gmail account thanks to 2FA. This seems like that nightmare scenario on steroids.
Roughly half of new phones are purchased because the previous one was broken.