This question already has answers here:
Secure hash and salt for PHP passwords
(14 answers)
Closed 9 years ago.
I've got a little question here because I'm creating a log in and register system. A developer at my school told me to salt secure passwords. I agree on that point but he said I needed to create the salt out of a timestamp but how to do it? Currently I'm doin' this:
$password = hash('sha512', $password . $salt);
and the salt just like:
$salt = "xHkosbGhsfT77239GhsvH";
This stands litteraly in my configuration so it's not good...
Does anyone have some tips? Any idea how to do it, so if any of you do share it with me!
Thanks.
It is better to generate a unique salt for each user and keep them in your user table. So, for password checking, just fetch the user salt from database and use it. It is much safer than using a single salt for hole database.
You can use hash_hmac() function which needs three arguments (See documentation). I use it like this:
hash_hmac('sha512', $password . $salt, SITEKEY);
sha512 is my preferred hash function which generates 128B long strings
$password is user password
$salt is unique string generated for each user and stored in the database in the same row for user
salt is generated as: bin2hex(openssl_random_pseudo_bytes($bits)) (See documentation)
SITEKEY is unique string for each site I make
Related
This question already has answers here:
How does password salt help against a rainbow table attack?
(10 answers)
How can bcrypt have built-in salts?
(5 answers)
Password hashing, salt and storage of hashed values
(4 answers)
Closed 3 months ago.
I am wondering about how password_verify() verifies the hash, I have reviewed the documentation and many answers in StackOverflow, but I didn't get the idea
because, as I understood, this function will compare the hash with entered password after hashing it again, and use the same salt and cost and algorithm,
but the question here: if anyone can separate the salt from the hashed password, then anybody also can try to use rehash and try to match, and the salt will be useless here. Am I right, or what?
The salt have to be generated randomly each time the fonction is used (and it's what this function does, and not accept custom salt anymore).
For example:
<?php
$password = "nothing";
echo password_hash($password, PASSWORD_DEFAULT);
echo PHP_EOL;
echo password_hash($password, PASSWORD_DEFAULT);
Give the response :
$2y$10$mdJRjsoc1vR11SKa2JDyS.qSlxja/a0SUPuXC1NKsRLkzmayKwjku
$2y$10$H2th6dRY/i.xZzXSGxDZ1uaiwZx6s0.FM0NXcBcBQ0E2aNEHCJ57m
It's the same password with differents results.
The hashed password is stored in a database or a file. In this case, an admin system (or someone who's hacked the database) can't say if the same password is used by differents users. Another point, rainbow tables can't be used with hashed password with salt. Only brut force can be done.
Using the same salt for all is not more secure than using simple hash algorytm.
This question already has an answer here:
Trying to understand password_verify PHP
(1 answer)
Closed 5 years ago.
I use PHP's password_hash and bcrypt algorithm to hash my passwords. They are in MySQL database.
password_hash($password, PASSWORD_BCRYPT);
As obvious every hash generated by this function is different. But is it really necessary, to identify user by email/login or something to grab his hash from database and then verify it with PHP's password_verify()?
Is it really necessary to make this query and then check?
I mean, is it possible to check hash before, and after only do query to check if it matches this one in MySQL?
Or something else maybe? I remember years ago I used something like checking inside query, like
WHERE login = $login and pass = PASSWORD($password)
Especially I mean this PASSWORD($password)?
Is there other option than fetch user's hash from Database and then verify this hash with password_verify()?
Yes, it's necessary. You need the unique salt generated during hashing, encoded as part of the hash, to do the comparison. That's also exactly why this algorithm is so strong for password storage.
This question already has answers here:
Secure hash and salt for PHP passwords
(14 answers)
Closed 9 years ago.
In an MVC style web app, what's the best/most secure way of setting up a hashing method that's available globally?
I've just been doing this within my core controller that is extended by the rest of my scaffolding:
class Core{
protected function salt($string=null){
$salt = 'dsjflk32osdjshewy8327rtewyrkjfdhdsgnmbcxvsgfyew3287';
$this->data = md5($salt.$string);
return $this->data;
}
}
Is this good practice, or should I be doing something different?
It depends on what you want to hash. If its just to create a unique identifier for larger/grouped datasets, then you could just use MD5. Using salt isnt realy needed then, but it cant harm you either.
If you want to use it for passwords, dont use a hashing function that is optimized for speed at all, because its not realy secure. For passwords I recommend Bcrypt and this question has a lot of information on why you should use it.
If you need the hashing function to disquise parameters, so they cannot be altered, an md5 hash would be sufficient aswell. Since you need to store the link between the hash and the actual value somewhere, they can try to bruteforce the md5 to change the parameter, but they still can only enter values you allowed and have in your link table.
Look at openwalls phpass
http://www.openwall.com/phpass/
Its used in a lot of open source php projects
This is an alternate solution,
$this->data = crypt($salt.$string);
It's not a good idea to use constant salt in hash. It's wise to use different salt per each hash. For this you can:
Generate random salt and save it next to the hash in db
(better) Password is always connected with some entity in database so you can pick some attribute that won't be changed (its ID or creation date) as a varying part of salt.
Use SHA512 for encryption, MD5 is not secure at all.
Method i use to get it encrypted:
$salt= hash("SHA512", $myconstantvar);
$peper= hash("SHA512", $username);
$pass= hash("SHA512", mypass);
enc_pass= hash("SHA512", $salt.$pass.$peper);
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Improve password hashing with a random salt
Is there a valid security reason to generate random salt, but then store it in the same DB as the password as well as a static salt?
For example:
$hashedPass = crypt($pass, $staticsalt.createRandomSalt());// just an example for sanity
$user->setPass = hashedPass;
$hash->setSalt = createRandomSalt();//assuming same result...
I know the security community recommends using an exisitng column for the hash (like username), but i really don't see a point.
If the DB is hacked, the attacker would get usernames as well...
While if it's in a separate column/table , I can incorporate additional security measures.
If you're generating per-record salts, you HAVE to store the salt along with the hashed password. Otherwise you'll never be able to verify the pw, e.g.
register_user:
$salt = rand_salt();
$pw = 'foo';
$hashed = md5($salt . $pw);
login:
$pw = $_POST['password'];
$hashed = md5($pw); // oops... no salt. can't hash the pw properly anymore.
If your server's been hacked, then it doesn't matter WHICH database the hash, salt, userna mes are spread across - they're going out the door.
But at least with the salt you've made the attacker's job more difficult, because now their script kiddy rainbow tables don't apply anymore. They had have a pregenerated hash for the usual passwords (12345, password, etc...), but not for 2d%##41234xrs12345 or 89yusdf;hjlk2342sdf##password.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Secure hash and salt for PHP passwords
THREE part question:
Which technique I should use to store a password? (sha1, sha256/512, etc.)
What is the ideal size of a salt?
What should i use ?
$passwordHash = hash('ENCRYPTION',$salt . $password);
or
$passwordHash = hash('ENCRYPTION',$password . $salt);
I intend to store forum passwords only. I am not storing bank credentials or any other highly sensitive items. It should be fast and not rocket science.
I used MD5 but since it is known that it is broken, I now use SHA-2
$hash = hash('sha256', $pass); - creates 256 bit hash.
Personally, I'd still go with MD5 - it's very fast and widely implemented.
Although security researchers have found a way to make two blocks of text that result in the same MD5 hash (a "collision attack"), there's no known practical way to create an a block of text that produces a specific hash (a "pre-image attack")
Just make sure that you do have a decent length salt (16 random bytes should be more than enough) to ensure that a hacker can't use "rainbow tables" to reverse your hashes.
In my opinion, you should use SHA512, if availble, as it is one of the strongest hashing algorithms that are availble at the moment.
Regarding salt sizes, I would use one the same size as the hash, as the adds a lot more entropy to the hash. I use the uniqid() function in conjunction with the rand() function
I would use code similar to what is below
<?php
$password = 'password';
//Generate the salt
$salt = hash('sha512',uniqid('',true) . rand());
//Hash our password with the salt
$passwordHash = hash('sha512',$salt . $password);
?>
Any as you state -- it`s not so highly sensitive
Any, but if you want precise number, let it be 32
Any, as the main purpose of the salt is don`t give bad man to determine, whether two passwords are same.
For example I`m a developer of some system and decide to store only login-n-password hash:
user1:qjwhegwqe7865weq786ew7q8
user2:kl21j3kl21j3kl21j3kl12jk
user3:qjwhegwqe7865weq786ew7q8
As you can see, without salt bad man will see, that user1 and user3 have same passwords. That's why salt was invented -- it creates always different hashes. And it's only one it's purpose.