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:
- some minuscule lookup time to find the user and his/her salt
- 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.