To encrypt or not to encrypt...
Moderator: General Moderators
To encrypt or not to encrypt...
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.
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.
Ok, that's a good point.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.
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?Also, while does the cookie include the password in the first place?
Well the way I would do a persistent cookie would be
For more details see
viewtopic.php?t=3190
Code: Select all
$cookieVal="$username+$expTime";
$cookieVal.="+".MD5($cookieVal . $server_secret);viewtopic.php?t=3190
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?
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?
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: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.
Code: Select all
val=nielsene+456433+SFjkh7ufdSdi87asdfSfdgdSHA1 from the mcrypt library is a better hash than MD5, but otherwise MD5 is still pretty darn good.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?
- hhfbrouwer
- Forum Newbie
- Posts: 4
- Joined: Wed Jun 25, 2003 4:50 am
- Contact:
Sessions?
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.
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?
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.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.
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.
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.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.
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...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