Welcome Guest, Not a member yet? Register   Sign In
phpass HAVE BEEN CRACKED! What is the solution?
#41

[eluser]Jondolar[/eluser]
Another security option is to encode your code with either Zend or IonCube so if your code is stolen, your hashing algorithm can't be easily deciphered.

Some things to remember:
1. Using a salt requires 1 rainbow table to crack most, if not all, of the passwords in your table
2. Using a random salt per record requires 1 rainbow table per record to crack 1 record and the rainbow table must be rebuilt for each record.
3. Setting someone's password for them and not allowing them to change it requires them to write it down every time. Not one person in the world has ever, ever remembered a randomly generated password (well, there was one guy in Toledo back in '97). Every password in your database will be written down without fail or saved in an email forever. Don't do that.
4. Requiring the password to have upper/lower/numbers/specials and length requires the absolute most effort from a cracker and "most" users already have a remembered password with complex requirements.

In conclusion:
1. Put strong requirements on your passwords (it's been said many times before).
2. Hash with a random salt per record
3. Other things to consider AFTER you do the above is obfuscate your code, obfuscate the random salt field, etc.
#42

[eluser]dmorin[/eluser]
Two points I want to make about @Jondolar's post. First, obfuscating the code, while effective against casual script kiddies, is still debugable and traceable be people with more than casual software dev experience and they would most likely still be able to figure out your hashing algorithm, so don't put too much hope that this will save you.

Second, "obfuscate the random salt field" provides questionable additional security. See the following for a good discussion: http://stackoverflow.com/questions/53658...ord-hashes

Overall, very good points though
#43

[eluser]richwalkup[/eluser]
[quote author="jedd" date="1245209619"]I'd really like to ask my question again, but it might come across as though I'm taking the piss. Oh, bugger it.

Who has access to your hashed password list?

If your site allows people to hit a few million dictionary attacks an hour, then here's a clue - your problem is not the password encryption algorithm.

If you allow visibility of your password column in your table - your problem is not .. (etc).[/quote]


I asked myself the same question several times throughout the first page. If you have a weakness in your infrastructure that would allow access to your password store, you have way bigger issues than how you encrypt your passwords. Secondarily, I tend to use a combination of MD5 and SHA1 in various methods of split/concat/encrypt/encode so that the final product is a one-way hash of several other hashes so it's ridiculously unlikely to be broken even if it is hacked into. Also remember that NOTHING in cryptography is unbreakable - it's just a matter of time and effort.
#44

[eluser]dmorin[/eluser]
Quote:Also remember that NOTHING in cryptography is unbreakable - it’s just a matter of time and effort.

I believe the same thing about websites. Assuming your application can never be broken and therefore, protecting your database is pointless, is just not smart.

Quote:If you have a weakness in your infrastructure that would allow access to your password store, you have way bigger issues than how you encrypt your passwords.
If you thought your infrastructure was impenetrable, you wouldn't need to hash your passwords at all... (you'd also be wrong, but hey...)

So while I agree to a point, upon further reflection, it's also fairly short-sighted.

EDIT:
Sorry one more point:
Quote:Secondarily, I tend to use a combination of MD5 and SHA1 in various methods of split/concat/encrypt/encode so that the final product is a one-way hash of several other hashes so it’s ridiculously unlikely to be broken even if it is hacked into.

If someone was able to get your code along with your data store and you use the same "algorithm" of combining different hashes for each password, it would be trivial to make rainbow tables for your custom algorithm. The only advantage you get is that the multiple steps would make it take computationally longer to create, so I guess that's something.
#45

[eluser]Jondolar[/eluser]
[quote author="dmorin" date="1245373295"]Two points I want to make about @Jondolar's post. First, obfuscating the code, while effective against casual script kiddies, is still debugable and traceable be people with more than casual software dev experience and they would most likely still be able to figure out your hashing algorithm, so don't put too much hope that this will save you.

Second, "obfuscate the random salt field" provides questionable additional security. See the following for a good discussion: http://stackoverflow.com/questions/53658...ord-hashes

[/quote]

I agree with your points.
#46

[eluser]Dan Horrigan[/eluser]
If you really want to confuse an attacker trying a brute force using rainbow tables, you could use a pseudo-random number generator with predictable results when using the same seed to get random characters out of a few of the fields as your salt (not stored in DB). The seed could the password creation time or something. The attacker would have to know your pseudo-random number generator algorithm and what fields you used just to get the salt, let alone creating the rainbow table.

This may make no sense, as it was just a brain dump, but an interesting idea i think. Obviously if the attacker gets your code too, you are kind of screwed no matter what encryption you use.
#47

[eluser]taurine[/eluser]
After reading this thread, and seeing that after the developer does his part, the user still needs to pick a decent password in the first place, I found this: http://www.passwordmeter.com . Maybe some of the rules it checks for can be put into your password form, and require a user to get xx% before allowing registration or password change. It's javascript, and GPL licensed.
#48

[eluser]Unknown[/eluser]
Thats the reason why you should use a SALT on your password.

In that way it is IMPOSIBLE to crack!

$password = $_POST['pass'];

$encryptpass = $password . 'saltkey';

$encryptpass = md5($encryptpass);

OR what do you think?
#49

[eluser]WanWizard[/eluser]
For ExiteCMS I even do double hashing:
Code:
// generate a random salt for this password
users->salt = md5(microtime(TRUE));

// create the new password hash
$users->password = md5(md5(set_value('newpassword')).$users->salt);
#50

[eluser]slowgary[/eluser]
WanWizard,

Hashing twice is worse than hashing once. It increases the chance of a hash collision.




Theme © iAndrew 2016 - Forum software by © MyBB