Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

RE: Salt Storage - web.config or database?

Subject: RE: Salt Storage - web.config or database?
Date: Fri, 2 Jun 2006 18:43:30 -0500
Cynthia Peluso 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 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.  If stored in
web.config what level of protection is required?

Huh? The salt is (almost?) always stored with the password itself,
either preprended or appended to the hashed password. This should
require very minimal increase in traffic volume. Storing in the
web.config would be (IMHO) rather insane. It would have to be
updated everytime a user changes their password. Also, web.config
is unlikely to be as optimized for searches as a database is...at least
if you are talking about hundreds of thousands or millions of users.

As far as level of protection, you don't obviously want to make the
salts available to someone who could try to mount an offline dictionary
attack as that would probably defeat the purpose. I'm no IIS expert,
but I should hope that the normal permissions on web.config would
accomplish this to prevent both read and write access from all by
administrators. Probably IIS / ASP.NET doesn't even need to be able
to have write access. But if you stored salts in it, you would likely
have to give the ASP.NET worker process write access so it could update
it with new salt information whenever a user changes their password
or whenever a new user is added. That's probably just asking for
trouble.

-kevin
---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall@qwest.com    Phone: 614.215.4788
"The reason you have people breaking into your software all 
over the place is because your software sucks..."
 -- Former whitehouse cybersecurity advisor, Richard Clarke,
    at eWeek Security Summit


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

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

Watchfire named worldwide market share leader in web application
security assessment by leading market research firm. Watchfire's AppScan
is the industry's first and leading web application security testing
suite, and the only solution to provide comprehensive and consolidated
remediation task lists at every level of the application. See for
yourself.
Download a Free Trial of AppScan 6.0 today!

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


<Prev in Thread] Current Thread [Next in Thread>