Hacker News Reader

Comment by vibrunazo | Hacker News Reader

Complete security newbie here. Doesn't it make brute force attacks almost worthless when you just have a minimum time between each login request after too many attempts per IP ? So you can only try to login every 30sec after you've failed 10 times in a row? I thought brute-forcing logins were a thing of the past after people started implementing this min time between requests strategy.

The only weakness I can imagine would be a massive botnet forcing logins, but even then it would be severely limited. Am I missing something silly?

View on HN

Correct, the heavy lifting for basic security is not done with a pw that has 50 bits of entropy and drives off your casual playerbase, it's done on blizzard's backend with lockouts after a few failed attempts.

>Am I missing something silly?

Yes. It's not that the bad guys try bruteforce to login multiple times and wait to be banned. They could (will/might) steal db with hashed passwords, do their decrypting at home and then login with what they got. The stronger the password (or better, ie slower to calculate hash used) the more time they need for that thus giving more time for Blizzard to realize passwords were compromised and block all accounts/force global password change. Really clever bad guys can do their homework before they have a chance to put their hands on hashed passwords by preparing hashes for say all passwords which are simple combination of words [1]. Now, once password db is compromised they just look for matching hashes and have instant access to some accounts. This is why you are told to use "strong" passwords, if they just try to "bruteforce log-in" that really wouldn't matter much.

[1] http://en.wikipedia.org/wiki/Rainbow_table

This assumes they aren't salting the hashes. But Blizzard apparently[1] uses SRP 6+ which does salt the hashes meaning if you and me have the same password we will still have unique hashes.

[1] http://www.reddit.com/r/netsec/comments/u2168/blizzard_inten...

Just so you know, every variant of SRP is randomized, not just SRP6, and every variant of SRP has parameters that can to some extent be tweaked to provide variable work factors.

That's cool, I had never heard of this.

How is the salt stored to make sure attackers won't just steal your salt anyway? Wikipedia says "the salt is stored along with the output of the one-way function" [1]. Does it means the server needs to store the salt for each user so it can authenticate the password?

[1] http://en.wikipedia.org/wiki/Salt_(cryptography)

Every randomized password hash does exactly this; the randomizing nonce is tiny compared to the hash itself.

As the defender, you don't care if the salt is obtained by the attacker. The salt is not a secret. It's only use is to ensure that each password is hashed as unique, even if the users chose the same password. Basically, it is for defeating precomputed databases (rainbow tables), nothing more.

You store a salt per user. Salts protect against rainbow table attacks. The salt doesn't have to be private for it to be effective at that task.

Besides the salt point others have made, I've also read (on HN) that rainbow tables aren't much use anymore because the speed/storage equation has changed. If your hashing mechanism is dumb enough not to use salts, it is also fast enough to calculate that there's no point doing it in advance.

Reply on news.ycombinator.com