shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: Salted hashing of passwords - where to store the salt?
Date Sun, 31 Oct 2010 18:28:21 GMT
Wiki worthy, imo.


On Oct 30, 2010, at 12:49 PM, Les Hazlewood wrote:

> If an attacker has already compromised your data store and they can
> see both the credentials hash and it's salt (whether the salt is
> random or not), then yes, it is possible to perform dictionary
> attacks:  They can use the discovered salt + a dictionary value as
> input to the hash function to try to compute a matching value.  If the
> resulting hash matches the stored credentials hash, then they will
> infer the original plaintext password.
> There are 3 options I can think of that you can do to make this more secure:
> 1.  Definitely use more than one hash iteration (this is built into
> Shiro's Hash concept).  The number of hash iterations is usually
> application-wide, so it is not necessary to store along side the
> password and the salt.  This makes it a) much much harder for
> dictionary attacks since the number of iterations is one more piece of
> data they may not have access to, and b) significantly slows down the
> attacker since they have to perform multiple hashes for _each_
> salt+dictionary value pair in real time.
> I do this for all of my passwords and never use just a single
> iteration (I usually use somewhere between 500 and 2000 iterations).
> The speed difference is negligible to end-users but quite noticeable
> to attackers.  Also, because of the speed difference, that gives you
> more time to discover what is going on and shut things down.  For
> example, maybe some monitoring alert is triggered because your CPU
> spikes because they're thrashing it or the number of requests is
> abnormally high and you can investigate quickly.
> 2.  Similar to the concept of the number of hash iterations not being
> stored along side the password hash & salt, you could pair a server or
> application-specific salt with the account salt and use that as the
> total salt supplied to the hash function.  For example:
> salt_bytes = server salt bytes concatenated with user-specific salt bytes
> credentials hash = SHA-512(salt_bytes + plaintext password bytes)
> 3.  Store the salt in a separate data store.  If the attacker
> compromises one data store, it does not necessarily mean they can
> compromise the other data store.
> Note that if you use either a salt or change the number of hash
> iterations, or both, it virtually eliminates the possibility of
> rainbow attacks.  For those unaware, a rainbow attack uses what is
> called a 'rainbow table': essentially a huge map of pre-calculated
> hash values (key: plaintext password and/or dictionary word, value:
> hashed output).  Rainbow attacks are powerful because there is very
> little computation time for the attacker - they simply look up a value
> for a given plaintext key.  If the hashed value matches what is
> stored, they immediately know the original password.
> But the possibility of a pre-computed rainbow table knowing about a
> salt is nearly impossible if your salts are sufficiently large
> securely randomly generated numbers - as they absolutely should be -
> and not say, based on account data such as a username or given name.
> That's why good secure-random salts effectively eliminate the
> possibility of rainbow attacks.
> Anyway, #1 and #2 add that extra bit of difficulty, but then you have
> to ask yourself - "If they can compromise my data store, then do I
> consider my application compromised as well?".  If so, then #1 and #2
> don't matter much.  But I still consider them useful and use them
> myself for that 'extra bit' that makes it that much harder to attack.
> #3 is also useful, but most of the time considered too impractical for
> most applications.  This stuff is about making it 'sufficiently
> difficult' to deter attackers.  You have to judge for yourself what
> constitutes being 'sufficiently difficult' for your application.
> Storing the salt along side the password is perfectly fine for 98% of
> all applications, which is why it is such a common practice.  Doing #3
> might only be worthwhile for certain government/NSA type of
> applications (and believe me, most government apps I've seen have
> nowhere near this level of security built in, sadly enough).
> Anyway, that's my $1.02 - I hope it helps!
> Cheers,
> -- 
> Les Hazlewood
> Founder, Katasoft, Inc.
> Application Security Products & Professional Apache Shiro Support and Training:

View raw message