0

Possible Duplicate:
Salting Your Password: Best Practices?

The company I work for is building a social network (like many other people are). While working on the user login system I was unsure what sort of hashing to use. I know never to use md5. I have an interesting way of working with sha512 and whirlpool and a changing salt. My boss says he may want to have users finacal data connected with there login info. The language is PHP just to let you know.

Community
  • 1
  • 1
WojonsTech
  • 1,237
  • 1
  • 13
  • 28

3 Answers3

2

Whatever you do, do NOT roll your own password hashing function. The very worst thing you can do is "have an interesting way of working" with crypto primitives. Algorithms like bcrypt have been developed and analysed by professional cryptographers, and they are much better at it than me, you, or just about anyone else on StackOverflow.

It is surprisingly easy to weaken your security when you think you are strengthening it.

Also, for financial information, do NOT roll your own password hashing function. It's important enough to say twice.

Cameron Skinner
  • 45,321
  • 2
  • 63
  • 80
  • @Carmon Skinner I am not going to roll my own I know better then that one. I have in the past looked into how those are made and its a lot of work. What i am talking about is how i should add the salt into the users password and which functions to use. for example. I can do. $password.$salt or i can do $salt.$password$salt and then hash it. – WojonsTech Oct 04 '11 at 06:53
  • 1
    OK, I'm glad to hear that. In terms of salt, it doesn't matter whether you prepend or append it, but there's no point in including it twice. Read up on PBKDF2 (http://tools.ietf.org/html/rfc2898) to see how to implement a good hash function, or http://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php for a good description of how to use bcrypt in PHP. – Cameron Skinner Oct 04 '11 at 06:57
  • The reason i play around with prepending and appending or split it in half and mixing it into the users password is the following. Lets assume the hacker gets the database table of users and not the code. they wont know how i applyed the hash. so if they try to brute force $password.$salt. but i used $salt.$password. they would be wasting there time. they need to be able to apply the salt correctly. to there burteforce string. if the salt is mixed in with the password it means that they have to burte force from strach and cant use the salt. – WojonsTech Oct 04 '11 at 07:10
  • 1
    @WojonsTech, the matter of whether the salt should be at the beginning or end of the password is 1 bit of information that the attacker has to guess. Just choose a long enough salt from a good random source and you have lots of bits that the attacker must guess, in a much simpler way. – Wyzard Oct 04 '11 at 07:19
  • @Wyzard for my salts i normally use. mt_rand and then i change it to a base 36 number. I know that the hacker has to guess. But I want to make sure that them trying to hack a single user will cost them so much money and so much time just to figure out the method that I am injecting the salt. for example. Most people prefix or append the salt. the the attacker will make 2 clustets trying to figure out which one it is. But if they finally realize that its not post or prefix they will will have to split there reources even more just to find my method. it does take more cpu for me buth worth it. – WojonsTech Oct 04 '11 at 07:23
  • @WojonsTech, I'll bet you're mixing the hash into the password using the same algorithm for every user. So the attacker (who has your users table) looks at the stored salt for his *own* account, and figures out how to mix it with his own (known) password to get the right hash, and then applies the same formula to all the other records. Better to use an iterated hash, to ensure that every record requires lots of CPU work with no way to do the work once and apply it to many records. – Wyzard Oct 04 '11 at 07:33
  • @Wyzard you have a very good point there. They would have to spend some time trying to figure it out how the salt is being intergrated with there password and then find the salt which should take a fair amount of time. I think i will have the algrium change based on user id or the last time that they loged in something like that. – WojonsTech Oct 04 '11 at 07:41
  • @WojonsTech, no, do what CameronSkinner said: use a tried-and-true technique like bcrypt; don't try to invent your own ingenious scheme. Refer to [Schneier's Law](http://en.wikipedia.org/wiki/Schneier's_Law): just because you think your scheme is strong, doesn't mean it is. There are people who research this stuff as a career. – Wyzard Oct 04 '11 at 07:46
  • @Wyzard I know that they are the best I just like to do some magic before I hand it off to the pros. I will jumble things up using the salt and then I will use the correct type of hash. This way its not generic and takes some time to break my method and then you have to work your way around things like blowfish or sha512. Every IO operation counts :) every one they have to do the more time it takes them. – WojonsTech Oct 04 '11 at 07:50
  • @WojonsTech: There are two issues you should be aware of. The first is that you should assume that the attacker *does* have access to your code. It makes your security analysis that much stronger if you make this assumption. The second (perhaps more important) point is that the salt is not there to make brute force harder. The salt is to ensure that a single brute force attack can affect only one password, so to break *n* passwords requires *n* brute-force attacks. Using an iterated hash is the bit that makes it infeasible for any of those brute force attempts to work. – Cameron Skinner Oct 04 '11 at 19:37
  • @CameronSkinner You have some great points the reason that I think of them not having my code is the simple fact that if you look at secirty as a whole there is just so much so u have to think of it like an oion and just take one layer at a time. As the project advances we will be buildint out server arch and hardning the linux – WojonsTech Oct 06 '11 at 10:33
