Securely storing passwords

[Rifts]

Hey,

 

I know this questions get asked a lot but here is a different version of it.

 

What is a simple and secure method for storing data/passwords? I know there is a lot of debate in this subject but I run a browser game off my server and just want the data to be encrypted.

 

is this good enough or is this easy to crack?

 

<?php
$password = 'abcdefg';
$salt = 'whateversecrethash';
$pw_hash = md5($salt.$password);
?>

 

or I just found this tutorial is this up to date and actually a good method?

http://webhole.net/2010/10/30/php-password-encryption-with-salt/

[Psycho]

You are right, there are a lot of discussions on this. Which is why we encourage people to search for related posts before creating a new one. First off you "hash" passwords, not "encrypt" them. Encrypting implies you can unencrypt. A hash cannot be unencrypted.

 

But, here is an existing post on the subject that should hopefully answer some of your questions as well as provide a solution that will be as secure as you need (PHPass).

 

http://www.phpfreaks.com/forums/index.php?topic=358612.msg1695040#msg1695040

[Rifts]

so the way I posted isn't good enough then?

[xyph]

'Good enough' is subjective.

 

I wouldn't trust my password with the above method though.

[doddsey_65]

In regards to password storing, overkill is best. For example you could use a salt and then use something like

 

 

$salt = $_SERVER['REMOTE_ADDR'];
md5(sha1(sha1(md5($salt.$password))));

[xyph]

$salt = $_SERVER['REMOTE_ADDR'];
md5(sha1(sha1(md5($salt.$password))));

 

That's adds no real difficulty in brute forcing the password, and limits entropy in your final digest.

[The Letter E]

$salt = $_SERVER['REMOTE_ADDR'];
md5(sha1(sha1(md5($salt.$password))));

 

That's adds no real difficulty in brute forcing the password, and limits entropy in your final digest.

 

Probably better off hashing the salt as well, since your servers remote_addr could be easily determined by an unwanted visitor. I personally just keep a small password hashing function in my library to reuse, then I can make minor adjustments in the hashing algorithm and salting algorithm easily and call the function on password creation and login alike.

 

something like this:

<?php
function hashpass($pass, $salt=null){
    if( !$salt ){
        $salt = substr($pass, 0, -4); //assumes min 5 character password
        $salt = $salt.$_SERVER['REMOTE_ADDR'];
    }
    //hash the salt
    $salt = md5($salt);
    //hash the pass
    $pass = md5($pass);
    //glue and rehash
    $hash = sha1($pass.':'.$salt);

    return $hash;
}
?>

[Pikachu2000]

Maybe I'm missing something here, but why would you use the client's IP address (or for that matter the server IP address) as part of the salt anyhow? What happens when their IP address changes, or they try to log in from a different location?

[The Letter E]

Maybe I'm missing something here, but why would you use the client's IP address (or for that matter the server IP address) as part of the salt anyhow? What happens when their IP address changes, or they try to log in from a different location?

Yea, that wouldn't make sense unless that IP was being stored in a database at the time the password is created.

[xyph]

It's much simpler to just use a random string for your salt.

[andrew_biggart]

