[WEB SECURITY] Salt Storage - web.config or database?

der wert derwert at hotmail.com
Thu Jun 1 13:06:14 EDT 2006


>So from a security perspective, the answer is probably "doesn't matter."

you obviously don't think like a hacker, and you don't seem to understand 
web security

>A salt should not need to be kept secret.  The idea is that if someone
>steals the password hashes and the salts, they can't use a precomputed
>dictionary to crack the passwords.  So from a security perspective,
>the answer is probably "doesn't matter."

they can crack the hashes, the thing is it will take much longer
they just have to get the salting method and if they have the salt and hash 
they will create a program that will generate the hashes using the salting 
method and the salt with words from a dictionary and compare the two, when 
they match they know what the password is, if the password are not in the 
dictionary then they will have to use a bruteforce method which can take 
longer, but for ppl that have weak passwords it may not take that long

from my experience in dealing with salted hashes and salts, I think it would 
be best to keep the two seperate, so if there is a db vulnerability then 
only the hashes will be exposed and not the salts and hashes, etc


On 6/1/06, Brian Eaton <eaton.lists at gmail.com> wrote:
>On 6/1/06, Peluso, Cynthia M. <Cynthia.Peluso at 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.
> > What is  best practice for salt storage?  The 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.  If stored in
> > web.config at the presentation layer, should it be encrypted?
>
>A salt should not need to be kept secret.  The idea is that if someone
>steals the password hashes and the salts, they can't use a precomputed
>dictionary to crack the passwords.  So from a security perspective,
>the answer is probably "doesn't matter."
>
>On the other hand, if you are ever going to want other applications do
>be able to use this database for authentication, having the password
>salts in the web.config file would make that more difficult.
>
>There is also the matter of how well the web.config file is going to
>scale.  You're going to have one salt per-user, right?  That
>web.config file could get large fairly quickly.
>
> > The concern is that storing the salts in the database will increase 
>traffic volume.
>
>Unless someone has actually measured the difference in performance,
>this is just blowing smoke.
>
>Regards,
>Brian

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


----------------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/



More information about the websecurity mailing list