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?

  • 1
    If it was possible, then every hacker on the planet would test every app and crack those apps first ...
    – schroeder
    Nov 21, 2016 at 18:55
  • 2
    Just use a password manager and a unique and very strong password per application. Problem solved.
    – marstato
    Nov 21, 2016 at 18:59
  • 4
    Similar question here with some good advice for you in the top answer: security.stackexchange.com/questions/91006/…
    – PwdRsch
    Nov 21, 2016 at 18:59

2 Answers 2


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.


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.

  • 1
    +1 for the idea, even though I don't think this will work as a differentiator in practice. I'd agree that if an answer to a login attempt took considerably longer than all other requests to the application, that was a good sign that something like bcrypt, scrypt or the like was running on the server, but in the absence of much-longer-than average delays when logging in, there'd be no additional information at all. You'd never know if there was a weak hash function in use, no hash function at all or some other reason for small delays (such as a generally slow authentication system) Nov 21, 2016 at 19:53

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