Password Storage and Salts - Tilted Forum Project Discussion Community

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

spindles · 10-03-2007, 02:54 AM

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

Jinn · 10-03-2007, 07:06 AM

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.

trib767 · 10-03-2007, 10:33 PM

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.

ratbastid · 10-04-2007, 06:20 AM

Quote:

Originally Posted by trib767

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!

Dilbert1234567 · 10-04-2007, 08:19 AM

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.

drego · 10-04-2007, 09:36 PM

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.

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!!!!

10-03-2007, 02:54 AM	#2 (permalink)
spindles Mine is an evil laugh Location: Sydney, Australia	why not put the salt in your code, rather than store it in the DB? __________________ who hid my keyboard's PANIC button?

10-03-2007, 07:06 AM	#3 (permalink)
Jinn Lover - Protector - Teacher Location: Seattle, WA	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'm typing on a computer of science, which is being sent by science wires to a little science server where you can access it. I'm not typing on a computer of philosophy or religion or whatever other thing you think can be used to understand the universe because they're a poor substitute in the role of understanding the universe which exists independent from ourselves." - Willravel

10-04-2007, 08:19 AM	#6 (permalink)
Dilbert1234567 Devils Cabana Boy Location: Central Coast CA	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. __________________ Donate Blood! "Love is not finding the perfect person, but learning to see an imperfect person perfectly." -Sam Keen

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

10-03-2007, 10:33 PM	#4 (permalink)
trib767 Crazy Location: London, UK	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.