3

I am looking to create a commercial website using php and I wanted to make sure the code I have for user hashed password was strong enough to avoid brute force attacks.

Note that my server and it's php version does not support blowfish so I am trying to figure out a decent method of hashing a password.

$pw = "12341234";
$salt = 'randomchars';
$initial = sha1($pw);
$hashed = md5($salt . $initial);

Is there something else I should be considering? any thoughts would be appreciated!

Paul
  • 139,544
  • 27
  • 275
  • 264
Kevin Jung
  • 2,973
  • 7
  • 32
  • 35

5 Answers5

2

You want http://www.openwall.com/phpass/

chx
  • 11,270
  • 7
  • 55
  • 129
2

I think you are not aware of the fact, that the way you hash passwords does not influence the possibility of cracking the password by brute force attack (eg. when attacker tries to provide thousands of possible passwords). It only makes password safe in case someone sees the value in the database that is used to represent this password.

Tadeck
  • 132,510
  • 28
  • 152
  • 198
  • 1
    The algorithm can, however, affect how quickly a brute force attack can be executed. – Corbin Sep 11 '11 at 02:39
  • Corbin: of course, eg. if the algorithm takes into account only eg. 13 letters from the beginning of the password (similarly as some older versions of Microsoft Office did), then you have only 13 letters to guess. Or if the algorithm transforms every letter to lowercase before hashing/comparing. But this is not the case. – Tadeck Sep 11 '11 at 03:06
  • 1
    If someone has a copy of the database, and he or she is trying to brute force one or more passwords, the longer the hashing algorithm takes to run, the longer it will take to brute force one or more passwords. Yes, if someone is trying to brute force via a web form, the algorithm is not going to matter much in terms of time required (percentage wise anyway); however, "the way you hash passwords does not influence the possibility of cracking the password by brute force attack" is wrong by almost all interpretations of "possibility". – Corbin Sep 11 '11 at 03:44
  • Corbin: I strongly disagree. Consider one algorithm that ignores every sign after the 5th sign within the password (so if user has password `abcdefghijkl`, then both `abcde` and `abcdefg` will work for his account), but takes a lot of time to process (eg. ten times as much as sha1 algorithm) the password. In the first case the password would be cracked with brute force attack almost instantly. By brute force attack I meant the situation when someone makes multiple requests to login form, using some kind of script or other tool (such as [BadBoy](http://www.badboy.com.au/)). Is it clear now? – Tadeck Sep 11 '11 at 03:54
  • 1
    I believe we're arguing the same thing with different terminology. In fact, your comment previous to this one directly opposes the validity of your opening sentence in your answer. (Technically the truth of this comment depends on the definition of "possibility".) You first asserted that the algorithm used does not affect the feasibility of brute force attacking. Then, in your post previous to this one, you say that if you choose a weak algorithm, a brute force attack can be extremely quickly done. Which way is it? – Corbin Sep 11 '11 at 04:08
  • I think the difference is a result of us both speaking about brute force attack at different levels. Initially I was talking about brute force attacks conducted without access to the database and/or source code (so based only on submitting one form multiple times). But when I gave you an example of slow, but weak algorithm, I mentioned a brute force attack that I think you are talking about. I think this is important to distinguish here a brute force attack (where you try all the combinations, because you are unaware of algorithm's weaknesses) from, well, "educated" brute force attack. – Tadeck Sep 11 '11 at 04:36
  • One additional thing: I would not say there is a correlation between time used by the algorithm to generate the hash and the time needed to break the hash (I have already given an example, I think). In other words, I would not connect low efficiency to high "durability". – Tadeck Sep 11 '11 at 04:40
  • If someone has a copy of the database, his ability to crack users' password is least of your problems. I'd bet you'll have many other more important things to worry about then. – sanmai Sep 11 '11 at 04:44
  • 1
    If a certain algorithm takes 10ms longer to run (which would be a huge amount of time to hash 1 password), then each web request would take 10ms longer. Add that up, and yes, the time of the algorithm does affect it over the web as well. No offense, but this comment thread is devolving into babble about terminological differences and misunderstandings. The original point I disputed was that the algorithm chosen affects the amount of time that a brute force attack requires. I still dispute that. – Corbin Sep 11 '11 at 04:47
  • 1
    And, "I would not say there is a correlation between time used by the algorithm to generate the hash and the time needed to break the hash" is blatantly wrong. Please think about this mathematically. If each run of algo 1 takes 10 seconds and each run of algo 2 takes 1ms, 10 attempts of algo 1 can require fewer attempts and still take longer than algo 2 to find a collision. – Corbin Sep 11 '11 at 04:48
  • @sanmai: I think you are wrong, because many people use same passwords for different services and this is the only information you can not get from somewhere else (if you know someone, you know his name, email address, cellphone number etc., but the password is not something you share - at least not in "my neighbourhood"). If someone has copy of my database, this is not so worrying as if someone knew how to extract passwords from it (even if he still would need the access to the database, because that would mean you really suck at security). – Tadeck Sep 11 '11 at 05:34
  • @tadeck an ecommerce site database usually contains assorted credit card numbers and alike. You should be much more worried of this kind of data but salt-hashed passwords *if someone manages to copy your database*. – sanmai Sep 11 '11 at 08:08
  • 1
    @sanmai: First of all we were speaking about websites in general, but you said "_ability to crack users' password is least of your problems_" and did not limit it to ecommerce websites (or websites that contain eg. secret data of the company that should not be placed on the web server). And for your information: even if ecommerce websites you usually do not need to store credit card numbers, for god's sake. In Paypal you need it only if you have recurring payments, as far as I remember. – Tadeck Sep 11 '11 at 20:29
1

For Brute Attack you can use google's captcha..

And for code password you can use first md5 and second sha1 because md5 generating 32 characters data sha1 64.. :)

Yusuf ali
  • 331
  • 1
  • 6
  • 15
0

Your snippet seems secure. You want to protect against rainbow table attacks, so the double-encryption is a good idea. The computing power to even generate a list of MD5 hashes of SHA1 plaintext is huge, but it's still no harm to have the salt there to protect against such an attack.

bcoughlan
  • 25,987
  • 18
  • 90
  • 141
0

There is no need to reinvent a wheel as there is a crypt function.

// generate MD5-hashed password with salt
$password = crypt('mypassword');
// password contains string(34) "$1$bkZO1nIl$y5bzPPwByq.9tYEb64k4e0"

See examples for different types of hashes including MD5 and SHA256 in the manual: http://php.net/manual/en/function.crypt.php

I this is not enough, there are alternatives:

Keep in mind that if someone was able to lay his hand on your database, his ability to crack users' passwords will be least of your problems.

Community
  • 1
  • 1
sanmai
  • 29,083
  • 12
  • 64
  • 76