Is there a way to check whether the application saves password in clear text or in hashed format?

Question

I have four kind of passwords and I use them according to the importance of the web application. So if I see an application not using SSL and I have to make an account, I will use a basic password which is used for all the non-sensitive applications.
Now, even if an application uses HTTPS, I am skeptical what if the passwords are stored in plain-text in database and someone can find those in a table. Say, somehow, the database got hacked and the attacker have all the passwords.
As my other three passwords are somehow a little related, I want to make sure that my important passwords are not shared with an application which saves passwords in plain text.

So is there a way to find about the password storing mechanism of an application?

Answer 1

No, there isn't if the application isn't open source.

The only sure way to protect yourself is to use a different password for every website you use. You can use various password managers for that.

If you're interested in finding out whether a site stores plaintext passwords, try calling support and begging them to give you your password, which you've conveniently forgotten. If they give it to you, you know.

Assuming they store hashed passwords, that's still no guarantee that your password is sufficiently protected. An awful lot of sites seem to use unsalted hashes of questionable quality (md5, for example). Unsalted MD5 hashes can be brute forced with good recovery rates for simpler passwords, although long, uncommon/random passwords should still be safe.

Answer 2

You could use a Timing Attack* to determine this information.

You might be able to distinguish a (Slow/Strong) Password Hash from a weak (fast) hash or plain text by measuring the processing time of the login form, (which is likely to be a very lean script) first by submitting no Password, and see how much additional time is needed when the Password is included. The script will require:

1. some minuscule lookup time to find the user and his/her salt
2. some additional time to hash the password for comparison

In my recommendations on password hashing, I suggest that the (Slow/Secure) Password Hash should take about 100ms (with DoS protection) on target platform (knowing that faster hardware would be used for Brute Force), but could be as low as 10ms or 1ms (much harder to measure) and still be considered a reasonably secure. (by other security experts)

In testing there will be several considerations:

• How consistent is response time in each attempt.

• A well-secured application developer will defend against User-Enumeration Timing Attacks by processing the hash with fake salt in the event the Username is incorrect, so observing the difference in processing time would be difficult.

  (I do not expect fake delays when the Username and Password is totally blank, but it could be hard to distinguish the delay difference between #1 and #2 above)

• Many applications take much less than 100ms to hash, for various reasons, and this makes the Timing Test more difficult.

_{* Searching for vulnerabilities in other people's software without permission is illegal in many jurisdictions. Although in reality, I don't think you would be incriminated caught for testing response time of just a few login attempts.}