I have recently done a lot of research on this topic myself as I am currently creating a custom CMS. I came across this useful link ( http://sunnyis.me/blog/secure-passwords/ ) which explains how to use the Phpass framework easily. It helped me lots, so hopefully you will find it useful as well.

[cpd]

Don't get me wrong, I enjoy implementing API's but when it comes to passwords your better off researching a topic and creating your own hash method.

 

The best techniques will involve dynamically hashing strings/passwords where the method of hashing differs from one pass to the next. Whilst its a vast and possibly ever lasting topic and potentially unwarranted in this instance, it still might be worth researching cryptography. Your first read of pretty much anything will give you a good insight into how passwords and sensitive information can be hidden.

 

And if your really adventurous you can get down to the nitty gritties like creating mathematical matrices for your own unique hashing method... just a thought.

[Psycho]

Don't get me wrong, I enjoy implementing API's but when it comes to passwords your better off researching a topic and creating your own hash method.

 

The best techniques will involve dynamically hashing strings/passwords where the method of hashing differs from one pass to the next. Whilst its a vast and possibly ever lasting topic and potentially unwarranted in this instance, it still might be worth researching cryptography. Your first read of pretty much anything will give you a good insight into how passwords and sensitive information can be hidden.

 

And if your really adventurous you can get down to the nitty gritties like creating mathematical matrices for your own unique hashing method... just a thought.

 

Could you please provide some details about your experience that qualifies your response? Creating your own hashing method will not be more secure than one that is open source which hundreds, if not thousands, of people with advanced experience have reviewed for flaws. Suggesting someone with little to no experience to build their own hashing method is inadvisable IMO.

[cpd]

I think you've misunderstood what I meant by "create your own hash method". I was merely referring to creating your own PHP Class or something similar which implements different hashing methods such as sha or haval. I've not even looked at Phpass and have no idea what it's like so cannot comment specifically on this tool; having taken a sneak peak though it seems to implement some sort of C functions with MD5 hashing, not sure as I haven't taken a good look.

 

My final comment was largely related to a conversation I had with a friend coming to the end of his Maths degree where we discussed how matrices are implemented in cryptography and begun creating our own encryption method - for fun. It can be thought of as a rhetorical idea as a newly founded programmer should not be expected to construct their own advanced hashing method as it involves a very specific and vast topic (some people do like to read and understand what's happening, however). Forgive me if this was not apparent but I think the village idiot could work out a new programmer is incapable of completing such a task.

[scootstah]

$salt = $_SERVER['REMOTE_ADDR'];
md5(sha1(sha1(md5($salt.$password))));

 

That's adds no real difficulty in brute forcing the password, and limits entropy in your final digest.

 

Not to mention that in the end, no matter how complicated the thing you hashed was, MD5 is still breakable in < 10 minutes on modern computer hardware.

 

Seriously, stop using MD5 for passwords.

[xyph]

MD5 isn't the issue, it's the implementation. Using PBKDF2 with an HMAC'd MD5 implementation is extremely resource consuming to brute-force. I'm not going to argue that it's ideal, but it's definitely 'good enough' and scalable. Ideal would be avoiding speedy algorithms altogether, but there are times when portability requirements limit choices.

 

@ The Letter E - Salts don't need to be secret. Obfuscating them adds no significant security.

 

@ CPD - There's nothing wrong with building your own implementation for educational purposes, but that's terrible advice for anything being designed for production use. You're much better off using a peer reviewed implementation of a security procedure. You have to watch out when saying 'The best techniques...' because I doubt you are qualified to say it. PHPass uses a stretched implementation of MD5 as a fall-back or if portable hashes are needed, otherwise it implements bcrypt. It was designed by a well known security expert. The issue with security is flaws generally don't show up until an attacker manages to find them... at this point your only hope is that they're white-hat.

 

@ http://sunnyis.me/blog/secure-passwords/ - There a lot incorrect information and terminology in this blog post. It is much less complete than the article on Openwall, linked in my signature.

[The Letter E]

MD5 isn't the issue, it's the implementation. Using PBKDF2 with an HMAC'd MD5 implementation is extremely resource consuming to brute-force. I'm not going to argue that it's ideal, but it's definitely 'good enough' and scalable. Ideal would be avoiding speedy algorithms altogether, but there are times when portability requirements limit choices.

 

@ The Letter E - Salts don't need to be secret. Obfuscating them adds no significant security.

 

@ CPD - There's nothing wrong with building your own implementation for educational purposes, but that's terrible advice for anything being designed for production use. You're much better off using a peer reviewed implementation of a security procedure. You have to watch out when saying 'The best techniques...' because I doubt you are qualified to say it. PHPass uses a stretched implementation of MD5 as a fall-back or if portable hashes are needed, otherwise it implements bcrypt. It was designed by a well known security expert. The issue with security is flaws generally don't show up until an attacker manages to find them... at this point your only hope is that they're white-hat.

 

@ http://sunnyis.me/blog/secure-passwords/ - There a lot incorrect information and terminology in this blog post. It is much less complete than the article on Openwall, linked in my signature.

 

I never stated they "need" to be hashed/obfuscated, that's just one of the many possible options available to an engineer. I've seen it done either way, both by noteworthy development teams. Assuming we're all going to stick to 1 golden rule on hashing passwords that would make brute forcing attempts that much easier. It's the fact that it can be done n different ways that makes brute forcing a pain for malicious hackers. Granted it would take a while to generate a match to any random string, hashed or not.

[xyph]

Why add extra overhead for no 'real' extra security?

 

It's the fact that it can be done n different ways that makes brute forcing a pain for malicious hackers. Granted it would take a while to generate a match to any random string, hashed or not.

 

No, the length of time it takes for an attacker to produce a digest from any plain-text source can make brute-forcing a pain. Salts exist to prevent your digest from 'leaking' information, such as duplicate passwords between users. Certain applications of 'salts' also prevent collision-based attacks in 'weaker' algorithms, but again, obfuscating these won't necessarily hinder an attack. If you want to obfuscate it you're welcome to, but it won't add any significant security to your hashed passwords. Informing others that it is good practise is bad advice.

[The Letter E]

At any rate, totally unnecessary to hash the salt, and not smart to pull from easily reproducible data, especially ip addresses, since there are only so many to choose from. You and I also overlooked the fact that I totally concatenated the pass and salt together improperly...but I can tell it was mainly because you were all hyped about the whole obfuscating the salt move.

[xyph]

How did you do it improperly?

[cpd]

I had quite a long chat with another member about this and was explained thoroughly the pros and why, in the majority of situations, its not great to write your own algorithms or classes etc.

 

Apologies for saying "take a look at constructing your own". It isn't such a good idea in most cases (largely dependant on your knowledge)! Although it is quite fun and very interesting IMO.

[The Letter E]

How did you do it improperly?

My intention was to do something like sha1($pass.$salt).':'.$salt; Assuming the salt was randomly generated, it would be nice to have it available for authentication. I shouldn't write untested sloppy examples of code for topics so important to a websites integrity. Even though it did spark a nice discussion on certain pitfalls and/or reasons not to do certain things.

[xyph]

I thought you meant to regenerate it because it was based on password and REMOTE_ADDR.

 

I suppose if you needed to recall the salf directly from the hash, your posted code wouldn't work too well