Why Login Security Sucks

https://matduggan.com/why-login-security-sucks/

by todsacerdoti • 2 years ago

56 77 2 years ago

janalsncm• 2 years ago

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.

graemep• 2 years ago

Magic links are annoying for users.

ibll• 2 years ago

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.

radicality4• 2 years ago

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

radicality4• 2 years ago

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/

tptacek7• 2 years ago

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.

radicality4• 2 years ago

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.

martinky24• 2 years ago

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)

fragmede5• 2 years ago

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.

wepple3• 2 years ago

This looks like any other public key crypto authentication (U2F) but more complex and less universally adopted?

How is this better than OIDC?

radicality4• 2 years ago

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.

tptacek7• 2 years ago

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.

stavros• 2 years ago

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.

kibwen• 2 years ago

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?

tptacek7• 2 years ago

It's clunky and it's not phishing resistant.

lll-o-lll3• 2 years ago

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?

tptacek7• 2 years ago

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.

vdelitz5• 2 years ago

Why would it be bizarre to have passkeys?

will1james• 2 years ago

It's even weird for you to do login-with-Google or SIWA.

What is "SIWA"?

slater• 2 years ago

"Sign In With Apple"

Dwedit• 2 years ago

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.

jonpurdy• 2 years ago

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.

smcnally3• 2 years ago

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.

wepple3• 2 years ago

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.

tomsmeding• 2 years ago

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.

smcnally3• 2 years ago

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.

wepple3• 2 years ago

Sorry, when I said OTP I mean the recovery code OTP. They’re often 16 hex, so 16^16

semiquaver• 2 years ago

Summer2024!

wait, how do you know my pw?

Ferret7446• 2 years ago

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.

bluepuma772• 2 years ago

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.

hinkley5• 2 years ago

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.

bluepuma772• 2 years ago

Usually you have to click a unique confirmation link in the email to activate the account.

motohagiography• 2 years ago

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.

hinkley5• 2 years ago

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.

fragmede5• 2 years ago

All of the ones in the "wait crap, I'm screwed" kind need to have different passwords.

RadiozRadioz2• 2 years ago

Controversial opinion: Username and password is perfectly fine.

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.

jrochkind1• 2 years ago

Ah, so the problem is the HUMANS! This is great, because all we need to do is switch out the humans.

wlesieutre2• 2 years ago

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

lesuorac2• 2 years ago

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

RadiozRadioz2• 2 years ago

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.

bruce3434343• 2 years ago

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).

pieter_mj• 2 years ago

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.

fragmede5• 2 years ago

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.

rlpb• 2 years ago

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.

aseipp• 2 years ago

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.

joshka• 2 years ago

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.

bruce3434343• 2 years ago

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.

Why Login Security Sucks

Related Stories