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.
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 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
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Secure hash and salt for PHP passwords
Iv'e read a lot of posts both in stackoverflow and other websites talking about web security. Such as salting encrypting etc. And I'm kinda not getting it so a simple explanation would be really helpful.
So here's what I know so far. A user logs in types his username and password. The input then goes through a process. Lets say the username and password is combined like for example:
$username = (USERS USERNAME INPUT);
$password = (USERS PASSWORD INPUT);
$userinput = $username . $password;
Then we add some salt.
$salt1 = "13$13aVc!kd";
$salt2 = "4kr$!vlmeoc";
$salted = $salt1 . $userinput . $salt2;
Then we encrypt it.
$encrypted = encrypt($salted);
Then check with the database and if its right user gets logged in.
That's how it works right? But Iv'e read about brute force attack. It guesses the input values right? With the procedure above. Doesn't it shows that the attacker only needs to get the $userinput information correct to get in? He doesn't need to guess the long $encrypted string correct?
Note: Lets say in this situation there's no captcha, no number of tries limit, no lockout, nothing else but the one above.
Note: Be gentle I'm still learning.
If you rule out captchas, try limits, lockouts, et cetera... then yes. You just have to brute force the plain text string.
However, that does take time - at the very least, it's bounded by the rate at which the server will respond to login requests. Even if the developer doesn't add any measures to prevent brute forcing, the server itself can only go through the encryption + verification process so quickly, and can only handle so many parallel requests.
That said, this is why it's important to
As a user, use a strong, hard to brute-force password
As a developer, have adequate measures to prevent brute-forcing of your login process
Hashing and salting passwords isn't to protect against people who brute force the natural login process (there are other things that protect against that). Instead, they're to protect against potential compromise of the password storage itself (e.g. someone dumping the contents of the database).
Both hashing and salting serve to decrease the speed at which someone with access to the stored passwords can retrieve the plain text string they'd need to be able to go through the natural login process (of your site or other sites, given that passwords are commonly shared between sites) without tripping anti-brute-forcing security measures.
The idea of hashing and salting is more to prevent someone from taking user passwords if the database itself is compromised. If the passwords are stored as salted and hashed strings, the attacker can't just use them to access a user's account on another site.
Password encryption is one-way encryption (or rather its suppose to be in a secure site). That is to say you take the password and you make a hash form it. bcrypt for example is the acceptable standard for doing this today.
If its one-way encryption a lot of people wonder how it can check a password. But you just hash the password the user submits and compare it to what hash you stored in the database. This way if your database is stolen an attacker has to work a lot harder.
The problem with just hashing a password is easily brute forced or rainbow tabled. You can google rainbow table to learn more on that. But essentially its a way to turn these hashes back into passwords.
Enter salting. Salting is adding random data essentially to every password. This trumps rainbow tables. Meaning a compromised database will mean brute force. Which if you're using a hash system like bcrypt takes a lot of time and effort for the attacked.
Having said all that. Best not to reinvent the wheel. Just use a known good authorization system if you can.
See my answer here
And you should generate unique salts for each entry when you create the hash.
One problem with brute force attacks is when you use a fast encryption like SHA1 or MD5. These functions are build to run the password through an algorithm fast. Instead you could use the Blowfish method, which im no expert on, but long story short it takes more calculation for a returned value, than SHA1 or MD5. This means it may take 5 years to brute force a password, hashed with Blowfish because of calculation time.
The next example is made with SHA1 and MD5, so it's vulnerable to bruteforce attacks, however the salt part should be OK to use:
$salt = md5(microtime().uniqueid());
This will output a unique 32 charecter salt, which you will put together with the password.
$passwod = $_POST['password'];
$hashed_password = sha1($password.$salt);
Now you have to store both the password and the salt in the database. And when you check the user inputtet password you get the salt, and hash the whole thing.
$temp_pass = $_POST['temp_pass'];
$salt = //from database;
$database_pass = //hashed pass from database;
$hashed_temp_pass = sha1($temp_pass.$salt);
if(hashed_temp_pass == $database_pass){
//Welcome user!
}
else{
//go away
}
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.
Basically, what I'm asking is if salting a password by appending a hashed version of it to the end of it is just as secure as salting with a different string. So:
Is this:
$pass = "pass";
$salt = sha1(md5($pass));
$pass = md5($pass.$salt);
As secure as this?
$pass = "pass";
$salt = "4D9ds*^dkrUI45^#dkd*3fD8&!dlvd*";
$pass = md5($pass.$salt);
If the salt is based on the value to be hashed, then you lose the value of the salt.
If a password hash salt is based only on the value of the password, then two users using the same password is very visible in the database, for example.
You should instead add a salt on a different determinable value. Common options are fields like the username, email, etc.
The first example is as secure as hashing without using any salt at all, because it still just requires the password and nothing more to crack. In other words, you are just applying the hashing functions to the same thing a few times more.
A better bet is still to create a salt for each user and store it alongside, separately. A fixed salt for everyone is alright, I guess, because you cannot use the password to determine the salt. However, generating a unique salt for each user is even better because then it would take more information than just the password to crack it (e.g. username, date registered, or some other info).
You shouldn't use md5 anyway as it's been cracked. sha256 is more secure and just as easy to implement.
How about using, when storing the data:
$salt = mt_rand();
$pass = hash('sha256',$_POST['userPassword'] . $salt);
Therefore $salt is not based on any user entered data, but random data. You then store $salt in the db as it is, or reverse the string for obfuscation.