Why Login Security Sucks(matduggan.com)
matduggan.com
Why Login Security Sucks
https://matduggan.com/why-login-security-sucks/
80 comments
An SSH key isn’t exactly a long password since the service you use it for can’t leak your private key in a security breach
The password isn't leaked, a hash of the salted and peppered password is the only thing in the database (+ the salt, and the pepper elsewhere).
Assuming it's implemented that way. Which is a big assumption.
As the main post was written in the voice of a knowledgeable developer picking a login flow, I assumed so indeed.
I still cannot understand why mutual TLS never took off anywhere besides Gov [1].
You know how much more convenient it is to just open a browser and go to a webpage and already be logged in?
[1]: https://en.wikipedia.org/wiki/Common_Access_Card
You know how much more convenient it is to just open a browser and go to a webpage and already be logged in?
[1]: https://en.wikipedia.org/wiki/Common_Access_Card
Wouldn't that broadcast a stable identifier to every site you visit?
Isn't that desirable?
Safari (Apple), IE/Edge (Microsoft), and Chrome (Google) all operate their own ad networks. I'm sure they'd love their own version of X-UIDH [1].
[1]: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
Safari (Apple), IE/Edge (Microsoft), and Chrome (Google) all operate their own ad networks. I'm sure they'd love their own version of X-UIDH [1].
[1]: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
that's precisely why it's not desireble
Mutual TLS was necessary but a giant pain in the butt for an app I worked on that needed to do over the air updates over WiFi. Getting it working across all of the moving parts was a significant part of the overall effort for the OTA part of that project.
OCSP existed back then which helped but I don’t know if stapling had been widely implemented yet.
OCSP existed back then which helped but I don’t know if stapling had been widely implemented yet.
Yes, I deliberately didn't say it was _exactly_ a long password. I was more trying to get across the single-factor side of it.
In any case, if the service handles passwords properly and the user generates one password per service (both wild far-out concepts unfortunately), leaking the salted hash would not matter.
In any case, if the service handles passwords properly and the user generates one password per service (both wild far-out concepts unfortunately), leaking the salted hash would not matter.
Agreed, but it’s nice to not have to trust a service to handle passwords correctly
[deleted]
> An SSH key is effectively a really long password with cryptographic properties
"An SSH key is basically a really long password, but also at the same time it's not a really long password, and you interact with it entirely differently." OK.
Modern password managers make long passwords vaguely "look like" SSH keys much in the same way a truck might vaguely "look like" a train. But they only achieve this by taking over the creation and use of the password entirely, even going so far as to tie them to origins in your browser, to prevent them from being inserted into a hostile webpage (phishing attacks still work just fine.)
So they're not really passwords anymore, just bearer tokens. But bearer tokens are not SSH keys, anymore than a password is an SSH key.
The SSH analogue to login passwords are SSH passwords, not SSH keys. And nobody uses SSH passwords anymore for the same reason people don't like web passwords, today (at least on the web 90% of the time you can email reset.) Even the follow up methods like credential stuffing are identical; typing in a password to a hostile SSH server will absolutely result in that username+password being spammed at every possible service as a brute force method. The reason this method isn't still popular today is because collectively ~everyone started using keys like 20 years ago for everything. But credential stuffing and phishing are still massive problems for the web.
"An SSH key is basically a really long password, but also at the same time it's not a really long password, and you interact with it entirely differently." OK.
Modern password managers make long passwords vaguely "look like" SSH keys much in the same way a truck might vaguely "look like" a train. But they only achieve this by taking over the creation and use of the password entirely, even going so far as to tie them to origins in your browser, to prevent them from being inserted into a hostile webpage (phishing attacks still work just fine.)
So they're not really passwords anymore, just bearer tokens. But bearer tokens are not SSH keys, anymore than a password is an SSH key.
The SSH analogue to login passwords are SSH passwords, not SSH keys. And nobody uses SSH passwords anymore for the same reason people don't like web passwords, today (at least on the web 90% of the time you can email reset.) Even the follow up methods like credential stuffing are identical; typing in a password to a hostile SSH server will absolutely result in that username+password being spammed at every possible service as a brute force method. The reason this method isn't still popular today is because collectively ~everyone started using keys like 20 years ago for everything. But credential stuffing and phishing are still massive problems for the web.
> We are fine to use SSH keys as our only authentication factor for servers…
Are we? True 2FA for ssh keeps getting easier. There’s FIDO2 support now for example. The gold standard includes 2FA and I don’t see why that shouldn’t continue filtering down to common practice, just as has already happened with ssh keys.
Are we? True 2FA for ssh keeps getting easier. There’s FIDO2 support now for example. The gold standard includes 2FA and I don’t see why that shouldn’t continue filtering down to common practice, just as has already happened with ssh keys.
How much does the recipe of strict requirements limit entropy of the password or enhance its predictability (both are somewhat related)?
More of a problem is password reuse for multiple sites, which is impossible when using SSH keys.
More of a problem is password reuse for multiple sites, which is impossible when using SSH keys.
Not to admit to poor security practices in public, but I don't generate different ssh keypairs for every server I log in to. If each keypair represents one password, and we're never supposed to reuse a password, I'm in trouble.
Ah, so the problem is the HUMANS! This is great, because all we need to do is switch out the humans.
[deleted]
> It is unclear why generating a one-time password for the user is bad but if we call the password a "recovery code" it is suddenly sufficient.
The OTP is usually very long, highly randomized (you don’t get to choose Summer2024!), and designed to be stored offline somewhere as a break glass. Passwords typically follow none of those rules.
The OTP is usually very long, highly randomized (you don’t get to choose Summer2024!), and designed to be stored offline somewhere as a break glass. Passwords typically follow none of those rules.
Also, recovery codes can only be used once, and every usage triggers a notification to the user and potentially a signal for internal risk analysis systems.
> highly randomized (you don’t get to choose Summer2024!)
Sure.
> designed to be stored offline somewhere as a break glass.
That's fair.
> The OTP is usually very long,
No, 10 digits is not very long, that's just 10^10 (about 2^33). The xkcd password ( https://xkcd.com/936/ ) is better than that. It's better than Summer2024 perhaps, but not all that much better.
Sure.
> designed to be stored offline somewhere as a break glass.
That's fair.
> The OTP is usually very long,
No, 10 digits is not very long, that's just 10^10 (about 2^33). The xkcd password ( https://xkcd.com/936/ ) is better than that. It's better than Summer2024 perhaps, but not all that much better.
The xkcd password requires the use of spaces as legal characters. For some reason, this is still an issue with the majority of orgs with complex password requirements.
I practically see red when they tell me I can’t use spaces in my password. What kind of clown car are you idiots running over there?
I worked for a government agency who banned @, because it would SQLi and break their Oracle-based LOB apps when you logged on and when they synced your password in the clear.
correcthorsebatterystaple isn't much worse
Sorry, when I said OTP I mean the recovery code OTP. They’re often 16 hex, so 16^16
> Summer2024!
wait, how do you know my pw?
wait, how do you know my pw?
If I'm going to be forced into two-factor authentication, I would much rather use TOTP than be forced to use a phone number. Phones can break.
Yes. The absolute worst 2FA is SMS based, especially when they refuse to work with my VoIP numbers (I now have a $5/mo 2nd eSIM plan just for this since my primary SIM is data only).
IMHO, just let me check a box that enables me to ONLY use username and password all the time, no extra steps or IP-based captcha or “verify it’s you” by clicking an extra email. My passwords are unique and strong and the provider is more likely to get hacked than my passwords get cracked.
IMHO, just let me check a box that enables me to ONLY use username and password all the time, no extra steps or IP-based captcha or “verify it’s you” by clicking an extra email. My passwords are unique and strong and the provider is more likely to get hacked than my passwords get cracked.
> I would much rather use TOTP than be forced to use a phone number. Phones can break.
Phones / SMS is also less secure than TOTP. It’s odd that most orgs that require 2FA yet accept only phone calls or sms as the second factor are financial institutions.
Phones / SMS is also less secure than TOTP. It’s odd that most orgs that require 2FA yet accept only phone calls or sms as the second factor are financial institutions.
[deleted]
Many of the questions about TOTP lengths / timing / storage are covered in the Security Considerations part of the RFC[1]. This is written in fairly plain language. The meta answer is if you're implementing a security protocol yourself, you should always be reading the RFC for this sort of thing. If you're designing a library to implement a security protocol, you should document the parts that need to be implemented according to spec (e.g. storage / transmission / time / etc.).
[1]: https://www.rfc-editor.org/rfc/rfc6238#section-5
On a what can we do perspective. We actually need some higher level concepts in play than just the APIs. What you really care about is:
1. You can identify the user.
2. The identity used by the user doesn't have a single point of failure.
Passkeys solve only the first part. You want the browser to tell you that the user has synced the passkey to another place other than just the browser. Or you want some other way to remove the reliance on a single factor.
The problem you really have though is not everyone has the same ability to sync passkeys. For some apps giving you an email address is likely secure enough to satisfy requirement 2. I hate it being the primary option though - that's annoying AF.
[1]: https://www.rfc-editor.org/rfc/rfc6238#section-5
On a what can we do perspective. We actually need some higher level concepts in play than just the APIs. What you really care about is:
1. You can identify the user.
2. The identity used by the user doesn't have a single point of failure.
Passkeys solve only the first part. You want the browser to tell you that the user has synced the passkey to another place other than just the browser. Or you want some other way to remove the reliance on a single factor.
The problem you really have though is not everyone has the same ability to sync passkeys. For some apps giving you an email address is likely secure enough to satisfy requirement 2. I hate it being the primary option though - that's annoying AF.
The credentials api seems rather opaque to the user. What happens if I want to log in temporarily from a strange computer that isn't synced? Will I be shit out of luck? What if I don't have my own device with me?
I am anxious about the fact that if you lose your phone in the modern world, you are in for so much work and inconvenience. I don't carry my personal laptop everywhere you know. So throughout the day, for many hours my phone is basically 1FA, not 2FA, and I think that goes for lots of people.
I am anxious about the fact that if you lose your phone in the modern world, you are in for so much work and inconvenience. I don't carry my personal laptop everywhere you know. So throughout the day, for many hours my phone is basically 1FA, not 2FA, and I think that goes for lots of people.
the problem is the threat models for different sites and apps aren't the same, and so security protocols that cover the maximum bases for compliance, identity, security, privacy, recovery, and moderation don't have a lot of flexibility.
the only thing that is going to change authentication is a new mode for working online and the death of the browser from AI rendering most of what we need.
maybe this polarizes, where on one end you have the resurgence of TUIs that raise the technical bar and normalize cryptography and key management for tech work, and at the other we have AI interfaces using a kind of real time biometric context, mediated by some opaque hardware integration. I would be surprised if we're still typing passwds and TOTP tokens in as little as 10 years.
the only thing that is going to change authentication is a new mode for working online and the death of the browser from AI rendering most of what we need.
maybe this polarizes, where on one end you have the resurgence of TUIs that raise the technical bar and normalize cryptography and key management for tech work, and at the other we have AI interfaces using a kind of real time biometric context, mediated by some opaque hardware integration. I would be surprised if we're still typing passwds and TOTP tokens in as little as 10 years.
But you could break most of the apps I use into a handful of kinds, and apply rules accordingly.
Like there’s no reason my bank, brokerage, and doctor shouldn’t use the same degree of paranoia. But who cares if someone cracks my hackernews password. I haven’t associated my account with any projects or my real identity so the worst you can do is make me look like an idiot or get dang to ban me.
Like there’s no reason my bank, brokerage, and doctor shouldn’t use the same degree of paranoia. But who cares if someone cracks my hackernews password. I haven’t associated my account with any projects or my real identity so the worst you can do is make me look like an idiot or get dang to ban me.
All of the ones in the "wait crap, I'm screwed" kind need to have different passwords.
This person is wildly overthinking their problems.
Early in the piece, they marvel that it's somehow OK to email magic login links to people, but not to SMS logins. Yes: among other reasons, that's because there's nobody an attacker can realistically call on the phone or bribe at a neighborhood cell phone store to rehome an email account. Nobody wants to do away with SMTP more than I do, but everybody has it, and most people (by an overwhelming majority) host it with their absolute most secure provider.
Get past the SMS/SMTP thing. You're doing a low-sensitivity CMS application. It would be bizarre for you to have a Passkeys implementation. It's even weird for you to do login-with-Google or SIWA. Just mail magic links! Be done with it!
TOTP is dead tech. Implement the full gamut of OIDC provider logins --- most of which have better TOTP implementations than you'll come up with (but also tend to steer their users away from TOTP) and forget that it exists.
I'd like to have a coda here about how things get much harder if you're a high-sensitivity application. But they don't. Mostly what happens is that OIDC signon gets much more important.
The bit about TOTP secrets being worse, harder-to-rotate passwords also misses the point of why passwords are bad and why unmasked TOTP seed storage is not in fact that big of a deal, but who cares? Just don't do TOTP.
Early in the piece, they marvel that it's somehow OK to email magic login links to people, but not to SMS logins. Yes: among other reasons, that's because there's nobody an attacker can realistically call on the phone or bribe at a neighborhood cell phone store to rehome an email account. Nobody wants to do away with SMTP more than I do, but everybody has it, and most people (by an overwhelming majority) host it with their absolute most secure provider.
Get past the SMS/SMTP thing. You're doing a low-sensitivity CMS application. It would be bizarre for you to have a Passkeys implementation. It's even weird for you to do login-with-Google or SIWA. Just mail magic links! Be done with it!
TOTP is dead tech. Implement the full gamut of OIDC provider logins --- most of which have better TOTP implementations than you'll come up with (but also tend to steer their users away from TOTP) and forget that it exists.
I'd like to have a coda here about how things get much harder if you're a high-sensitivity application. But they don't. Mostly what happens is that OIDC signon gets much more important.
The bit about TOTP secrets being worse, harder-to-rotate passwords also misses the point of why passwords are bad and why unmasked TOTP seed storage is not in fact that big of a deal, but who cares? Just don't do TOTP.
What's wrong with TOTP? Are you using that term in a technical sense to mean something specific or are you referring to any situation where someone needs to consult an app on a second device to receive a code to present to the first device?
It's clunky and it's not phishing resistant.
The way I think of it is: my browser’s password manager is the phishing-resistant portion of the system, and TOTP ensures that I am the one sitting at my browser.
Passkeys sound interesting, but I have a (perhaps incorrect) user-hostile big-tech lock-in feeling from them. I really could be wrong, but it feels like the intention is for us all to have to use accounts from Google, Microsoft, Facebook or Apple (maybe Mozilla, maybe), using browsers from Google, Microsoft or Apple (maybe Firefox), on OSes from Google, Microsoft or Apple.
Passkeys sound interesting, but I have a (perhaps incorrect) user-hostile big-tech lock-in feeling from them. I really could be wrong, but it feels like the intention is for us all to have to use accounts from Google, Microsoft, Facebook or Apple (maybe Mozilla, maybe), using browsers from Google, Microsoft or Apple (maybe Firefox), on OSes from Google, Microsoft or Apple.
Yes, that might be a strategic thinking of big tech. Still you can use third-party password managers like Bitwarden, KeePassXC or 1Password to take care of your passkeys. I think, for most non-technical users, they will go for the Apple/Google/Microsoft credential manager option but if you're more tech-savyy, there are ways to stay independent of big tech.
Agree. If I show my parents or great-parents TOTP, they're usually lost and hate it. Recently, I've seen a study that anyway +90% of users choose SMS OTP over TOTP.
Not phising resistant compared to what?
Bear in mind the saying: it's impossible to make anything foolproof because fools are so ingenious.
Bear in mind the saying: it's impossible to make anything foolproof because fools are so ingenious.
WebAuthn and related variants
How does a server using WebAuthn know that the client it is talking to is the right one? For example, say my bank wants to use WebAuthn instead of a username and password to let me access my account. How does the bank's server know that the public key I give it (via my browser) corresponds to my account?
Also, what if my device gets stolen? How do I prevent someone else from accessing my account, since the secret needed to do so is on the device, not with me?
Also, what if my device gets stolen? How do I prevent someone else from accessing my account, since the secret needed to do so is on the device, not with me?
1) They link the public key to your user account in their database.
2) Passkeys are 2FA by default. Someone needs to steal your phone where the private key is stored (first factor) and they would need your Face ID / Touch ID / PIN Code (second factor). Just loosing your phone doesn't give someone else the chance to use your passkey for authentication.
2) Passkeys are 2FA by default. Someone needs to steal your phone where the private key is stored (first factor) and they would need your Face ID / Touch ID / PIN Code (second factor). Just loosing your phone doesn't give someone else the chance to use your passkey for authentication.
> they marvel that it's somehow OK to email magic login links to people, but not to SMS logins
The answer here is that, even if you aren't emailing magic links, you're emailing magic links: the "forgot my password" flow is effectively a magic login link, because it uses your email as your single authentication method. There's then no additional loss of security if you use magic links instead of passwords.
The answer here is that, even if you aren't emailing magic links, you're emailing magic links: the "forgot my password" flow is effectively a magic login link, because it uses your email as your single authentication method. There's then no additional loss of security if you use magic links instead of passwords.
> why unmasked TOTP seed storage is not in fact that big of a deal
Wait, why is it not a big deal? Isn’t this similar to storing a plain text password server side? (OK, not user generated). If my server gets hacked, doesn’t the hacker get all the totp’s for everyone, much like getting everyones password?
Wait, why is it not a big deal? Isn’t this similar to storing a plain text password server side? (OK, not user generated). If my server gets hacked, doesn’t the hacker get all the totp’s for everyone, much like getting everyones password?
Because the secrets have no intrinsic value. If you believe your database has been compromised, you just invalidate them all. The problem with password compromise is that passwords are re-used: losing a user password is a big deal. There's a reason there's no "Has My TOTP Seed Been Pwned" site anywhere.
Losing a user password is a “bigger deal” when the password is re-used, I get this point.
> Because the secrets have no intrinsic value
This is too strong. In general, it’s not possible to know my database has not been compromised. TOTP invalidation isn’t a trivial thing either, particularly if it was used instead of passwords and not as a 2nd factor.
> Because the secrets have no intrinsic value
This is too strong. In general, it’s not possible to know my database has not been compromised. TOTP invalidation isn’t a trivial thing either, particularly if it was used instead of passwords and not as a 2nd factor.
I don't agree, but can you point to a system that uses TOTP as a sole factor?
Not really (I can login to some systems with just TOTP, but TOTP was registered as a supplemental to something else). I guess your point is that having the seeds exposed is as big a deal as having salted hashes exposed. Which is to say, not a big deal.
Fair enough.
Fair enough.
Why would it be bizarre to have passkeys?
> It's even weird for you to do login-with-Google or SIWA.
What is "SIWA"?
What is "SIWA"?
"Sign In With Apple"
It could be a good thing to have a confirmed email in the database, in case a 3-letter-agency knocks on your door because of some highly illegal content on your site.
I have to unsubscribe from five things a week that are clearly other people using my email address to sign up for things.
Someone used my email address to sign up for a Mint account. And the only way you can delink Mint is to call Mint or log into someone else’s financial account. I’m no lawyer but that seems like a very, very bad idea to me.
Someone used my email address to sign up for a Mint account. And the only way you can delink Mint is to call Mint or log into someone else’s financial account. I’m no lawyer but that seems like a very, very bad idea to me.
Usually you have to click a unique confirmation link in the email to activate the account.
My inbox says otherwise. Many sites don’t require the activation code to start using the account apparently. Fucking internet, man.
A website that allows login via forgot password -> send email -> reset password should skip passwords entirely and use magic links instead.
Also, at this point there’s a huge number of previously leaked passwords. So websites should simply not allow passwords that have appeared in those leaks.
Also, at this point there’s a huge number of previously leaked passwords. So websites should simply not allow passwords that have appeared in those leaks.
Magic links are annoying for users.
I always forget how stinking nice password manager autofill is until I have to fight with magic links because some service hates me. And most implementations I've seen only log you in from the new link the email sent, not the original page. So if you are trying to log in on a device your email isn't signed in on, you get to type the entire thing in on your second device.
> And most implementations I've seen only log you in from the new link the email sent, not the original page.
Probably because:
- Bad actor A attempts to login - User B sees the email and unthinkingly clicks the magic link - Bad Actor A now has access.
There are probably ways around this (browser session/cookies/IP/etc must match?) but that'd be a common enough scenario...
Common enough that e.g. Microsoft Authenticator switched from sending a notification that you can tap to approve/reject (same as scenario above) to needing to enter a 2-digit code that you also see on the webpage (so without seeing Bad Actor A's page you cannot enter the code and approve their login).
Probably because:
- Bad actor A attempts to login - User B sees the email and unthinkingly clicks the magic link - Bad Actor A now has access.
There are probably ways around this (browser session/cookies/IP/etc must match?) but that'd be a common enough scenario...
Common enough that e.g. Microsoft Authenticator switched from sending a notification that you can tap to approve/reject (same as scenario above) to needing to enter a 2-digit code that you also see on the webpage (so without seeing Bad Actor A's page you cannot enter the code and approve their login).
More times than I would like, I have had to manually type out some ludicrously long secret key/token/url. Could we please standardize on only using long strings that do not require il1o0 in them? I suppose it is a failure of Latin or the default fonts with which I am frequently stuck, but it would save me a minor bit of life aggravation.
I absolutely hate the magic links :S
A whole bunch of AI companies are going that route where you can’t have a password and login via magic links - eg Perplexity
I know that crypto/blockchain is not super popular here, but the experience of logging-in to various dapps is pretty nice.
The ”login” is the dapp showing the user a message to sign to prove they own the key, then you can sign the message, and that’s the whole login.
There’s various ways to implement it, but here’s a quick tutorial for doing login with MetaMask. https://docs.metamask.io/wallet/how-to/sign-data/siwe/
The ”login” is the dapp showing the user a message to sign to prove they own the key, then you can sign the message, and that’s the whole login.
There’s various ways to implement it, but here’s a quick tutorial for doing login with MetaMask. https://docs.metamask.io/wallet/how-to/sign-data/siwe/
There is no less attractive use of blockchain tech than login. The biggest problem with login security isn't attesting to an identity, it's account recovery; blockchains make that incredibly difficult.
Fair enough, I guess for crypto wallets there isn’t any recovery that can be done if you lose the private key. In the end a cryptocurrency wallet is usually just a pub/priv keypair, so purely for login/identity purposes it’s similar to passkeys. And can be backed up easily.
What I wanted to say is that hopping around different ‘dapps’ is quite seamless from a login point of view (and has benefits like ability to pay for goods immediately). Often I don’t even proceed exploring some website if it asks me to create an account since the friction is high.
In any case, this popped into my head as I was exploring openrouter.ai yesterday (routing layer for LLMs, you buy credits and can use many models), and they had a “Login with MetaMask” option, which is rare for non-crypto websites, and it worked quite seamlessly.
What I wanted to say is that hopping around different ‘dapps’ is quite seamless from a login point of view (and has benefits like ability to pay for goods immediately). Often I don’t even proceed exploring some website if it asks me to create an account since the friction is high.
In any case, this popped into my head as I was exploring openrouter.ai yesterday (routing layer for LLMs, you buy credits and can use many models), and they had a “Login with MetaMask” option, which is rare for non-crypto websites, and it worked quite seamlessly.
There's a new trend coming up of "Smart Wallets" which make use of synced passkeys for authentication.
I can share a blog post about this topic that I recently wrote if you're interested in some details (e.g. Coinbase did it this way).
I can share a blog post about this topic that I recently wrote if you're interested in some details (e.g. Coinbase did it this way).
It's easy to make things seamless if you define away the corner cases!
This looks like any other public key crypto authentication (U2F) but more complex and less universally adopted?
How is this better than OIDC?
How is this better than OIDC?
I guess it’s pretty similar, it’s just pub/priv key verification in the end.
Imo the benefit would be that on top of just proving you’re you (logging in), you can perform many other actions.
One example where could be used is micropayments, which is imo unsolved problem on the internet. Sometimes I’m browsing and end up on some newspaper paywall which asks me for credit card and yearly subscriptions. Not doing that. But if I were to click a button and get a message to sign saying “Spend 2 cents to view this article?”, and see the article 2 seconds later, I would go ahead and do it.
One example where could be used is micropayments, which is imo unsolved problem on the internet. Sometimes I’m browsing and end up on some newspaper paywall which asks me for credit card and yearly subscriptions. Not doing that. But if I were to click a button and get a message to sign saying “Spend 2 cents to view this article?”, and see the article 2 seconds later, I would go ahead and do it.
Ah, the crypto industry known for being exceptionally secure in their practices, always vetting their security, and never cutting corners. We should do what they do.
(Don't ask about what happened to the Ronin Network, Poly Network, FTX, Coincheck, etc, etc)
(Don't ask about what happened to the Ronin Network, Poly Network, FTX, Coincheck, etc, etc)
just like we have to separate the art getting the artist, we have to separate cryptocurrency from the cryptography. The underlying primitives are sound. Still not gonna factor 4096-bit keys any time soon, quantum computers won't be able break that for at least another decade.
To provide an example that most people here are probably comfortable with: An SSH key is effectively a really long password with cryptographic properties. It's a single factor, one thing, that you use to complete a challenge for the server. We are fine to use SSH keys as our only authentication factor for servers, with IP whitelisting where security trumps convenience; why should we feel uncomfortable using long passwords as our only authentication factor for websites, with opt-in MFA when security trumps convenience?
Instead, websites enforce terrible 8-20 character passwords with a recipe of strict requirements to help crackers, and a download of the flavor of the month authenticator app that quickly becomes burdensome and annoying.
Why does my library think they're Fort Knox and want me to get an authenticator app? The tech is fine, but its universal forced application bugs me. It's like those campaigning for enforcing MFA everywhere never considered that different users have different risk appetites/tolerances.
The problem with passwords comes when humans mismanage passwords and pick bad ones. Passwords themselves are fine.