3
hash('sha512', $_POST['password'] . time())

I have heard alot of things about this and that and can't come to a conclusion...

carlgcoder
  • 229
  • 1
  • 3
  • 10
  • 1
    It's not realistic to talk about security unless you tell us everything about how you use the calculated hash. – Jon Aug 26 '11 at 06:54
  • Just a simple login/signup project I am working on in wamp, it is the password that the user logs in with, I am salting with a timestamp – carlgcoder Aug 26 '11 at 06:56

3 Answers3

5

I suggest added a salt when creating and hashing passwords, other then that - yes.

Wesley van Opdorp
  • 14,888
  • 4
  • 41
  • 59
4

You're using time() as a salt. You can do that, but don't forget to store it (otherwise, how would you ever be able to check that the given password concatenated with the salt matches the stored hash?). sha512 is a great choice for a hash algorithm. I'd suggest

$salt = uniqid('carlgcoder_') . microtime(true);
$hash = hash('sha512', $salt . $_POST['password']);
Community
  • 1
  • 1
phihag
  • 278,196
  • 72
  • 453
  • 469
  • Is this a static salt and a random one together?? I wondered about this, would this be of benefit?? – carlgcoder Aug 26 '11 at 07:05
  • Ok cool, thanks for your help, I am going to stick with what I had, and add in a static salt as well... would the static salt be better stored as a global variable or within the actual hash itself like your example?? – – carlgcoder Aug 26 '11 at 07:10
  • @carlgcoder This salt contains a static part and a variable one. (The time is not random). The dynamic part makes every salt unique - if two salts for different users were the same, an attacker could find out both passwords in one run. Also, it contains a (less important) static component to make sure a hypothetical attacker who would create tables for all possible values of `microtime` and `uniqid` would *still* have to customize his tables for your project. – phihag Aug 26 '11 at 07:14
  • @carlgcoder The static part is not that important. I'd say just put a constant string in there, to avoid the far more likely possibility of a malconfiguration somehow breaking your hashing. – phihag Aug 26 '11 at 07:15
  • Ok thanks, I now understand why it is good to use a static, and a variable salt in conjunction, thanks alot phihag, happy coding :) – carlgcoder Aug 26 '11 at 07:23
0

Use salt. Sample:

<?php
    $passwordWasSavedInDB = md5($_POST['password']."_paranoia_")
TROODON
  • 1,175
  • 1
  • 9
  • 17
  • ...but better not to use the same salt for everything, and sha512 is better than md5, so what the original poster had is better than your answer – David_001 Aug 26 '11 at 06:59
  • He *is* using a salt, and it's way better than the constant string you're proposing. Also, why in the world would you prefer MD5 over SHA512? – phihag Aug 26 '11 at 06:59
  • never use a static salt - use something created from other information of the user. – ty812 Aug 26 '11 at 06:59
  • MD5 for sample, count of md5 chars is 3, faster writing :). Time for salt is not good. – TROODON Aug 26 '11 at 07:02
  • what about a random salt, and a static one @phihag ?? – carlgcoder Aug 26 '11 at 07:04
  • If this hash not use for save in DB, and is was just token-style auth, time and random hash is good. But for save in DB save hash _with_time_ is big error. – TROODON Aug 26 '11 at 07:06
  • @carlgcoder It is a good idea to have a specific static component in your salt, for example your site name or so. That way, even if someone would create tables for all common salts, they'd still have to customize their tables for you. The salt should also be unique for each entry (not necessarily random). – phihag Aug 26 '11 at 07:07
  • Ok cool, thanks for your help, I am going to stick with what I had, and add in a static salt as well... would the static salt be better stored as a global variable or within the actual hash itself like your example?? – carlgcoder Aug 26 '11 at 07:10