Page 1 of 2
To encrypt or not to encrypt...
Posted: Mon Aug 18, 2003 10:39 am
by Swede78
I am planning on creating an "Auto-Login" script for the convenience factor of my site.
My question is whether or not I should encrypt their username/password in the cookie. Quite frankly, I don't really understand the logic in doing so. I will give the user the option of whether or not to do this. So, for those that choose to do this, what's the point of encrypting their username and password. Because, if someone who uses their computer wanted to find out what they are, they could simply go to my site, where they will be automatically logged in, then go and change the user settings.
I don't show the password, but they can change it. There also, isn't any super sensitive information to access, just the user's address.
So, could someone please explain to me why I would bother encrypting their username/password.
Posted: Mon Aug 18, 2003 2:00 pm
by nielsene
Encrypt it. If they are like 95% of computer users they will use the same password on multiple sites. Therefore if a local user can read theirr cookie, they can guess the password for many other sites.
Also, while does the cookie include the password in the first place?
Posted: Mon Aug 18, 2003 2:11 pm
by m3rajk
i agree with eric here.
i have an open username and a second one that's a masked password that i'm going to increase security on by eencrypting once i get things going. i use the pw to check against the db AFTER i bring up the info by the username, just to restrict it to the user with that username
Posted: Mon Aug 18, 2003 2:15 pm
by patrikG
Also, IE had a nasty bug that allowed any website to read any cookie on someone's computer. Encryption is the way to go.
Posted: Mon Aug 18, 2003 3:01 pm
by Swede78
Encrypt it. If they are like 95% of computer users they will use the same password on multiple sites. Therefore if a local user can read theirr cookie, they can guess the password for many other sites.
Ok, that's a good point.
Also, while does the cookie include the password in the first place?
The way I authenticate users now, is to check their username and password against the DB. I guess I can assume that if they have a cookie that I created with an encrypted username, that they must be the right person. Which is more insecure... assuming that, or including an encrypted password?
Posted: Mon Aug 18, 2003 8:49 pm
by nielsene
Well the way I would do a persistent cookie would be
Code: Select all
$cookieVal="$username+$expTime";
$cookieVal.="+".MD5($cookieVal . $server_secret);
For more details see
viewtopic.php?t=3190
Posted: Tue Aug 19, 2003 10:30 am
by Swede78
That's interesting. I'm curious, why do you include a plaintext username and expiration time in the value? I guess I can see why you might include the username. That way if they change it, it won't match the encrypted one. But, if you don't have a plaintext version in the value in the first place, then there would be nothing for them to try to alter.
Another question... I installed MCrypt a while back. From my understanding, it's a more fool-proof way of encypting than the MD5 method. Would there be a reason that I should use MD5 instead of MCrypt?
Posted: Tue Aug 19, 2003 10:33 am
by m3rajk
md5 hashing masks it so it looks like gibberish. if they don't know that you're using md5 they can't change anything and come up with something.
md5 is one-way
mcrypt is two way. they can hack and find you encryption/decryption keys
Posted: Tue Aug 19, 2003 10:35 am
by Swede78
sorry, nielsene... didn't see your link at first. - thought it was part of your signature.

Posted: Tue Aug 19, 2003 11:10 am
by nielsene
Swede78 wrote:That's interesting. I'm curious, why do you include a plaintext username and expiration time in the value? I guess I can see why you might include the username. That way if they change it, it won't match the encrypted one. But, if you don't have a plaintext version in the value in the first place, then there would be nothing for them to try to alter.
Usernames tend to be public information. Therefore I don't mind exposing that in plaintext in the cookie. Furthermore some paranoid privacy people get upset when they see entirely encrypted cookies. These cookie values will end up looking like:
Code: Select all
val=nielsene+456433+SFjkh7ufdSdi87asdfSfdgd
(or something like that.) And yes you need both the MAC'd and the plaintext username to be able to test for tampering. You could also then mcrypt the entire cookie value with a
different server secret to hide the whole thing. The order should alwasy be MAC, encrypt -- decrypt, check MAC. Inverting that order can cause vulnerabilities to appear.
Another question... I installed MCrypt a while back. From my understanding, it's a more fool-proof way of encypting than the MD5 method. Would there be a reason that I should use MD5 instead of MCrypt?
SHA1 from the mcrypt library is a better hash than MD5, but otherwise MD5 is still pretty darn good.
Sessions?
Posted: Tue Aug 19, 2003 3:26 pm
by hhfbrouwer
I would use sessions.
A simple variable like $_SESSION['login'] = "loggedin", set when the user has succesfully, could do.
As far as I know that is safe enough.
Also one comment: I would always ask for the old password when the user wants to change it.
Re: Sessions?
Posted: Tue Aug 19, 2003 4:26 pm
by nielsene
hhfbrouwer wrote:I would use sessions.
A simple variable like $_SESSION['login'] = "loggedin", set when the user has succesfully, could do.
As far as I know that is safe enough.
Also one comment: I would always ask for the old password when the user wants to change it.
Sessions can not implement an "auto-login" functionality. Furthermore the critical session id is not protected well in the default PHP setup, so session hijacking is trivial. Yes sessions are great and I use them all the time, but they are not perfect.
Posted: Wed Aug 20, 2003 9:51 am
by Swede78
Nielsene,
I think your code will help me out a great deal to create a good solid auto-login script. Thanks for replying!
One last question... I always try to make my site as effecient as possible. I assume that most people who implement an auto-login script, do so on every possible entry-page, which is most likely what I'll do. I figure that I'll first check to see if they're already logged-in, if not I'll call up the script. But, if they are not logged in and do not have an "auto-login" cookie, will this code bog down the site if it's being called every page hit?
Thanks again for the help.
Posted: Wed Aug 20, 2003 10:12 am
by nielsene
Swede78 wrote:Nielsene,
I think your code will help me out a great deal to create a good solid auto-login script. Thanks for replying!
One last question... I always try to make my site as effecient as possible. I assume that most people who implement an auto-login script, do so on every possible entry-page, which is most likely what I'll do. I figure that I'll first check to see if they're already logged-in, if not I'll call up the script. But, if they are not logged in and do not have an "auto-login" cookie, will this code bog down the site if it's being called every page hit?
Thanks again for the help.
Well any cryptographic stuff will always impose a computational burden on the server, but that's more for checking the hash. The overhead that checks 1) user not logged in and 2) user doesn't have a cookie is trivial and won't bog things down, so I beleive this method should be safe.
Posted: Wed Aug 20, 2003 11:02 am
by Jay
m3rajk wrote:md5 hashing masks it so it looks like gibberish. if they don't know that you're using md5 they can't change anything and come up with something.
md5 is one-way
mcrypt is two way. they can hack and find you encryption/decryption keys
I don't understand your logic, if you've been hacked, your encryption keys are not the only things compromised. I would guess everything else is too...