7

Say you are using a website and incorrectly enter your password. The website then "instantly" pops ups with an "incorrect username/password" message.

Would it be safe to infer that the website is not hashing passwords?

As I understand it, cryptographic hashes are generally designed to take a certain minimum amount of time in order to deter brute force attacks.

  • 1
    What do you mean by "website pops up"? Does it proceed to a different page? – techraf Apr 25 '16 at 2:13
  • @techraf nope. It isn't a true pop up. The message just appears the log-in boxes. – Liam Apr 25 '16 at 2:14
  • appears above the log-in boxes*. Also, it does take several seconds to proceed when the correct password is entered. – Liam Apr 25 '16 at 2:48
  • 1
    How long do you think it takes to hash a string? – schroeder Apr 25 '16 at 4:08
  • 1
    The time it takes for your browser to send your user/pass over the internet to the web server and receive back the response is far greater than the time it takes the server to check your password. There is no way you could possibly know what the server is doing (hash or not) based on the time it takes to receive the response. There is far too much noise in the total time. – TTT Apr 25 '16 at 17:53
23

You can't make that assumption. Hashing occurs extremely fast, even a password that's salted, and uses a secure "slow" algorithm (or even chained set of algorithms) is going to return very fast (for humans). A ballpark estimate for using PBKDF2 with 10,000 iterations for each logon attempt could handle 100,000 attempts in a second (when only looking at hashing time). What seems like "instant" to you is actually quite a long time to the system.

Also remember the page may not have to reload any content, it could have the dialog already rendered just not displayed. Or the page could use a persistent connection rather than creating a new connection when sending the credentials. Both speeding up the responsetime.

That's not to say the error for an incorrect username/password can't reveal information. Some sites will return their error message faster if the username is invalid (and thus didn't bother checking the password). This can lead to an attacker enumerating account usernames.

Hashing estimates : https://stackoverflow.com/questions/11298184/about-how-fast-can-you-brute-force-pbkdf2

  • 9
    There could also be client-side checks on the password's validity, since many sites have requirements (e.g. length, uppercase/lowercase/numbers). – grc Apr 25 '16 at 7:56
  • 1
    If it takes less than 10ms to confirm a password, your work factor is too low. – CodesInChaos Apr 25 '16 at 12:12
  • 1
    If you're calculating the hash in 10µs, you're doing it wrong. A proper calculation time would be something like 100ms — on the threshold of non-instant for human perception. I don't know where you got your numbers, they're several orders of magnitude off from the SO answers you cite. – Gilles Apr 25 '16 at 12:13
  • 1) 10k iterations is very low for PBKDF-HMAC-SHA-1/2. 2) My calculation suggests about 600-800 computations of PBKDF-HMAC-SHA-1 on a fast single core CPU. 3) You can use parallelism to increase throughput but not latency, for typical password hashes. – CodesInChaos Apr 25 '16 at 12:30
2

Your assumption is wrong. Cryptographic hashes are not generally designed to be slow. Quite the contrary, the most widely used hashes such as MD5 and the SHA series of cryptographic hash function were developed explicitly with speed in mind. They need to be, because they may be used to hash huge files or provide integrity check for internal file system data structures and should not slow down read/write access. The biggest requirement to a cryptographic hash function is that it is impossible to quickly generate a input file that matches a given hash, not that it be slow.

That being said, there is a subset of cryptographic hash functions developed explicitly for use as password hashes. And these are indeed developed to be (configurably) slow to deter brute force attacks. Two examples are PBKDF2 and bcrypt. But that does not mean that password stores only use these types of cryptographic hash functions.

So you cannot deduce the presence of password hashing from quick denial.

1

I suppose it depends on the circumstances.

If you're running a Windows 95 machine on a dial-up connection to a webservice running on an overloaded Unix box from 1990, then yes I imagine it would take a second or two to return back a result.

However, we are in 2016, where CPUs run in the GHz range, and internet speeds run into the MB/s. Hashing to a computer today is a trivial feat, which would take a fraction of a second. To the human, it's practically instant.

If we utilise AJAX, and pre-render said "pop-up", we'll see a result instantly in a best-case scenario. Try it on Facebook, or Google. You'll see a result straightaway. Try it again on a Raspberry Pi. You'll see the same thing.

  • I think this question is more to do with the assumed speed of hashing algorithms used on the server than (client-side) hardware or connection bottlenecks. (the assumption being 'password check = quick, hashing algorithms = slow, so if the password validation is quick there must not be a hashing algorithm involved') – Fluffy Apr 25 '16 at 12:28
  • Even a 90s Unix machine could compute a modern cryptographic hash in a fraction of a second. Even an 8 bit 8051 processor can do it (almost) instantly. It's not like it has to hash many megabytes of data. – forest Feb 24 '18 at 7:14
-16

No, because your hashed password is just plain text anyways. The hashing takes place when you create the account, not each time you log in. If someone is using the same password as you then they will have the same hashed password as well, which is why many sites require complex passwords.

Those plain text passwords will take about as long to retrieve as it does to create them, even if you are using a slower method, the password will still be created instantly.

How can passwords created so fast be secure? Because it's one way encryption; which drastically reduces the work a server needs to do.

  • 32
    Is there at least one true sentence in this answer? – techraf Apr 25 '16 at 9:28
  • 4
    Each time you log in, the server will run the same hashing function over your passwords and it will compare the result of that hash with the hash stored in the database. As the hash of an incorrect passwords is different of that of a correct passwords, the application knows when you entered a wrong password. 2 hashes of an identical password are the same in a normal hashing operation, but the industries best practices dictate that you should use a unique "salt" for every user, which will affect the resulting hash in such a way that identical passwords will have different hashes. – BlueCacti Apr 25 '16 at 12:23
  • 3
    The reason an application wants you to use a strong password, is because they are harder to bruteforce or guess. Attackers often use dictionaries of passwords that are known to be quite common and/or they have discovered on other websites (e.g. 123456 or password). Hashing is indeed a one-way function (not encryption), which means that the result of a hash cannot be used to get back to the original password. – BlueCacti Apr 25 '16 at 12:26
  • 3
    Doug, how does the server know that a submitted password is the same as the hashed password in the db? Do you believe that no 2 accounts can have the same password? Your statements about "creating" passwords make no sense. I am having trouble coming up with a clarifying question about them. Can you express those statements in a new way? – schroeder Apr 25 '16 at 15:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.