Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

6 digit OTP for Two Factor Auth (2FA) is brute-forceable in 3 days

lukeplant.me.uk

Post reply on HN
Print view View original

21–30 of 42 posts

Re: 6 digit OTP for Two Factor Auth (2FA) is brute-forceable in 3 days

#21

Post by 3np »

gruez wrote: post #9

>An alternative is account locking after a number of failures, which is much better. However it also brings problems. It means that your 2FA must only be accessible for people who already have passed one level of security, otherwise you have a denial of service vulnerability. Isn't that how most 2fa flows work? You enter username + password, if it gets accepted you move onto a second page where you enter your 2fa cod…

One problem with the two-step approach of only prompting for 2FA after successful auth is it leaks a lot of information - an attacker can confirm that they got the right password, or even just that the account exists and has 2FA enabled.

For TOTP-based 2FA, it would ideally prompt for all three (username/password/TOTP code) immediately, not indicating which part of auth failed.

This may not always be desired, for example when TOTP is just one among several 2FA options.

In those cases, at the very least always prompt for 2FA for accounts that require it, regardless of if password auth succeeded or not. Don’t tell the user if it was the password or TOTP code that failed.

Re: 6 digit OTP for Two Factor Auth (2FA) is brute-forceable in 3 days

#22

Post by throw0101a »

ClumsyPilot wrote: post #4

Its a shame the TOTP standard does nor support variable code length, 8 symbols seems to be better for high value accounts but still usable

> Its a shame the TOTP standard does nor support variable code length, 8 symbols seems to be better for high value accounts but still usable

It does. TOTP (RFC 6238) builds off of HOTP (RFC 4226), which states (§5.3):

> Implementations MUST extract a 6-digit code at a minimum and possibly 7 and 8-digit code. Depending on security requirements, Digit = 7 or more SHOULD be considered in order to extract a longer HOTP value.

* https://datatracker.ietf.org/doc/html/rfc4226#section-5.3

There is no inherent limitation in the protocol on how many digits to use (AFAICT): the pseudo-code examples have the number of digitals desired as a parameter in each function.

Further, HOTP even discusses (§E.2) is to use (six+) alphanumeric characters ([A-Za-z0-9]) instead of just digits ([0-9]), though digits are "desirable" for easier entry.

Re: 6 digit OTP for Two Factor Auth (2FA) is brute-forceable in 3 days

#23

Post by briHass »

The thing I don't understand is why some OTP systems have started issuing 7-digit codes via text/email (e.g. Sendgrid). I have to imagine Sendgird is competent enough to lockout the account after a few failed OTPs and/or limit the duration a code is valid, so I don't understand the need for the extra digit. It makes mental chunking harder, and is nothing but security theater if the above two checks are in place.

Re: 6 digit OTP for Two Factor Auth (2FA) is brute-forceable in 3 days

#24

Post by ocdtrekkie »

throw0101a wrote: post #22
ClumsyPilot wrote: post #4

Its a shame the TOTP standard does nor support variable code length, 8 symbols seems to be better for high value accounts but still usable

> Its a shame the TOTP standard does nor support variable code length, 8 symbols seems to be better for high value accounts but still usable It does. TOTP (RFC 6238) builds off of HOTP (RFC 4226), which states (§5.3): > Implementations MUST extract a 6-digit code at a minimum and possibly 7 and 8-digit code. Depending on security requirements, Digit = 7 or more SHOULD be considered in order to extract a longer HOTP v…

True, but the problem is I do not believe any apps implementing TOTP allow for codes over six numerical digits. So the real world standard (Google Authenticator) does not support it.

Re: 6 digit OTP for Two Factor Auth (2FA) is brute-forceable in 3 days

#25

Post by rpadovani »

