5

I am into bitcoin right now, and the password threats scare me a little...

Not so much for me, because I use LastPass and generate new passwords at 20 characters and it includes symbols, upper and lower case letters as well as numbers. However, I know that we are nearing a time where 100 billion passwords a second can be attempted as a brute force and I was thinking about the amount of people who use Teddy567 or qwertyqwerty for passwords and I think to make the internet safer we should come up with a way to stop brute force attacks.

So, can you help me to understand why sites can't implement a 3 second delay or hell, even a 1 second delay in any missed password. This would, in my mind totally end all brute force attacks. It also would not even be noticeable by humans

Campy
  • 71
  • 2
  • 2
    Why not just lock an account after 3-5 bad attempts, which is what most websites do. – RoraΖ Sep 25 '14 at 15:29
  • 2
    @Campy: There would still be brute force attacks on the password hashes. –  Sep 25 '14 at 15:36
  • 4
    Attacker: I don't like Campy. Let me go and write a script that tries to log in with "Campy / bad-password" every 2 - 3 seconds. Now he can't log in to the site using his legitimate creds. Ha ha! – Levi Sep 25 '14 at 15:37
  • 1
    I don't think this is primarily opinion-based because a good answer would explain why this would not be necessary. – SilverlightFox Sep 26 '14 at 09:05

3 Answers3

5

Generally locking accounts as proposed by raz is a very bad thing - it leads to helpdesk load, annoyed customers, and is not needed to actually prevent brute force attacks.

Temporary suspensions are used by more and more systems, often some delay that foils brute force, like 5 or 30 minutes, or by using an escalating scale, eg doubling the timeout each failed login attempt.

Rory Alsop
  • 61,474
  • 12
  • 117
  • 321
  • I'm a big fan of the exponentially increasing delay. (0s, 1s, 2s, 4s, 8s, etc). If you display a timer, the user knows the cost of 'trying again', allows them time to really think about the password they are using, and works as a de facto lockout without incurring the help desk costs (people tend to wait it out). It all depends on the application and business decisions, but it works nicely. – schroeder Sep 25 '14 at 16:33
4

Brute-forcing is normally used in the context of an offline-attack, where the attacker already knows the password-hashes and can use the full power of his system (GPU) to find a matching passwords.

You are talking about online-attacks, an increasing delay would indeed make brute-forcing unpracticable, though it is not so easy to implement as it may sound. An attacker could then e.g. block a user from a successful login. Brute-forcing an online system does not allow for enough attempts anyway.

martinstoeckli
  • 5,189
  • 2
  • 27
  • 32
  • Thanks so much. I wasn't thinking. So, attacker would somehow get my bitcoin wallet hashh, and then use his system to attack the hash until it was broken – Campy Sep 25 '14 at 15:46
1

Online bruteforce attacks

Indeed, sites that don't implement some form of protection against online bruteforce attacks are leaking their users' passwords. Many sites don't have any form of protection in place, and many others do.

Simple blocking has issues:

  • If we block the user's IP after x failed tries, a 10'000 strong botnet gets to try x* 10'000 passwords. At 100'000 tries a lot of the weaker passwords are already cracked.
  • If we block the user's account after x failed tries, any attacker can block any user's account.

This implies that the defense needs to be more sophisticated, or we can simply ignore defense and try to blame the user when it eventually blows up, which is less than ethical. More sophisticated schemes use some combination of detection of suspicious activities, and conditionally stronger login requirements.

To detect suspicious activities we track positive signs based on successful past successful logins, such as the ISPs of the user and some identifier of the devices that the user logged in with before. We can also use negative signs such as IPs from "tainted" ISPs or countries, or a rapid increase in login attempts.

In terms of stronger login requirements we can use short timeouts, captchas, multi-factor authentication, and even blacklists.

Offline bruteforce attacks

All the above measures are useless once our disgruntled system administrator sells a copy of our password database on the black market, because then the attacker can just hash the password himself and see if it matches the database. Cracking the the hashes can be cheap and easy or still easy but very very expensive, depending on how we hashed the passwords See: How to securely hash passwords?

Salt: To make it harder on the attacker to crack the whole database, we use a salt, which makes each hash slightly unique. Every user has a different salt, which is stored next to the hash. This means the attacker can't just calculate the hash of one password and compare it against every user's hash, but instead the attacker has to calculate a new hash for every password he tries against every user. Using a salt does not increase the cost to get the password of a single user.

Expensive Hash: No attacker can bruteforce 100 billion passwords a second, unless the hashing scheme was set up by a moron (which is plausible). Some attackers can calculate 100 billion basic hashes like sha256 per second, but the solution is simply to not use a basic hash to hash the password. A trivial solution is that our hash isn't actually hash =sha256(password, salt), instead it's hash =sha256(sha256(sha256(.......(password, salt)...)password, salt)password, salt), where we use around 100'000 iterations of sha256, making any attack 100'000 times more expensive. In reality this defense is too simple to break with specialized hardware, so in practice we use special Key Derivation Functions tike bcrypt and scrypt to mix multiple basic hashes in ways that are expensive for any attacker to calculate, regardless of hardware.

Community
  • 1
Peter
  • 3,620
  • 3
  • 14
  • 24