Crypt, Sha1

[Bogey]

Hi all, What to use for password (login)?First I though to use SHA1, but then I read on the world wide web, it is better to use crypt for passwords, cause that is much safer... I have this piece of code:

echo crypt($_SESSION["password"]);

This are the outcomes, of 4 times given password "test": $1$9TpTTJKO$SIQLX/ehQ7TXMuWro23z91$1$uE0uZBIG$v3T8NPe0PK7BxkPwNLQJR1$1$4N0HG4c3$5N4d6w2qIhjTdkh5nmRfz.$1$2sNz44X1$6Ss5qcCsKxYKgZEiKhq0p0 So I get everytime another hash :SHow come? Isn't it possible to use crypt? What can I use BEST for handeling passwords?

[Ingolme]

It shouldn't give different values. Are you sure that $_SESSION['password'] isn't changing? Maybe PHP is adding a random salt to the hash. Try setting the second parameter of the function.

[Bogey]

What u mean with "setting the second parameter"? I am 99% sure, that $_SESSION['password'] isn't changing...

[Bogey]

This is my code: Post erased for safety

[Ingolme]

The crypt() function has two parameters: crypt ( $str , $salt)The second parameter is optional, behaviour if it's omitted depends on the algorithm that's being used:

saltAn optional salt string to base the hashing on. If not provided, the behaviour is defined by the algorithm implementation and can lead to unexpected results.

[Bogey]

Is this something?:

$salt="$1$6testtest";echo crypt($_SESSION["password"], $salt);

The salt can also be something like "doorstep"? What is wise to use as a Salt? all kind of characters? Without the salt I get an echo of 34 characters! (but values change)With the salt I get an echo of 13 characters! (gives same values) I think the more characters, the better? or am I wrong? So:1.) What is better? more or less characters2.) What to use for a $salt?3.) I need the salt for a steady outcome?

[Ingolme]

A salt is what makes your encryption key harder to guess if somebody gets a hold of the encrypted password. You decide what you want to use as a salt, it's just a string. I'm not certain that the salt will give you a steady outcome, but it seems probable. I can't tell all the details for certain because I never use the crypt function, I use a specific algorithm, usually sha1.

[Bogey]

I was using sha1 also, but I came on an article where was told not to use sha1 for password, but use crypt instead (cant find article anymore :S) What u think? more wise to use sha1 instead of crypt?

[Ingolme]

It does seem that sha1 is a bit weak. There's SHA-256 and SHA-512. I don't know what algorithm the crypt() function uses.PHP's manual on SHA-1:

Note: Secure password hashingIt is not recommended to use this function to secure passwords, due to the fast nature of this hashing algorithm. See here for details.

Anyways, using the crypt function, you should add a salt to it.

[Bogey]

Oke, thanks for all your help! I stick with the crypt function for now

[boen_robot]

You might want to use the sha1() function with a custom salt generator, just so that you can observe how the process works.The crypt() function itself is not the real deal. It's the blowfish algorithm, which only since recent versions (5.3) was built into PHP (previously, you'd have it available only if the OS on which PHP was running had it). The blowfish algorithm is designed so that it remains just as hard to crack regardless of the hardware involved, whereas SHA1 and most other algorithms, while hard to crack now will become easier to crack as the speed of computers rises.Crypt is supposed to be used as follows:1. Every time you create a user, generate a random string to use as salt. You can do that using various techniques (I like doing a sha1 from the current time and username, and then extract half of that from an mt_rand offset).2. Hash the submitted password with the randomly generated salt.3. Save the generated hash and the salt.4. Upon login, extract the salt and hash the submitted password with the extracted salt.5. Compare the newly generated hash with the hash stored in the DB, and if they don't match, reject login.

[Bogey]

That is not how I have it now! So a little work for me, to make it so like you explained THNX THNX THNX...!!!

[Bogey]

Can I store salt in the same db and table where the hash is stored? or better use another table and/or db to store the salt?

[boen_robot]

Can I store salt in the same db and table where the hash is stored? or better use another table and/or db to store the salt?

Doesn't matter... if an attacker has gained access to one table, he'll have access to other tables. Besides, the reason for using hashes and salts in the first place is to ensure your passwords are protected after an attacker has somehow gotten access to your DB.For convenience and performance's sake, it's best you store them in the same table.

[Bogey]

OK, clear for me! Thnx

[Bogey]

Breaking my head over this, while having diner and going to family 1.)the salt, can it also be a sha1 form a string with characters like @#$%^.,"'?2.)if someone knows the salt, is there then a possibility, that that someone, somehow extracts the salt from the hash, and then decrypts it to the password? Suposing that someone is a hacking king... or is it just impossible getting the password, no matter what they do?3.)is it usefull/wise to build code in, that checks for bruteforcing? and if it alerts a bruteforce, then block that user (with IPadress or Username) for some time or reset password with mailadres or something...4.)when subject 3.) happens, is it also possible to track where from the attack is coming? (ip-adres or something like that?)

