Why Login Security Sucks
matduggan.com
matduggan.com
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.
You know how much more convenient it is to just open a browser and go to a webpage and already be logged in?
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
OCSP existed back then which helped but I don’t know if stapling had been widely implemented yet.
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.
More of a problem is password reuse for multiple sites, which is impossible when using 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.
"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.
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.
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.
wait, how do you know my pw?
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.
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.
[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.
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 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.
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.
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.
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.
Bear in mind the saying: it's impossible to make anything foolproof because fools are so ingenious.
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?
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.
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.
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
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.
Fair enough.
What is "SIWA"?
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.
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.
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).
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/
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.
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).
(Don't ask about what happened to the Ronin Network, Poly Network, FTX, Coincheck, etc, etc)
How is this better than OIDC?
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.