Re: Salt Storage - web.config or database?

[Steve Barnet <steve.barnet () icecube wisc edu>]

cynthia.peluso () us ngrid com wrote:
> Where is the best place to store salts?  I have developers that will be using the 
> Microsoft random number generator (ASP.NET ) to generate a salt to append to the 
> password and then hash.  They want to store the salt in the web.config file and the 
> password hashes in the database.  

This is not necessary, and may well be undesirable. This does
very little to improve security and creates more complexity
and more failure modes.

Salting does nothing more than ensure that identical passwords
with different salts hash to different values. This solves a
few very narrow attacks:

1) Precomputed dictionary attacks. If an attacker wants to
   precompute a list of password hashes for later comparison with
   stolen hashes, they must now compute the hashes for the
   number of words * number of hash values instead of a single
   hash for each password.
2) Identical passwords hash to different values. If you break a
   particular password hash, you cannot do a trivial comparison
   with hashes using a different salt to find other usernames
   which use the same password.
3) Same password used on different systems. This is essentially
   a special case of the # 2.

Salting does very little to mitigate an attack on a single
password hash.


> What is best practice for salt storage?  

Store the salt with the hash. There's not much security added
by keeping them separate and the opportunity for error in
separating them is not worth it.

> The developer's concern is that storing the salts in the database will increase 
> traffic volume. I'm not sure if this is the case as we are talking 16 bytes or so.  

It's hard to judge this without knowing the arrangement of pieces
and the scale of the problem. Adding 16 bytes for a few hundred
queries is small. Scale that to a few hundred million and it can
be significant.

However, all this does is change *where* the traffic goes, it
doesn't eliminate the traffic.

> If stored in web.config what level of protection is required?

Well, now you've got an open file handle to web.config. Who knows
how many creative ways such a thing could be manipulated?

Best,

---Steve



-------------------------------------------------------------------------
Sponsored by: Watchfire

Watchfire's AppScan is the industry's first and leading web application 
security testing suite, and the only solution to provide comprehensive 
remediation tasks at every level of the application. Change the way you 
think about application security testing - See for yourself. 
Download a Free Trial of AppScan 6.0 today!

https://www.watchfire.com/securearea/appscansix.aspx?id=701300000007kaF
--------------------------------------------------------------------------