Note: I completely understand the need for strong passwords & I understand that there is an issue of speed with hashing. I am just interested in better understanding the actual negative impact of medium strength passwords (ex: a&3jC36ksL, AweSom3paSswOrd, sImple! pass_pHrase) and poor hashing algorithms (SHA1, MD5) specifically.

For example, let's pretend we have the following application (usability aside for now): It only allows three incorrect password attempts within a 120 minute window, with the account being locked after the fourth attempt. We can also guarantee that users will never reuse passwords (from this application or any other website), and they are always too complex to be guessed with only three attempts.

With these assumptions made, what is the main concern that extra strong passwords and hashing algorithms are addressing?

  1. If an attacker wants to do a brute force attack, don't they need direct access to the data, in which case they already have what they were after?

This post about hashing passwords makes this point:

There are ways attackers can get access to parts of your database without accessing all of it... Coding errors can leak data, as can sql vulnerabilities. An attacker could get a dump of your passwords and nothing else.

Maybe this answers my question, but I am still uncertain of the likelihood of this happening. I also don't know if brute-force is the only concern.

  1. If password hashes are only good for determining passwords for other sites, and the database only contains unique passwords, the hashes should be useless, right?
  • "We can also guarantee that users will never reuse passwords (from this application or any other website)" how? Apr 5, 2016 at 18:13
  • 1
    @NeilMcGuigan Because in the first part of the question begins with "let's pretend...", he's constructing a thought-experiment. That seems like a reasonable thing to put into a thought-experiment. Apr 5, 2016 at 18:15
  • 1
    To put some numbers around @MikeOunsworth's answer, once the hashes are stolen, a high-end hash cracking rig, against some hash functions, is capable of hashing several billion candidate password per second for comparison. Combine that power with dictionaries and pattern masking and you'll see that all but strong passwords will fall very very quickly.
    – Xander
    Apr 5, 2016 at 19:17
  • @Xander good point, I'll add some numbers to be answer. Apr 5, 2016 at 20:10

2 Answers 2


In the case you constructed, even a 4-digit PIN would be fine. In fact, it's very similar to the iOS (and maybe Andriod?) PIN lock screen that wipes your phone after 10 incorrect guesses.

No real hacker will try brute-forcing passwords against an application server, it's just too slow. Over the internet you can get at best what, a couple of hundred guesses per second, assuming the server doesn't lock you out. The real risk is that the hacker has access to your password hash and can go to town with an offline brute-force attack using their fancy GPU hashing rig which can do millions to billions of guesses per second, per GPU [nice article], [raw speedhashing data]. Long passwords mean they have to make more guesses before they get lucky, and slow hash functions means they have to spend more time / power per guess.

Answering your questions:

  1. Just because a hacker got a copy of your password hash does not mean they have any kind of access to any other part of the server. For example, check out haveibeenpwned.com, by clicking through those links, I can download long lists of password hashes for gmail, adobe, Ashley Madison, etc. Having those lists of hashes does not in any way give me access to "the data" on those servers.

  2. I guess so, but the assumptions that A) no two users in the database have the same password, B) no user ever re-uses a password between sites, and C) "password hashes are only good for determining passwords for other sites" are very strong assumptions.

  • No real hacker will try brute-forcing passwords against an application server, it's just too slow - it does happen. Bots will constantly try submitting login forms with known usernames and common passwords to try to get in, usually rotating usernames before passwords as to evade account lockout controls. Apr 7, 2016 at 8:10

Your assumption at 1. is incorrect. Consider an email system, where users log in with a password. In that case, the target may well be either the emails (which might be stored in a database, but equally may be in individual files, or mailbox files), or the ability to use the system. In this case, access to the database wouldn't provide either of those things, but access to the passwords would.

Your point at 2. is also not quite right - they are used for the current site, not for other sites. They are how the system checks that the correct password has been entered.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .