1

How do I make passwords more secure, my current code is:

<?php

if(!empty($_POST['userPass']))
    #secure pass
    $newRequesterPass = mysql_real_escape_string($_POST['userPass']);
    $static_salt = 'M0AaE|}{<}|{&*@^AhEQ'; 
    $dynamic_salt = mt_rand(); 
    $newRequesterPass = sha1($dynamic_salt . $newRequesterPass . $static_salt);

?>

Is there a way to make this more secure, without sacrificing a ton of resources?

Like through SHA512, or another method?

Jared Farrish
  • 46,034
  • 16
  • 88
  • 98
meow
  • 95
  • 1
  • 2
  • 9

5 Answers5

2

You can change the algorithm to use SHA512 or Blowfish.

See http://php.net/manual/en/function.crypt.php

You could also look at generating a unique salt per user when they create their account (or update their password), which would limit the risk to a single account if the salt is discovered.

hafichuk
  • 8,680
  • 9
  • 32
  • 52
1

Using hash_hmac is better than plain hashing (md5/sha etc).

http://php.net/manual/en/function.hash-hmac.php

Although I dont understand your use of $dynamic_salt. If you generate a new salt each time, how is it going to match up with the password in the database.

..

Ok, so if the dynamic salt is stored per user....

$newRequesterPass = hash_hmac('sha256', $newRequesterPass, $dynamic_salt.$static_salt);
barryhunter
  • 20,390
  • 3
  • 27
  • 42
  • Or is this when you store the hashed password in the database - ie you store the dynamic salt with the user record? – barryhunter Nov 05 '11 at 00:00
  • store that dynamic salt with the user... then use once login. Is that anymore secure? – meow Nov 05 '11 at 00:04
  • Well 'secure' is always relative... There is probably no such thing as totally secure. But storing the salt with the user, is common practice. Having different salts for each user, makes brute force attacts against a comprimised database much harder. – barryhunter Nov 05 '11 at 00:24
  • @barryhunter The purpose of adding the dynamic salt is to add more entropy to the password. It stops the use of rainbow tables. – hafichuk Nov 05 '11 at 03:34
  • I didmt realise the code was storing the password for the first time. genereting a changing salt when checking the password would of been nonsence – barryhunter Nov 05 '11 at 12:13
1

In addition to the excellent suggestion to use a stronger hash, secure password management involves management code that does more than store the password in salted+hashed form. How much of this you do depends on the business needs of your application, but consider the following:

  1. Password validation -- you may want to enforce certain characters (e.g. letter + number, upper + lower case, etc.

  2. Multiple hashes -- e.g. hash the password 1000 times -- OK this may violate your "not a lot of resources" condition :)

  3. Expiration -- Passwords should be set to expire at some time (e.g. 1 year), so that you want to warn your users to change their password before then (e.g. 10 months) right after they successfully login.

  4. Channel handling -- obviously the password should be sent via an SSL channel and not in the clear. Do not rely on client javascript to secure the password. But you should do more than just POST the password via https, the entire login sequence needs to be conducted in https.

  5. Forgot password policy. Do not send them the password in the clear via email. Send them a link to reset their password and use an offline confirmation channel (e.g. send a follow up email notifying them that their password has been changed).

Take a look here https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet

UPDATE: Just to be clear, don't try to roll your own tools for session management or password hashing. Use the standard tools unless you are a real expert.

rsj
  • 778
  • 3
  • 10
  • Thanks Rsj! Amazing depth in reply! – meow Nov 05 '11 at 00:00
  • How does hashing a password 1000 times make it "more secure"? – Jared Farrish Nov 05 '11 at 00:00
  • @JaredFarrish I don't necessarily condone this, but http://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once – Bailey Parker Nov 05 '11 at 00:06
  • It makes dictionary attacks more expensive (computationally). Now you may think that is the job of salt, but at the level of the host, the salt is public info. Salt defends against an attacker hashing a dictionary once and then searching for the hash among many different hosts. Multiple hashes of the same password defend against an attacker hashing a dictionary once against the same host. Whether or not this is a legitimate threat depends on your application environment. For purely online attacks, who cannot read your salt, it's not necessary. – rsj Nov 05 '11 at 00:08
  • @PhpMyCoder - Iterative hashing has always felt a bit like a crutch. I believe that Schneier (who authored blowfish) is right when he says rely on proven techniques. Recalculating a hash from a plaintext poker may be expensive, but that doesn't mean some other method can't shortcut that "protection". – Jared Farrish Nov 05 '11 at 00:14
  • @rsj - There are potentially better ways to handle dictionary attacks than iterative hashing. Most of them involve detecting DDoS-type requests, but if you are facing such a challenge, you probably have different issues. If you've been compromised and your database downloaded, you face other concerns. Rehashing to such a depth seems unnecessary IMO. – Jared Farrish Nov 05 '11 at 00:17
  • Iterative hashing is part of PKCSv5 as well as RFC 2898. It is not an "ad hoc" random thing. Now, having said that, like any tool it is appropriate in some contexts but not others. You can argue that for an online service, the salt is secret and there is no need for IH, etc., but I don't think you can argue that IH is less "proven" than any other standard technique. – rsj Nov 05 '11 at 00:19
  • @rsj - Do you have any links? I'd be interesting in reading more. `:)` – Jared Farrish Nov 05 '11 at 00:21
  • @JaredFarrish: Look here: http://tools.ietf.org/html/rfc2898 http://en.wikipedia.org/wiki/PBKDF2 http://www.rsa.com/rsalabs/node.asp?id=2127 Most modern OS's use some form of iterative hashing. Again, I just listed different techniques to be aware of, and was not requiring that the OP use all the techniques blindly. But they should *consider* all the techniques and use the appropriate ones. – rsj Nov 05 '11 at 00:21
  • @rsj - Your link didn't make it in the comment. – Jared Farrish Nov 05 '11 at 00:22
  • @JaredFarrish yes, fixed now. – rsj Nov 05 '11 at 00:25
  • @rsj - I will quote from your first link: **4.2 Iteration Count** - *An iteration count has traditionally served the purpose of increasing the cost of producing keys from a password, thereby also increasing the difficulty of attack. For the methods in this document, a minimum of 1000 iterations is recommended. This will increase the cost of exhaustive search for passwords significantly, without a noticeable impact in the cost of deriving individual keys.* – Jared Farrish Nov 05 '11 at 00:28
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/4733/discussion-between-rsj-and-jared-farrish) – rsj Nov 05 '11 at 00:29
0

md5() - Calculate the md5 hash of a string

hash() - Generate a hash value (message digest)

uniqid() - Generate a unique ID

Added :

sha1() — Calculate the sha1 hash of a string

Just see http://php.net/manual/en/function.crypt.php

Mob
  • 10,435
  • 6
  • 37
  • 57
0

What you've goth there, is just "security by obscurity" - a very complicated way of creating a password hash.

If you are at all bothered about people compromising your database and cracking the hashes, you should use bcrypt.

If you're not, then use something standard (md5 is popular) - this provides only superficial protection against cracking.

Note that someone would need to compromise your database to be able to do dictionary or brute-force attacks in this way.

I strongly recommend that you don't "invent" cryptographic algorithms yourself, it is very difficult to get them right (or at least, make them secure).

MarkR
  • 59,334
  • 14
  • 109
  • 144