Hacker News Reader

Comment by est | Hacker News Reader

offtopic, is it secure to design a login that only requires username+TOTP?

This elimilates passwords altogether, but are there any pitfalls?

Not TOTP but a bunch of sites are doing this thing where they send an OTP to the registered email and have eliminated passwords altogether. I find it really annoying.

It is annoying but it generates far fewer support requests for people who can't remember a password and think resetting it is too difficult.

With a long enough session life and a good refresh strategy, it's less of a problem. If an app clears sessions after a week, then I would argue they are doing it wrong.

I think they also want to thwart folks like me who are possibly going to use a temporary email site to make an account.

Depending upon one's threat model, I found that the "public" version of throwaway emails still work great for that purpose, versus sites like 10minutemail which destroy the address after a time. Sure, I am cognizant that if I just went surfing around (e.g.) https://www.mailinator.com/v4/public/inboxes.jsp?to=ksynwa long enough I could probably snag any hypothetical login link to HipsterLoginLink.co but in practice I doubt it's an issue

That's how I use random sites for which I can't/won't use my main browser - just set a random password and don't save it anywhere, then rely on email password resets to login.

It blows my mind that a 6 digit code is considered a secure replacement for a password on these sites. Only a 1 in 1 million chance of brute forcing. Seems rather simple for a motivated actor with a botnet targeting a large list of accounts to have some degree of success.

Any competent IPS system would lock out a botnet, and it rotates, so you need to guess the right 6 digits within 90 seconds 30 plus 30 on both sides) until it's a different set of 6 digits.

You'll see this in CTFs sometimes. Each guess gives the attacker a one in a million chance of guessing the TOTP. If the attacker can figure out a username (usually easy) and the log in API isn't rate limited, then they can just guess codes in a loop. It take about 12 days to make one million guesses at one request per second. Most TOTP apps allow codes that are older/newer, and the attacker may be able to use a higher RPS. I guessed a TOTP in 30 minutes for one CTF, for example.

So pretty insecure, but probably suitable for some systems with low security requirements or other mitigating factors.

> offtopic, is it secure to design a login that only requires username+TOTP?

This elimilates passwords alltogether, but are there any pitfalls?

Coincidentally, I just mentioned that I did this: https://news.ycombinator.com/item?id=40878150

(of course, I leave it as a user preference: The user chooses whether to use standard passwords or to use one-time-passwords)

Totally not my field of expertise, but maybe some like “an attacker knows all usernames, and can therefore try an attack where they attempt to log into all of the accounts in parallel with the TOTP ‘000000’” yields a high enough chance of hitting one or more accounts that happen to have this TOTP at this very moment?

it's about same chance of trying to login all usernames with password 123456 no?

An easy counter-measure would be blocking consecutive TOTP logins of the same or similar codes.

It doesn't really matter if the codes are the same.

The attacker has a 1 in 1 million chance of guessing right, assuming 6-digit codes. This isn't acceptable for most applications.

> a 1 in 1 million chance of guessing right

That's assuming there's no throttle of login requests and all authentication were made under one minute against one single user.

Yes, could easily be limited to 3 attempts per 30 seconds, so people could fix typos.

No, it is assuming neither of those things. Each independent attempt pretty obviously has those odds, no matter how many accounts and how much time they're spread over. Your suggested countermeasure does not do anything to change those odds.

I think you're misreading "1 in 1 million" as "1 million in 1 million".

> Your suggested countermeasure does not do anything to change those odds.

Actually it does change. Even if you hit the exact correct TOTP code, the system still deny your login because of throttle rules and you can't tell on the client side.

But that's not what you suggested first, and what dmurray objected to:

> An easy counter-measure would be blocking consecutive TOTP logins of the same or similar codes.

Which was in response to this attack:

> therefore try an attack where they attempt to log into all of the accounts in parallel with the TOTP ‘000000’

That class of attack is a legitimate threat. Your proposed mitigation (quoted above, not some other mitigation) cannot work. That's because the attacker does not actually need to try consecutive or similar codes, it'll work exaclty as well with random codes.

That you later changed to talking about a totally different attack (of trying a lot of codes on a single account) and a different mitigation (rate limiting of attempts on a single account) is irrelevant to that discussion.

there's a difference between:

1. hack into any account then call it a win

2. hack into a specific target account for a win

idk man. Maybe for some systems #1 is important.

The goal is to replace passwords. So TOTP is is about as secure as, if not better than logins that requires 6 digit PIN, no?

I agree there is a difference between the two. The discussion was about #1, you got called out on your incorrect statements about it, and rather than admit the mistake you're pretending you were talking about #2 all along.

1 absolutely is important for real systems. Think of the account system for Google, Facebook, Steam, etc. Those accounts will have real value to an attacker even if you're only getting a random account.

And no, TOTP is not as secure as a password specifically for a single-factor use case. It's brute-forceable in a way that passwords aren't, in a way that can't be fixed without a lot of collateral damage, and in a way that a high risk user can't even protect themselves against with better password hygiene[0]. A 6-digit TOTP is a decent second factor, but a horrible single factor.

[0] The attack you described of trying out the password 123456 on all users is called password spraying. (Obviously you'd just not use that, but the top 100 to top 1000 passwords). But that's an attack that single users can guard against, and that systems can mitigate with basically no collateral damage. The mitigations for a TOTP-spraying attack would need to be quite draconian.

> your incorrect statements about it, and rather than admit the mistake

Hey man you don't have to be so aggressive. I was asking a question "is it secure?" or "are there any pitfalls?"

If it's not secure then naturally I am curious what can be done about it. I don't need to defend to prove anything.

I am happy to learn that such design is inefficient against #1 scenario, especially if such "account system for Google, Facebook, Steam, etc. Those accounts will have real value" were at stake.

In similar systems I built, 123456 is never a system selected OTP. It gets guessed too often, if it was generated, we would never know if the user got the code or just guessed.

Why is that better than trying many TOTP codes against one user?

Because you can have a rate limit on attempts against one user. You can't have an effective rate limit on attempts against all users in aggregate. Or rather, you could have one, but the consequence is that a brute-force attack would cause all legitimate users to also be blocked by the rate limit.

Obviously you just rate-limit per client IP.

A rate limit strategy should limit the rate of the attacker not the victim.

Rate-limiting per email address is just a DoS vector, anyone can prevent a legitimate user from logging in.

"Secure" is relative.

I have a system I use where you enter your email and get a one-time code.

The goal in that system is not to securely authenticate you, merely to identify you. "Good enough" for the use case.

In this case you might as well send a very long token, since it's going to be copy/pasted. TOTP codes are rather short. Or better yet, send a link to login: this can be made to work cross-device (copy/paste usually doesn't).

The pitfall is when the TOTP app is on the same device as the browser you want to login with.

But that's a general problem. 2FA should really mean 2 separate devices.

Reply on news.ycombinator.com