Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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.
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
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.
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.
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.
