Password Storage and Salts
 

So anymore, what with haxors getting more and more 1337 (or RAM and drive space are getting cheap enough that it is possible to utilize rainbow tables in a more personal environment), it has become more standard to NOT store passwords in your database, but rather a one way hash of the fore mentioned password to ensure that if someone hacks your database, they at least have to work in order to get your passwords.

To further inconvenience Rainbow tables and their users, another tactic is to append a random series of bytes (or stings or chars or whatever) to the password before hashing, and then storing the salt in the database along with that hashed salt+password.

I guess my question is, while I understand the concept of adding the salt is to require an exponentially larger compiled rainbow table in order to "crack" the password, but what is the point? I mean, if someone haxors my database, they're going to have access to my salt table, and therefor will still be able crack my password.

I suppose by appending random bytes per password, that mean that theoretically no two passwords will work with any given one Rainbow table, and therefore the haxor would have to rebuild the table for each password based on the salt. Is this the general idea that this scheme is banking on?

Just thinking out loud and curious to your thoughts...
~Drego

why not put the salt in your code, rather than store it in the DB?

I was under the impression that salt + append was to prevent brute-forcing from a front-end (like a web UI), not direct DB access. Sure, if they're getting INTO your database, then salt is relatively pointless. But if they're trying to brute-force it from the "outside," it helps a ton.

I my apps I use a ramdom salt that is stoed in the database plus a static salt that is appended to the password. The latter is only available in my source code.

That's clever. Best of both worlds. I'm going to steal that! :thumbsup:

the salt should be different for each password, if the salt is the same, you can still create a table to make cracking a set of passwords easy.

I agree that the salt should be different for each password. Dilberts spot on in that fact.

While we're sharing our schemas, the one that I'm currently a fan of is first i append a random salt to the password so we have <salt><password> string. From there I do a quick encryption of the string (Rijndael, static key / IV) and then hash it (SHA256).

The overhead isn't to bad at all, but I have not tested it with say....10000 simultaneous logins or anything.