> Say you are thinking of a number between 1 and 10,000 and give me one thousand attempts to guess it. To make it harder, you change the number every 100 guesses. To make it harder still, you are thinking of changing it every 50 guesses. Would that work? Well, in the first case I get 100 guesses at 10 different numbers, in the second I get 50 guesses at 200 different numbers, but that makes no difference — I get the same number of guesses, and I only have to guess correctly once to succeed. Mathematically, it boils down to the fact that (xa)b=xab.

That's blatantly false, of course it makes a difference, because it makes the events stochastically independent.

If I choose a number between 1 and 10, and I give you 10 chances to guess it, you have 100% chances to guess it. If on the other hand I change it at every guess, you have only ~65% of chances to guess it.

Edit: fixed the % of chances, it is a binomial distribution, and I totally miscalculated it

Re: 6 digit OTP for Two Factor Auth (2FA) is brute-forceable in 3 days

#26

Post by Spooky23 »

ClumsyPilot wrote: post #4

Its a shame the TOTP standard does nor support variable code length, 8 symbols seems to be better for high value accounts but still usable

I wish TOTP supported a PIN. That omission makes it pretty useless for high security applications.

Re: 6 digit OTP for Two Factor Auth (2FA) is brute-forceable in 3 days

#27

Post by rpadovani »

3np wrote: post #21
gruez wrote: post #9

>An alternative is account locking after a number of failures, which is much better. However it also brings problems. It means that your 2FA must only be accessible for people who already have passed one level of security, otherwise you have a denial of service vulnerability. Isn't that how most 2fa flows work? You enter username + password, if it gets accepted you move onto a second page where you enter your 2fa cod…

One problem with the two-step approach of only prompting for 2FA after successful auth is it leaks a lot of information - an attacker can confirm that they got the right password, or even just that the account exists and has 2FA enabled. For TOTP-based 2FA, it would ideally prompt for all three (username/password/TOTP code) immediately, not indicating which part of auth failed. This may not always be desired, for exa…

> In those cases, at the very least always prompt for 2FA for accounts that require it, regardless of if password auth succeeded or not. Don’t tell the user if it was the password or TOTP code that failed.

This still leaks that the account exists and has TOTP enabled tho.

You have to choose if leaking the correctness of the password, or allowing DoS of a login, unless all the accounts have the same MFA.

Re: 6 digit OTP for Two Factor Auth (2FA) is brute-forceable in 3 days

#28

Post by withinboredom »

I think what’s important here is when there can’t or won’t be a “lock out” after a certain number of tries. I’ve seen a few door locks based on TOTPish. They won’t lock you out because who knows why. You can just stick a device outside the door, slamming the BLE endpoint with codes until it unlocks, sorta like a proxmark used to do for keyless entries (maybe still does, haven’t messed with them since ‘08ish)

Re: 6 digit OTP for Two Factor Auth (2FA) is brute-forceable in 3 days

#29

Post by duskwuff »

dzhiurgis wrote: post #20
duskwuff wrote: post #14

Earlier quoted context omitted.

Doesn't matter. If you keep trying enough random codes for long enough, eventually you'll guess right.

Does it assume that each code is new and not repeated? Because they can def be duplicates.

Still doesn't matter. If you're guessing at random, you have a roughly one in a million chance of getting it right each time.

(Actually, the odds are a little better than that, because most TOTP implementations mitigate clock skew by allowing clients to enter codes from a "window" of a few minutes surrounding the current time.)

Re: 6 digit OTP for Two Factor Auth (2FA) is brute-forceable in 3 days

#30

Post by duskwuff »

Spooky23 wrote: post #26
ClumsyPilot wrote: post #4

Its a shame the TOTP standard does nor support variable code length, 8 symbols seems to be better for high value accounts but still usable

I wish TOTP supported a PIN. That omission makes it pretty useless for high security applications.

What do you mean by that? The TOTP standard doesn't specify how (if at all) the client is secured. Besides, the one-time code is used in addition to a password, not as a substitute for one.
Post reply on HN