Best practice for password hashing
in [Cryptography]
|
From: Maaartin on 8 Jun 2010 16:20 I wonder why nobody comments on the prevention of massive parallel cracking e.g., by GPUs. On Jun 8, 7:42 pm, "Datesfat Chicks" <datesfat.chi...(a)gmail.com> wrote: > I think you can actually combine all three approaches without a problem. If > the PBKDF2 algorithm allows very long passwords, you can just append the > "hidden basis value" to the user's password before starting the algorithm.. If you don't go for compatibility (and by using a suffix you do not), you can make any algorithm accept passwords of any length by hashing them first. On Jun 8, 8:39 pm, unruh <un...(a)wormhole.physics.ubc.ca> wrote: > > c)Using a hidden salt or hidden basis value (that won't be revealed if the > > database is compromised because it exists outside the database) so that an > > attacker is missing a piece of the information required to calculate the > > hash at all (which renders compromise of the database irrelevant because the > > hash stored there won't make an attack cheaper than just trying random > > passwords). > > Not sure what this protects against. And it is dangerous. If it is > stored on another machine suddenly this machine becomes useless if the > otehr machine goes down or is disconnected. Not good. If it is on the > machine, it is a "single point of failure" in that someone, somehow > getting ahold of that secret suddenly renders this protection useless. > And since that secret is reused and must last for years, the chances of > that failure grow. I agree, but I'd propose a simple improvement: You could use multiple secrets here, where one gets selected according the date of the password creation. This way the chance of compromising newer passwords is lower. The date of the password creation could be part of the salt. This assumes you have a write (or append) permission for the secret file (or that the machine it resides on does it for you).
From: Stewart Malik on 8 Jun 2010 21:32 First of all, to Paul Johnston, look at mcrypt, it's a pretty decent library and has wrappings for multiple languages. Also as for the hashing algorithm I suggest you use SHA it's a lot more secure than MD5 which is what is used a lot. As for the salt, make sure you use one that has capital letters, lowercase letters, numbers and symbols. > I agree, but I'd propose a simple improvement: You could use multiple > secrets here, where one gets selected according the date of the > password creation. This way the chance of compromising newer passwords > is lower. The date of the password creation could be part of the salt. > This assumes you have a write (or append) permission for the secret > file (or that the machine it resides on does it for you). Yeah that's not a bad idea, however if the attacker was somehow able to figure out the date that the password was created, e.g. I assume that in the database you won't only have the username and password fields, you'll probably have date registered, email, and other such fields. An extension of Maaartins idea is to have some subsidary salts. Something like the following. [1] (date selection, or randomly selected) salt 1 salt 2 salt 3 salt 4 [2] (date selection, or randomly selected) salt 1 salt 2 salt 3 salt 4 [3] (date selection, or randomly selected) salt 1 salt 2 salt 3 salt 4 [4] (date selection, or randomly selected) salt 1 salt 2 salt 3 salt 4 You choose either 1,2,3 or 4 randomly or by date, and then choose either by date or randomly the salt to use. You can then either leave it like this or append the parent 1,2,3 or 4 the the end or beginning of the salt thus speeding up checking of the password. This of course makes it less secure if the entire system is compromised or if the attacker has previously obtained the salt file, however if this is the case then they still need to compute 4 times as much information. If only the database has been compromised and the attacker does not know the salt, then they will need to compute 16 times as much information.
From: Paul Johnston on 9 Jun 2010 05:49 Hi, I've decided to use PBKDF2, partly because the "it's got an RFC" argument is quite convincing, and partly because it's got an easy to use library for my programming language (http://www.dlitz.net/software/ python-pbkdf2/) I'm not too concerned about the different compromise scenarios (database, server, etc.). I'll do what I can to keep the server and database secure, and I expect they'll be fine. Hashing is partly for the "just in case" scenario, and partly because myself and one other person will have authorised access to the database, and we shouldn't really see other people's passwords. As for brute forcing, I'm aware that all hashes are eventually brute forceable, especially with GPUs and rainbow tables. What I need is a balance between CPU load and ease of brute force, and I think PBKDF2 with the standard 400 iterations is exactly that. Thanks for the responses. Paul
From: unruh on 9 Jun 2010 12:37 On 2010-06-09, Carsten Krueger <cakruege(a)gmail.com> wrote: > Am Tue, 8 Jun 2010 13:42:49 -0400 schrieb Datesfat Chicks: > >> c)Using a hidden salt or hidden basis value (that won't be revealed if the >> database is compromised because it exists outside the database) > > That's bullshit (security through obscurity). Security through obscurity is fine, if you know its limitations. After the password of any system is "security through obscurity". The reason why there is the generic questioning of "security through obscurity" is that often the obscurity breaks down, and then that level of protection is gone. Any you often have no indication that it has broken down. But given that, it can offer an additional layer of protection. It just should not be relied on. (The German Enigma machines relied on security through obscurity. That it was eventually broken both illustrates that the security was real (the messages could not be read) and that it broke down (enigma machines captured) without the Germans knowing. Unfortunately it was the only line of defense, so when it broke, everything was lost. However, had there been a secondary line, that first line would have held for a few years, and then the second line need only have held again for a few years to make the system secure for the whole time. Don't downplay security through obscurity. Just do not rely on it. > > greetings > Carsten
From: Stewart Malik on 9 Jun 2010 20:28
I agree with unruh, mathematically all cryptography is merely security through obscurity. Of course if you needed to brute-force a perfectly implemented cipher that had a large bit-length and was sufficiently strong, or find collisions in a hashing algorithm, the time it takes may be longer than the age of the universe however it could still be mathematiclly broken. |