3

Is there a secure way to know if my password's hash is publicly known on the internet? First I tried to search for it in Hashes.org (http://hashes.org/search.php), but then I suspected, that if it doesn't find my hash, then it will add to the unknown list and it will be cracked. I contacted Hashes.org, and they confirmed that indeed it works as written above. I'm trying to use as secure passwords as possible (and convenient), but if the cracked hash is already out there, then it doesn't really matter. Thanks for your help in advance.

  • How is this well researched? We have salts to stop rainbow tables. If you google "how hashing passwords" work I refuse to believe that there's nothing. – Alec Teal Oct 4 '15 at 22:45
3

If your password is stored properly, it is stored by hashing the password and a salt. Although a cracker who breaches the system on which you have made an account can almost certainly get the salt if he can get the hash, a salt of non-trivial length stops pre-computation attacks and forces the attacker to attack each password separately. A suitably slow hash algorithm makes attacks on a single password difficult, provided the password is strong enough not to be in a dictionary nor vulnerable to heuristic attacks.

So, for a properly stored password, the hash of the password alone is essentially useless to an attacker. (Of course, many sites will not store passwords properly, but there is little you can do about that other than avoid password re-use.)

There is more on salting here: https://crackstation.net/hashing-security.htm

Edit: I've performed the following experiment with hashes.org. I first computed the MD5 hash of "love," a sadly common password. It was found on hashes.org, as expected. I then computed the MD5 of "love" concatenated with "315379008," a 32-bit random number. As expected, it was not found. A real password system would use a much slower hash than MD5 and a salt much longer than 32 bits, e.g. 128 bits, much further reducing the chances that a pre-computed hash would be found, even for a very common password. (Of course, "love" is still a terrible password, even if properly salted, because it will fall to the attacker who has access to the salt. You still need a strong password.)

  • 2
    "Of course, "love" is still a terrible password, even if properly salted, because it will fall to the attacker who has access to the salt." -- It will fall even to an attacker who has neither access to the hash nor the salt, so long as the attacker has some way of verifying whether any specific password is correct, to a dictionary attack in the most literal sense. For instance some remote login API which happens to not impose any limit on the number of failed requests. And that is I believe an even slightly more likely scenario than a database containing password hashes being made public. – hvd Oct 4 '15 at 22:37
  • @hvd the way I see it is that this question is tagged hash and so the attack vector being focused upon here is attacking hashes. The difference is worth mentioning because brute force rates over a network and tiny compared to those on a local machine with the hash. (10^3-4 versus 10^8-12 attempts/sec) I'm not challenging the correctness of your remark, just its relevance. – Scruffy Oct 5 '15 at 0:12

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.