1
  • Use a good hash function.
  • Use a separate salt for each user.

I've recently seen Blowfish recommended as a best practice for password hashing, on the basis that it's slower than the SHA family so it makes brute-force guessing attacks less practical. According to Wikipedia, OpenBSD uses it for this reason.

You might also consider implementing support for OpenID so users don't have to store a password on your site at all. (That'd be a nice optional feature for a social network, though it may not be acceptable for a financial site, e.g. for regulatory reasons.)

Wyzard
  • 31,764
  • 3
  • 60
  • 78
  • The system does have a separate salt for each user that changes each time they login. I also hash with sha512 and whirlpool so if u burte force u need a collustion on both algs. I dont do sha512(whirlpoo(password)) i do sha512(password) and then save and then do whirlpool(password) save it seperately. I know the system will have some open id and social logins from other sites. – WojonsTech Oct 04 '11 at 06:51
  • @Wojons LOL! how does it help with separate hashes? – Your Common Sense Oct 04 '11 at 07:03
  • 1
    @Col.Shrapnel, a successful preimage or brute-force attack against one of the functions will yield a value that doesn't match under the other function. There's some value there, though it's not clear whether it's worth the extra storage cost; successfully reversing even one good hash function, other than by guessing the real password, is already rather unlikely. – Wyzard Oct 04 '11 at 07:08
  • a successful preimage or brute-force attack against one of the functions will yield a **friggin' password**. Period. The rest of your speech is unnecessary. – Your Common Sense Oct 04 '11 at 07:15
  • @Col.Shrapnel what Wyzard is talking about is whats called a collistion. In a hashing algrotim i can enter 2 different strings that will return the same hash value. one string could be the real password and the other one could be a random string. If the burte force returns the random string that is not the password it does not mean that that random string will yeild the same result on the other hash algrotim therefore they have not be granted access to the system. – WojonsTech Oct 04 '11 at 07:19
  • 1
    @Col.Shrapnel, preimage most likely won't. There are an infinite number of strings that hash to any given result, and a "realistic" password isn't any more mathematically significant than the others. Brute-force likely will, though, assuming the attacker is smart about trying realistic passwords before random garbage. – Wyzard Oct 04 '11 at 07:21
  • @Woj In fact, to find a collision is much harder than to find an original pass :) Though you are free to think that these collisions will help you with site security. cheers :) – Your Common Sense Oct 04 '11 at 07:22
  • @Col.Shrapnel with "random change" it is just as likly that someone can find the collision as it is the orginal password. But the fact the attacker has no idea what it is they have to guess. but because the way i inject the salt the salt. a users password looks more like a random genreated pass therefore finding the collison is just as likly. – WojonsTech Oct 04 '11 at 07:39
  • 2
    @Woj that's again false feeling of security. These "ways i inject the salt" are no more than children games, has nothing to do with security. – Your Common Sense Oct 04 '11 at 07:49
  • they have to deal with the random chance then with security.you are looking at it at an over view while i am looking at it from one part of the system at a time. I know that the average user will pick a password betwen 6-10 characters that wont have any numbers of symboles in it. the front site will block users with to many failed attempts like any other site. but for a hcacker with my user table will have to run threw about 10^26 combanations to hack each user if they knew the algorum that i hash things since they dont the strings are 128 char. – WojonsTech Oct 04 '11 at 07:54
-1

