|php cookies for login script - how to remember and auto login|
| 5:50 am on Sep 6, 2013 (gmt 0)|
Making a login script and I have the following cookies right now :
This is on every page, but expires on browser close. It holds user info from the db like id, username, email, last login, last ip, etc.
session_set_cookie_params(0, '/', '.test.com', false, false);
This stores the username if a successful login happens. When returning to the site it will fill out the username in the login form if the cookie is available.
setcookie('Test_User', $_POST['username'], time()+365*24*60*60, '/', '.test.com', false, false);
This remembers the value of the 'remember me' option on the login form - true or false - and fills out the last option they selected (checked or unchecked) on the login form if the cookie is available.
setcookie('Test_Remember', $_POST['rememberMe'], time()+365*24*60*60, '/', '.test.com', false, false);
This stores the user plain text password if they selected the remember me option above and lets them automatically login when visiting the site even after browser close within a day. If this and user cookie are present it checks if valid a valid user in the db and creates the user session variables again and automatically logs in.
setcookie('Test_Pass', $_POST['password'], time()+24*60*60, '/', '.test.com', false, false);
Other things to consider are if you log out the session and pass cookie are destroyed.
My problems :
I md5 and salt the user password for storage in the database. I actually never know the users pass. Problem is with the remember option I am storing their password in plain view in the cookie. What is the best way to store the pass in a cookie and it still be useable in this fashion? I need to be able to do something like encrypt it for cookie storage then decrypt it should I use it so I can md5 and salt to verify against the database. At present in plain view in the cookie it is obviously a security issue lol as anyone could view the cookie and know the pass not to mention people like to reuse their passwords for other things.
What is the standard of doing so? Basically I just want this to act the same as Facebook or any other login system. If you tell it to remember you it does - so how do they store the info to log back in without doing so in plain text in the cookie?
Is it best practice to have a separate cookie (4) for this? The session cookie makes sense, but is there not a more optimized way on my end to combine the other three and therefore give one cookie to the end user?
Newb question I know, but never needed to do any cookie storage like this before. Thanks for any help.
| 10:41 am on Sep 6, 2013 (gmt 0)|
Is this really the best practice for this autologin ability?
In theory it is not that bad, but still allows someone to steal/use the cookie if they have access to it. You would then need to wait for the actual owner to login to know a theft/use of the cookie happened. You then just invalidate the cookie if that happens and reset it. Well, that doesn't flow to well with me as the possibility is still there and who knows when the actual user would login after it has been stolen.
On top of that... for the application I am using there may be multiple people using the same login as well as different computers, ips, etc. So this warning/reset system from above would be triggered all the time.
Unless any of you know a different method I may just stick to NO autologon and if the user closes the browser then they will just have to login again.
[edited by: jatar_k at 3:49 pm (utc) on Sep 11, 2013]
| 2:27 pm on Sep 6, 2013 (gmt 0)|
I think you found the answer: the secret you share with the browser can be reused to connect just as the password could.
A few things:
|I md5 and salt the user password for storage in the database. |
That's a decent start, but not good enough:
- md5 really should not be used anymore - it's broken.
- for storing passwords you really must also use a SLOW hash. md5 (and sha-1, the sha-2 variants etc. are all fast hashes)
Make the hash as costly as you can bear.
A simple sha-1 or md5 is peanuts for the average passwords your users will chose to crack using dictionaries.
setcookie(... false, false)
is a bad choice: you do not limit the browser to send the cookie on on https connections, but it will also send it (in the clear!) on http connections to site(s) in your domain.
Finally, although I guess you have found it by now:
all you need is a single cookie: it's a random value and you store on the server side the user, timeout to log them out etc. If you store such info in the browser a smart attacker will change it...
| 6:36 pm on Sep 6, 2013 (gmt 0)|
Thanks for replying. I had trouble finding good info on the web about this project and those I did it was always an md5/salt. Those other options look much better.
|all you need is a single cookie |
At the moment the only cookies stored on the end-user side is the username, remember option, and pass each in their own.
To be quite honest I think I am going to get rid of the whole autologin option (password cookie) as I just do not see the convenience for users outweighing the security loss in that respect.
So, I would have one for username and one for remember option which would simply enter the last valid username and remember option on the login form. I do not see any security issue with this (possibly the username in plain text, but this is no different than usernames shown in a forum) and the other is just a 0/1. Still a security issue?
Can that user cookie still be combined into one? I did read about serialization for the cookie, but it seemed the extra work with serial/unserial would be more costly then just having two.
I have already changed to all to http only (my own overlook as I am just dev'ing this right now). No ssl on this site at the moment so https isn't possible.
| 8:04 pm on Sep 7, 2013 (gmt 0)|
You just store a long random string -to make it next to impossible to guess- as cookie in the browser. Think of it as a secret.
On the server side you store the username, and any other data you need in a database (can be the session, can be in a database, it's your choice). As long as you get the "secret" you're good to go: you can log them in if they are not, or keep working if they are logged in.
If you log them out and know they should not be auto-logged in you ignore the setting and send them to the login page.
Don't forget to refresh the cookie every so often (they do expire eventually).
If you store somethig like a username in the browser, an attacker can change the username ...
| 8:35 am on Sep 8, 2013 (gmt 0)|
Since my op I have done lots of reading on best practices and other. I have decided, for security reasons, that I will not be using the autologin/remember me option. As of now I require login on every new browser session and all data used for operation will be stored server side in sessions.
I figure if they want to use an autologin feature then they can use an up-to-date browser that will do it for them.
While using the token option is the best is still leaves the ability to steal and use the cookie elsewhere. In the end using a token is really no different than just storing something in plain text with the exception of actually knowing the actual user/pass in terms of security. The link I posted above is the best I could find and even it has its security limitations. For this project I do not want to take that risk.
Thank you for the responses though.
[edited by: jatar_k at 3:47 pm (utc) on Sep 11, 2013]
[edit reason] removed url [/edit]