[WEB SECURITY] Salt Storage - web.config or database?
eaton.lists at gmail.com
Thu Jun 1 14:36:23 EDT 2006
On 6/1/06, der wert <derwert at hotmail.com> wrote:
> >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
I try to split my time between thinking like a hacker and thinking
like a developer or a product manager with a limited budget. I think
a lot of the time security people shoot themselves in the foot by
refusing to acknowledge the trade-offs involved in the security
measures they suggest.
> >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
Yeah, all true. And if you reread my original note you'll notice that
I didn't imply that any of it wasn't true. I said they couldn't use a
precomputed dictionary to do the crack, they'd have to generate it
after stealing the hashes and the salt.
> 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
If you keep them separate, you add some security because someone needs
to break into both databases before they can run their dictionary
attack. That, in theory, improves the security. In practice, it's
probably a waste. Consider:
- You want to improve the security by having separate databases. That
probably means you shouldn't host the databases on the same machine,
since an attacker who gains access to one DB on a machine can probably
gain access to the rest. So you just increased your hardware costs,
added another failure point to your system, another machine that needs
to be backed up, patched, etc...
- The code to do the authentication just got more complex. Now it
needs to talk to two separate databases. Not impossible, just a
little more trouble. You also ought to make sure that you test to
make sure the code handles failure of either database gracefully, so
your test costs just went up as well. (Hopefully the developers will
still have time to check for other security issues in their code!)
- Of course, you're probably going to use the same software to run
each database, and both databases are going to need the same access
controls. Which means the two databases are going to have the same
vulnerabilities. A hack that gets into one DB is probably going to be
able to get into the other one.
So you just increased your hardware, development, and maintenance
costs, for a marginal (at best) increase in the security of your
application. You've also taken time away from focusing on the other
security aspects of the system. Was that trade-off worth it?
Don't make your case to me, make it to Cynthia. And remember, she is
on a budget.
The Web Security Mailing List
The Web Security Mailing List Archives
More information about the websecurity