[boen_robot]

1. The manual page at crypt() says the accepted salt must be in the alphabet "./0-9A-Za-z" (i.e. latin letters, numbers, and the symbols "/" and ".").2. Hashes are one-way encryptions. You can't decrypt them back to the original. However, entering the same data as input will always produce the same output hash. If an attacker knows the hash and salt, they can try out passwords, and see if the hash they get matches the hash they have. They'll thus conclude the password they just entered is the actual password. This is in fact why salts are used to begin with - without a randomly generated salt, if two users have the same password, the hashes for their password will be the same, and thus an attacker cracking that one password will know all accounts that use that same password. With a randomly generated salt, an attacker figuring out the password for this one account only affects that unfortunate user he targeted.3. Blocking a user is probably a bad idea, as it will only hurt the legitimate user really. Blocking the IP is possible, and it's probably a good idea, as long as you also unblock the IP after some time.4. IP of the client (cracker or otherwise) is visible from $_SERVER['REMOTE_ADDR'].

[justsomeguy]

For the sake of security, it is better to use a slower, more complex hash function. Instead of SHA-1, use the largest version of the SHA algorithm available, like SHA-512. The hash function supports whatever algorithms are available on the system: http://www.php.net/manual/en/function.hash.php Use multiple hashes. Get your password and salt, combine them however you want, hash that, take that hash and mix it up with the salt again then hash that, repeat several times where you keep hashing the hash. The point is to get your hash algorithm to take a lot of time. If you can come up with a hash technique that takes an entire second to execute, that's great. It adds a little delay when users log in or change their password, but if an attacker can only test 1 password per second instead of hundreds or thousands then it makes a dictionary attack take a lot more time.

[Bogey]

Hmmmzzz.... interesting How can I test, how long it executes?

[justsomeguy]

You can use microtime to time some code. $start = microtime(true); // code here $end = microtime(true); echo 'code took ' . ($end - $start) . ' seconds';

[Bogey]

What about this?:

function check_logged_in(){$start = microtime(true);sleep(1);//my code here$end = microtime(true);echo 'code took ' . ($end - $start) . ' seconds';}

[JamesB]

yeh that will work, but I wouldn't recommend having the sleep() in there, as you only want to measure the time of your code, not any possible overhead of sleep(). you might find it easier to output in milliseconds:

echo 'code took ' . (($end - $start) * 1000) . ' ms';

[Bogey]

I want to measure the time of the code yes, but I want to be the time of the code be around 1sec... (the measurement is only for coding/testing) But I have been thinking of an other way... Not to stretch the time to approx 1sec, but to build in a way to block a bruteforce (see post #16), when doing this, then the extra time isn't necessary, cause when lets say 5 passwords have been tried, then the IP is beïng blocked... So:1.) can I use the sleep() method to extract the runtime?2.) when I build code against bruteforce, is sleep() method still necessary then?

[justsomeguy]

Sleep does nothing to offer any sort of protection other than making the user wait. My point was not to make the user wait, it was to make the calculation of the hash computationally expensive. Using sleep is not computationally expensive. Write a loop that keeps re-hashing the thing a million times and see how long that takes. The point is that if an attacker gets your database and your password algorithm then it should take them a long time to brute force anything. If your algorithm includes a call to sleep, then they just remove it. That's not protection. It's trivial to use SHA-1 on an entire dictionary and check each hash against your database. It takes a whole lot longer if you need to hash each word in the dictionary a million times using SHA-512. But even so, if you're not using a salt then they only need to build their dictionary once. If each password in your database uses a different salt (or, at least a different starting salt) then they have to calculate a different dictionary for each user. Blocking multiple login attemps on your site is one thing, but you also need to make sure you're protected even if your entire database and code gets stolen.

[Bogey]

Thanks for all the help in advance! I am using a different/unique salt for each user... So your advice is to make the hash computationally expensive instead of checking for bruteforcing?What about the serverspeed? supposing there are a lot of users logging in the same time? I guess lot of calculating eats a lot of speed? What you suggest? using SHA-512 instead of crypt?This is how I have it now: 1.) there is made a hash (SHA1) of 2 different unqiue variables (differs on each user) (this is the salt)2.) userpassword together with the salt is being hashed by using crypt3.) hash from 2 stored in DB of user4.) the salt from 1 stored in DB of user5.) When user logs in, then the userpassword will be hashed (crypt) with the salt (point 1) from DB6.) When hash from point 5 is equal to the hash from point 3, then user logs in7.) If point 6 is false, then NO loggin What I want now:If point 6 errors 5 times, then IP is been blocked for 10minIf point 6 errors another 5 times, then IP is blocked for 1 hourIf point 6 errors another 5 times, then hash of password/salt is deleted, and a new confirmation mail has been send to registerd mail-adres, with the info, that mail-adress has been userd, to try to login... and to tell user, another password has to be set...