Two obvious things to bear in mind which everyone prefer to forget:

  1. Password hashing actually adds nothing to the site security itself. It's just for such imaginary case when your user base was stolen and used against the same users somewhere else.

  2. No hashing algorithm with super-extra-random salt will protect silly passwords like 'joe', '123' or 'password'. Or even more complex passwords like 'v5dsa'.

So, you have to either torture your users with strong passwords requirement or just forget such a silly matter as a password hashing.

Or simply warn them not to use the same password for your site and your mission accomplished!

Hashing problem is way exaggerated on this site.
An average so-called "PHP programmer" thinks that if they don't use MD5 which is "broken" (though they have no idea what does it mean) - they are safe.

The poor OP is a perfect example of what I am saying:
He is doing 2 different hashes and store them separately. thinking it will help with securing their site :)

That's the problem. An average user is thinking that password hashing has something to do with site security. While it is not.

Your Common Sense
  • 152,517
  • 33
  • 193
  • 313
  • 4
    NO! Sony had their entire Playstation Network password database stolen. It is *NOT* an imaginary case at all. Iterated hashes or slow functions (like bcrypt) provide some level of protection for short passwords, and very good protection for long passwords. You are right that the password 'password' will never be safe, but you certainly do need to use a good password hashing system to protect those users that choose good passwords. – Cameron Skinner Oct 04 '11 at 06:53
  • Imaginary? Hardly. And people often *do* use the same password on multiple sites. – Wyzard Oct 04 '11 at 06:54
  • @Cameron password hashing didn't help sony users. They've lost their credit cards info. That's the problem. You have to protect your system and hire a good pro for it. Not just salt your hashes and dream happily in the false feeling of safety. – Your Common Sense Oct 04 '11 at 06:58
  • The hack on the sony system was a stolen db. I am not sure if sony encrpyted the credit card numbers or not. But that was an issue with the playstation network and not the hashing on user passwords. Also hashing a password is important. the amount of time it would take for someone to find a match on a hash password can be anywer from hours to days depending on how complex ur hashing is some times it will take months. also if each user has a different salt. then a simple compare will not prove if 2 users have the same password looking at the hashed values. hashes and salts help alot. – WojonsTech Oct 04 '11 at 07:07
  • @Col.Shrapnel I know that the hashing is not for the overall site secirty I am using it to avoid burte forcing or someone that ends up with a copy of the user table not be able to login. – WojonsTech Oct 04 '11 at 07:27
  • @WojonsTech, wait. What "avoiding burte forcing" you are talking about? – Your Common Sense Oct 04 '11 at 07:50
  • @Col.Shrapnel How do you make it more secure then? what are the steps to take into consideration for a better (best) secure system? any resources you can suggest? – Damien Pirsy Oct 04 '11 at 08:47
  • @Damien web site security is endless issue, cannot be sescribed in tone comment. In fact, one have to learn it for the whole life. A resource is OWASP for sure and steps are avoiding SQL injection, file injection, XSS and CSRF attacks. regarding passwords it's password strength (requiring longer password with different symbols) and password guessing protection (making a delay between login attemts) – Your Common Sense Oct 04 '11 at 08:51
  • @Col.Shrapnel Thanks, I know all those factors (not saying anything about how good I do agaisnt them, of course), and I also know the OWASP guides. EDIT: Oh, ok, I was thinking exactly at the delay between login and password strenght, thank you – Damien Pirsy Oct 04 '11 at 08:57
  • @Col.Shrapnel: You are confusing site security with mitigating the effects of a breakin. Password hashing does not prevent people breaking in to your system, you are correct there. But it does mitigate the damage when someone *does* break into your system. Here's an analogy: Having a safe in my house to protect my passport does not make my house any more secure. A burglar can still break a window to get in. But once they're in, the safe makes it much harder for them to then steal my passport. You are argueing that I should strengthen the front door lock so that I can leave the safe open. – Cameron Skinner Oct 04 '11 at 19:41
  • @Cameron you are misrepresenting my words, I've never said that. To use your analogy, everyone here never thinks of the front doors and walls and fencing windows at all, but of safe lock only. while this safe is negligible part in comparison to other. Look at the DP - there are no questions about security, bit "stronger hashes" being asked in dozens. that's a consequence of such a twisted exaggeration I am talking about. In fact, there are only few professionals here who understand the matter. The rest just repeat mindlessly the same text they read from each other. – Your Common Sense Oct 05 '11 at 07:17