Safely store password and username in a cookie?
Moderator: General Moderators
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Safely store password and username in a cookie?
Hi,
EDIT: Check my post below, the 3rd post..
EDIT: Check my post below, the 3rd post..
Last edited by kaisellgren on Sat Sep 27, 2008 11:04 am, edited 1 time in total.
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: Safely store password and username in a cookie?
Here is what I have been doing so far. I hope some security gurus could take a look at this.
1) Login form that operates through SSL. The form will never appear if the SSL is not running.
2) Only max 5 login tries per IP or ban for 24 hours.
3) There is a global pepper (random string) in a config file. Then, everytime an accoutn is created, it will get its own salt into the db. So when logging in, this is what happens:
Basically what I am trying to achieve with the above is that the $salt is different for every user, so to get the password you must now the salt (aka have the SQL access). Even if you have the SQL access, you still would need the $pepper which is not in the SQL database, instead in a .php file
is there any problems with this?
4) If the user agent is different than the one in the last successful "logged in" -situation, then log out and ask for a password.
5) If the IP address is different in the first two dots, then log out and ask for a password. This means e.g. IP like 72.72.72.72 can not suddenly change to 72.73.0.0, but can change to 72.72.73.72 though. Also I am providing an extra option to the control panel to change this.
6) When you try to go/use the control panel, it checks if the session is authorized which means it checks the cookie details:
The cookies has a session id of hash('sha512',uniqid(mt_rand(),true)); which was generated when the user logged in successfully last time, so if the last logins generated hash do not match the one in the cookie, then do not allow being logged into the CP.
The cookie also stores the user id.
What am I trying to do: My own session system that keeps the user logged in for x minutes, up to a few hours and it must be fully secure. We are talking about very confidential information here that can be accessed from the CP.
EDIT: I forgot to mention that the session id changes between every reload of an authorized page. Isn't this a good thing? And also there is no way for an attacker for "fix" the id, not through url PHPSESSID= wont work or anything else.
EDIT 2: Some one just told me to use SHA256 instead of MD5. I was going to use SHA512, isn't SHA512 > SHA256? Why was he suggesting 256 instead of 512 :/?
EDIT 3: Looks like I have lots of edits today
Anyway, I got an idea. Since my script is going to be open to public... any attacker will see how the pass is constructed, e.g. $pepper . $salt . $pass or so... so instead of that I would create lets say 10 different mehods for this and in the installation of the script it decides which to use, so even if the attacker knows certain details about my passwords salts or system he would still repeat attacks 10 times more because he cant know which of the pass generation methods the server is using
?
1) Login form that operates through SSL. The form will never appear if the SSL is not running.
2) Only max 5 login tries per IP or ban for 24 hours.
3) There is a global pepper (random string) in a config file. Then, everytime an accoutn is created, it will get its own salt into the db. So when logging in, this is what happens:
Code: Select all
$pass = hash('sha512',$pepper . $password . $salt);4) If the user agent is different than the one in the last successful "logged in" -situation, then log out and ask for a password.
5) If the IP address is different in the first two dots, then log out and ask for a password. This means e.g. IP like 72.72.72.72 can not suddenly change to 72.73.0.0, but can change to 72.72.73.72 though. Also I am providing an extra option to the control panel to change this.
6) When you try to go/use the control panel, it checks if the session is authorized which means it checks the cookie details:
The cookies has a session id of hash('sha512',uniqid(mt_rand(),true)); which was generated when the user logged in successfully last time, so if the last logins generated hash do not match the one in the cookie, then do not allow being logged into the CP.
The cookie also stores the user id.
What am I trying to do: My own session system that keeps the user logged in for x minutes, up to a few hours and it must be fully secure. We are talking about very confidential information here that can be accessed from the CP.
EDIT: I forgot to mention that the session id changes between every reload of an authorized page. Isn't this a good thing? And also there is no way for an attacker for "fix" the id, not through url PHPSESSID= wont work or anything else.
EDIT 2: Some one just told me to use SHA256 instead of MD5. I was going to use SHA512, isn't SHA512 > SHA256? Why was he suggesting 256 instead of 512 :/?
EDIT 3: Looks like I have lots of edits today
Anyway, I got an idea. Since my script is going to be open to public... any attacker will see how the pass is constructed, e.g. $pepper . $salt . $pass or so... so instead of that I would create lets say 10 different mehods for this and in the installation of the script it decides which to use, so even if the attacker knows certain details about my passwords salts or system he would still repeat attacks 10 times more because he cant know which of the pass generation methods the server is using
Re: Safely store password and username in a cookie?
so you want secure "auto-login"?
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: Safely store password and username in a cookie?
You got it :parjan.top wrote:so you want secure "auto-login"?
Re: Safely store password and username in a cookie?
you could try salting it like password:
in the database write uniqid() at login
define $salt in php
then write hash of both in the cookie, that way access to database is not enaugh to "steal" autologin value
the problem is with matching cookie to user, you have to iterate over all users and hash the uniqid (maybe databases can do sha/md5 too, then it would be simpler)
EDIT: looks like mysql can do sha1 and md5
in the database write uniqid() at login
define $salt in php
then write hash of both in the cookie, that way access to database is not enaugh to "steal" autologin value
the problem is with matching cookie to user, you have to iterate over all users and hash the uniqid (maybe databases can do sha/md5 too, then it would be simpler)
EDIT: looks like mysql can do sha1 and md5
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: Safely store password and username in a cookie?
Hm...arjan.top wrote:you could try salting it like password:
in the database write uniqid() at login
define $salt in php
then write hash of both in the cookie, that way access to database is not enaugh to "steal" autologin value
the problem is with matching cookie to user, you have to iterate over all users and hash the uniqid (maybe databases can do sha/md5 too, then it would be simpler)
EDIT: looks like mysql can do sha1 and md5
Do you happen to know a good random number generation for cryptographic use?
Re: Safely store password and username in a cookie?
1. why would you need it?
2. mt_rand() is better than rand(), but as I read not good enaugh for criptography
2. mt_rand() is better than rand(), but as I read not good enaugh for criptography
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: Safely store password and username in a cookie?
Yup, mt_rand() is clearly not enough for cryptography. Do you have any ideas on generating as truly random number as possible? There are lots of problems with mt_rand() if you blindly rely on it for creating secret values such as session ids, passwords, activation links or such.arjan.top wrote:1. why would you need it?
2. mt_rand() is better than rand(), but as I read not good enaugh for criptography
Re: Safely store password and username in a cookie?
maybe Mordred can help
Re: Safely store password and username in a cookie?
uniqid() should be fine, although I am not a cryptologist and don't know the details on its implementation on different systems. It is most certainly better than mt_rand and rand.
The post arjan.top already linked to has my explanation on why there's no sense in using longer hash functions in this case.
The post arjan.top already linked to has my explanation on why there's no sense in using longer hash functions in this case.
Re: Safely store password and username in a cookie?
If the data has to be that secure, I wouldn't use an auto-login feature. Make them enter their password. And using a username that is displayed publicly isn't a good idea for the login either, cuz that's 1/2 of the login equation.
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: Safely store password and username in a cookie?
@scottayy: yup, agree.
It clearly explains how you could get in troubles when you rely on mt_rand() in cryptography. That's why I am wondering, what could be a better way to generate random numbers/values if not mt_rand().
Right now I'm using this function to generate randoms:
It is inspired by Stefan, Wordpress and my brains. I'll surely give credits to guys who have hands in this function, but right now I would like to create a random function that I can use to generate secret "things". Let's say random password, activation link.
I read the Stefan Esser's blog about PHP and not so random numbers, here: http://www.suspekt.org/2008/08/17/mt_sr ... m-numbers/Mordred wrote:uniqid() should be fine, although I am not a cryptologist and don't know the details on its implementation on different systems. It is most certainly better than mt_rand and rand.
The post arjan.top already linked to has my explanation on why there's no sense in using longer hash functions in this case.
It clearly explains how you could get in troubles when you rely on mt_rand() in cryptography. That's why I am wondering, what could be a better way to generate random numbers/values if not mt_rand().
Right now I'm using this function to generate randoms:
Code: Select all
$rnd = '';
$gseed = '';
public function rand2($min = 0,$max = 0)
{
global $rnd,$gseed;
$seed = $gseed;
// Reset $rnd_value after 14 uses
// 32(md5) + 40(sha1) + 40(sha1) / 8 = 14 random numbers from $rnd_value
if ( strlen($rnd_value) < 8 ) {
$rnd_value = md5( uniqid(microtime() . mt_rand(), true ) . $seed );
$rnd_value .= sha1($rnd_value);
$rnd_value .= sha1($rnd_value . $seed);
$seed = md5($seed . $rnd_value);
$gseed = $seed;
}
// Take the first 8 digits for our value
$value = substr($rnd_value, 0, 8);
// Strip the first eight, leaving the remainder for the next call to wp_rand().
$rnd_value = substr($rnd_value, 8);
$value = abs(hexdec($value));
// Reduce the value to be within the min - max range
// 4294967295 = 0xffffffff = max random number
if ( $max != 0 )
$value = $min + (($max - $min + 1) * ($value / (4294967295 + 1)));
return abs(intval($value));
}
echo rand2();