Tilted Forum Project Discussion Community - View Single Post

drego · 10-02-2007, 10:18 PM

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

10-02-2007, 10:18 PM	#1 (permalink)
drego Upright Location: WA......somewhere....I hope......	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 __________________ There is no such thing as "Bug Free" software....there is only software with an acceptable (and documented) level of failure. Hack the Planet!!!!