Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What are some published industry standards about why revealing the password hash and salt are poor or bad practices from a security perspective?

I am dealing with a vulnerability where anyone can anonymously obtain the password hash and salt remotely. The fix is to use a secure and long password (12+ characters). The hashing algorithm is HMAC-SHA1.

I need solid references for why disclosure of the password hash and salt is a poor practice even with a long password.

share|improve this question
I'm not sure that there will be published standards about WHY non-disclosure is a good thing. It would be like having a regulation specifying why it is not good to hit your fingers with a hammer. The fact is that with the hash and salt, a brute-force attempt can be made. – schroeder Aug 12 '13 at 18:09
up vote 0 down vote accepted

What is bad in revealing the password hash-and-salt is that it allows offline dictionary attacks: since the password hash and the salt are sufficient to verify a potential password, then, by definition, they allow an attacker to try passwords on his own machines, limited only by the number of PC (or other hardware) he can muster. This contrasts with online dictionary attacks, where each try must go through your server, and your server will not accept to try billions of passwords per second.

Password hashing is a second line of defence. You don't want attackers to obtain enough information to run offline dictionary attacks; but when they do, you at least prefer it if they have to pay the full price of the attack, i.e. you show them only password hashes, not the passwords themselves. Plus, you want a slow hash function (with millions of iterations), and the salt to prevent parallel attacks and other similar optimizations (like precomputed tables).

All of this is about protection of passwords, as in "secret data that human users remember". Human brains being what they are, passwords tend to be vulnerable to dictionary attacks. However, if you can convince your human users to remember sequences of 20 random letters (not sequences that they choose themselves, but randomly generated letters), then you can show the hash values, because sufficiently random passwords are out of reach of dictionary attacks anyway -- arguably, these are no longer passwords but keys. Note that this is not a matter of length but of randomness: a password is not strong because it is long, but because it was produced with enough randomness in it; you just need length to make room for randomness.

If you need a reference to smite unbelievers, then invoke NIST Special Publication SP 800-118 (still in draft form, but published nonetheless), which notably includes this quote (from the "executive summary"):

Password cracking attacks can be mitigated by using strong passwords, choosing strong cryptographic algorithms and implementations for password hashing, and protecting the confidentiality of password hashes.

(Emphasis is mine.)

Password hashing is a difficult art. You say that you use "HMAC/SHA-1", but HMAC is not a hash function; it is a MAC algorithm. MAC algorithms use a key. What you probably mean is that you use a password hashing function which has been designed over one or several invocations of HMAC/SHA-1 as a building block. PBKDF2 is such a password hashing function. It includes an extra parameter which is the number of iterations and that's an important one.

See this answer for a detailed discussion on password hashing, its theory and its practice.

share|improve this answer
Thanks for the reference. – Rodney Beede Aug 12 '13 at 19:54

First, HMAC-SHA1 is not a good password hashing algorithm. Use something like bcrypt, scrypt or PBKDF2.

In this case, it is absolutely trivial to begin cracking passwords on your system. Completely random passwords of at least ten characters may still be secure, but any password that is shorter or makes heavy use of patterns or words will fall in a matter of minutes. Modern password crackers have extremely sophisticated engines that can take a base word like "password" and hash every plausible permutation of it ("p4$$wOrd!", "PaSs;WORD1234", etc.) in a fraction of a second. Some recent systems have even surpassed speeds of 348 billion hashes per second.

This is why your current algorithm is not good enough, and why it is an absolutely critical vulnerability that attackers can reveal your salts and hashes. Password-specific hash algorithms (typically known as "slow hashes") help defeat these kind of GPU-accelerated password cracking machines by requiring large amounts of work to compute a single password. PBKDF2, for instance, is a scheme that uses a repeated HMAC. By doing 100,000 or more iterations, you slow down these password-cracking machines by the same factor. It may now take you half a second to verify a user's password in legitimate cases, but attackers now require days just to enumerate through even the most common of passwords.

Algorithms like scrypt go even farther, requiring a configurable amount of memory in order to generate the hash. If your passwords require 128MB of memory to compute, this will barely be noticeable by a standard webapp. But for a password cracker, it would require extremely large quantities of memory to compute hashes in parallel (which is how most of them achieve such great speeds).

In your current situation, you must close down the vulnerability that allows people to reveal salts and hashes. Existing passwords should be considered compromised unless they can be unambiguously proven otherwise. You should migrate your passwords to one of the recommended hashing algorithms as soon as is practical. You can simply compose the existing hashes with the new algorithm, so given h = HMAC-SHA1(password, salt), calculate h' = bcrypt(h) and use h' as the authenticator.

share|improve this answer
The vendor has already stated they are not going to patch the vulnerability. The vulnerability is "IPMI 2.0 RAKP Authentication Remote Password Hash Retrieval" I need official sources or references for further justification that the vendor's solution of use a long password isn't sufficient. – Rodney Beede Aug 12 '13 at 19:53
I continue to wonder who these people are that keep coming up with industry-wide specifications that contain trivially avoidable security issues. – Stephen Touset Aug 12 '13 at 20:06

If all passwords are long and truly random then it isn't bad. As long as all of the hashes that can leak are not vulnerable to being attacked based on current hashing performance, then there isn't any problem. That said, you can't guarantee that users won't do stupid things (and you pretty much CAN guarantee some will.)

In general, offline attacks against hashes are very fast, so the required complexity gets very high, very quickly. If the only option is online attacks, then rate limiting can be applied which helps prevent attacks against the logon and greatly increases security, however it is still good for hashes to be resistant if leaked.

I don't know of any industry documents, but the simple answer is that people using creatively stupid things as their password is the reason why it is bad. P@ssw0rdPa$sw@rdpAs$wOrd isn't secure, even if it is long.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.