This implementation is __INSECURE__. about blog2019 HOT 9 CLOSED

@rzwitserloot

I just keep guessing codes. Hey, any given time, 5 TOTP codes are valid, and there are only a million codes, so, any time I guess, I have a 1 in 200,000 shot of getting lucky. Assuming I can make a request every 100msec (and that's being 'generous'; usually I can go much faster; TOTP checking is not intentionally speed limited the way things like bcrypt are), I can fire off about 200k requests, giving me very reasonable odds I hit the jackpot in one of those, in less than 6 hours.

Can we actually do the math around this. You can make 300 guesses in 30s at a rate of 1/100ms. If 5 codes are valid at any given time then the probabilities are: 5 * 300 / 1000000 = 0.0015 or 0.15% for a given 30s window.

But we can't just add the probabilities together. From https://en.wikipedia.org/wiki/Bernoulli_trial it seems the formula to calculate this would be

So the chance of success after 720 attempts would be (following the logic here, calculate the chance of exactly 0 successes in n trials):
1 - (1- 0.0015)^720 = 0.66 or 66%

Did I work this out correctly? Would a solution be to simply only allow one TOTP code check every second?

from blog2019.

from blog2019.

Thanks for the feedback. I like this idea. How would you implement that in the GUI?

What do you think about adding an account lock feature that locks the account after x number of invalid login tries (wrong password, wrong totp)?

from blog2019.

You cannot 'unify' the notion of a failed login. Context is important:

• Your average decent password has ~40 bits of entropy. TOTP has 17.5. Stopping attempts at guessing is useful for password prompts. It is absolutely crucial to TOTP prompts.
• How do you lock down a guesser? With TOTP it is easy: Just lock down the account they are guessing for. However, with passwords it is not easy: If you do that, I can just go to facebook or whatever, log in as 'ralscha', enter a random string for a password, do that a few times, and now YOU are locked out. A trivial denial-of-service attack. On the other hand, with TOTP, the story becomes: I enter 'ralscha', I KNOW YOUR PASSWORD, APPARENTLY, and then I stumble at the TOTP roadblock. NOW locking down your account is entirely justified and the right avenue to stop guessing.

So, no unifying them.

You implement this in the GUI by switching it up once you get into 'extra security required' mode: [1] letting the entire screen be dedicated to it. If your authentication space is in a little box, you MUST break out of it. Looking different is GOOD here. [2] make it look different, the point is to make sure the user realizes this is not the normal flow anymore, [3] have 3 independent TOTP boxes for them to put a code into, clearly labelled, and [4] be a lot more forthcoming with feedback. If my phone is 24 minutes off the clock, and I enter my 3 codes, then the error I get should include the text 'your TOTP device's internal clock is 24 minutes ahead of the server's clock; TOTP requires that these 2 devices are within 2 minutes of each other. Please adjust your device's clock'.

from blog2019.

Thanks. This sounds very interesting. When I have some time I will try and implement this.

What would you recommend for applications that only have username and passwords or where TOTP is optional like in this example.
What would you implement to prevent or to make it more difficult to brute force passwords?

from blog2019.

I wrote a new implementation based on your description:
https://github.com/ralscha/springsecuritytotp

It's online here: https://demo.rasc.ch/totp/

from blog2019.

Great, you used math to prove that where I oversimplified to '100%' chance
it is actually 66%. This obviously does not matter one iota; do you really
think a user will be satisfied? They tell you: "Wow, whoa, this security
issue that showed up on bugtraq says that my TOTP is completely useless and
all an attacker needs is my password to log in as me??" – and you answer
with: Don't worry about it, that's only 66% of the time; the remaining 33%,
well, let's assume they don't have more than 6 hours to try and it's
fiiine'??

I'm flabbergasted you'd even bothered to do this math. __ IT IS INSECURE __
how hard is this to follow?

Jesus fucking christ dude, why are you getting so mad that someone questioned you? Security is all about examining risks which means that probabilities are heavily involved. If you aren't going to do the math correctly why bother?

Where did I ever say that 66% is acceptable?

from blog2019.

from blog2019.

Again you are putting words in my mouth. I do not have a current implementation and I am not defending anything. I am simply evaluating 2FA solutions and read this:

And yet 6 hours later, I'm in their account. For sure. Guaranteed. If it's a nice server or it's hosting in a virtual park where I can trivially colocate right next to it in the network, maybe as little as half an hour.

Which did not seem right to me. Turns out it is categorically wrong.

You have also made several other unsubstantiated claims such as:

Hey, any given time, 5 TOTP codes are valid

the industry standard solution to this flaw

Not saying these are wrong, but given your attitude displayed in this thread please excuse me if I don't take your word for gospel.

from blog2019.