I have an authentication form and for 'remember me' functionality, I want to use cookies which will store username and password.
Here is my question - If I want to keep a cookie for a month, will it be a good idea to store password inside cookie ? Can someone see cookie values and edit them using cookie manager etc tools ? How wise would it be to store passwords in cookies ?
Please suggest. Thanks in advance.
Cookies can easily be viewed and modified by users, for example by the Chrome extension EditThisCookie. Therefore, storing passwords in cookies is probably not a good idea.
You could encrypt the cookie using a server key that is somehow affected by the user name. You would have a base key for cookie encryption/decryption and then maybe salt it with the username stored. Crypto operations would obviously have to be performed on the server.
Probably better is storing a session key in the cookie, still encrypted to prevent theft of cookies from allowing the thief to log in. Have the session key include some information about the user-agent and whatever other info the browser supplies, maybe. Of course, you'll have to keep a table of valid session keys on the server.
Related
The offical documentation states the following about deleting a users cookie:
Link
DELETE /_session
Closes user’s session by instructing the browser to clear the cookie. This does not invalidate the session from the server’s perspective, as there is no way to do this because CouchDB cookies are stateless. This means calling this endpoint is purely optional from a client perspective, and it does not protect against theft of a session cookie.
I can invalidate the cookie on the client but what if somebody siphons the AuthSession=123abc and uses it on the quiet? Isn't this a security problem?
I would like to know how I can avoid this behavior and really destroy the cookie because I would like to have a somewhat secure application with CouchDB.
I'm certain I've answered this question before, but I can't find the duplicate question, so here goes again:
The cookie is a simple hash of the user's login name, the time the cookie was created, the user's password salt, and the server's secret.
This means that to invalidate an existing cookie, you must either wait for enough time to pass that the created timestamp is far enough in the past that the cookie is not considered valid, or change one of the other parts of the hash.
In effect, this typically means it's impossible, because:
Changing the user name means the user will no longer be able to log in.
Changing the user's password salt will also mean the user can no longer log in, unless you also store the user's plaintext password, so that their password hash can be re-calculated. (probably a very bad idea)
Changing the server secret will render all sessions invalid for all users, not just the one you're targeting.
If invalidating active sessions is a hard requirement of your application, it's best done in a reverse proxy server that handles authentication, and uses proxy authentication to interact with CouchDB.
Making a login script and I have the following cookies right now :
This is on every page, but expires on browser close.
session_name('Test_Login');
session_set_cookie_params(0, '/', '.test.com', false, false);
session_start();
This is stores the username if a successful login happens. When returning to the site it will fill out the username in the login form.
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.
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 and creates the user session variables again.
setcookie('Test_Pass', $_POST['password'], time()+24*60*60, '/', '.test.com', false, false);
Other things to consider are if you log out the session pass cookie is 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 be useable in this fashion? What is the standard of doing so? Basically I just want this to act 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?
You shouldn't store the password in a cookie it's not a good practice and can lead to security issues (somebody could "steal" the cookie for example and get the user password).
Instead, once the user has been correctly authenticated once, you could save the sessionId in a cookie and on next visit the sessionId will be passed to the server which will be able to retrieve the session. For additional security store the IP address too and check that it is the same when reopening the session. You could also make your server sessions expire after 2 weeks for example.
To do this you need to use a cookie, not a session cookie (which is deleted once the browser is closed).
Check session_set_cookie_params() and give session cookie a lifetime.
See the PHP manual for more info: http://www.php.net/manual/en/session.configuration.php#ini.session.cookie-lifetime
In the end, if you really want more security, you should definitely have a look at SSL.
You should use session variables instead of storing the data in a cookie.
Here's an example in PHP
<?php
session_start();
$_SESSION['password'] = 'YOUR PASSWORD HERE';
//then you can reference the session variable in your code
echo $_SESSION['password'];
?>
You can set how long the sessions will stay for and the user cannot directly access the session variables because they are stored on the server. This is the way many secure login system works.
Multiple sources have pointed to http://jaspan.com/improved_persistent_login_cookie_best_practice as the best practice for my purposes.
I have a login form on which there is an option "Keep me sign in" in. If user check this option and press the login button. Then i think i can save the username and password in a cookie and send it to user computer. Then when user open the site again , i can check whether that cookie is present in user computer or not , if it is then get the username and password from the cookie and sign in the user. But the problem is how can i send cookie to the user computer? As far as i know. You can set the cookie in that way
Cookie userCookie = new Cookie("userCookie", "loginUser");
//sessionCookie.setMaxAge(60 * 15);
userCookie.setPath("/");
httpServletResponse.addCookie(userCookie);
If i don't set the setMaxAge then it's a browser level cookie, i.e., when user closes the browser then the cookie will be deleted. How can i send that cookie to user computer and get from the user computer to automatically sign in?
Thanks
Either way, you should never, never, NEVER store the password in a cookie!
Here is a nice article about persitent cookies : Persistent Login Cookie Best Practice http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/
The essentials from the article:
Premises
Cookies are vulnerable. Between common browser cookie-theft
vulnerabilities and cross-site scripting attacks, we must accept that
cookies are not safe
Persistent login cookies are on their own sufficient authentication to access a website. They are the equivalent of both a valid username and password rolled into one
Users reuse passwords. Hence, any login cookie from which you can recover the user's password holds significantly more potential for harm than one from which you can not
Binding persistent cookies to a particular IP address makes them not particularly persistent in many common cases
A user may wish to have persistent cookies on multiple web browsers on different machines simultaneously
The author suggests to associate the username with a large random number, which is a common practice.
When setting Cookiee on the server with properties(httpOnly and secure=true), does that mean it will only be secured during the communication beween server and client, but not after that?
In other words, if the value was originally in plainText -will it also be stored on the client side with plainText (after traveling with https ) -making it unsafe/vulnerable?
1) Do passwords needs to be always encrypt befors sending (even when using https)?
2) Where is httpCookiee (with secure=true) stored? and is this storage access is protected?
You probably don't want store the password.
What you need is store some "user is already authenticated" flag.
After all, you should learn about "digest access authentification". Storing hashed data is always plus.
This answer is too short, mainly bacause here is too much possibilities - and too much open questions.
Handling returning users:
You can manage (server side) an session database. in the cookie you storing only session ID. when the user authenticate itself, you're store into your server side database his status: "logged in". when he log out, you change in the DB status: "logged off".
Handling returning users has nothing with "storing passwords" in any way. You for example can authenticate users by external auth-services, like open-id, twitter, facebook etc., you're only storing his status by some session-ID or similar.
Browsers usually can store user-names/passwords, but this all time should be the user responsibility. When the user want only remeber his passwords, you should not store it in any way.
Why you want complicating your app and security mechanisms with storing encrypted passwords in cookies - what is not a correct solution - from any point of view?
Simple flow:
When an new user comes to your site - you assign him an new session-ID and store the SID into a cookie
when he login (via https) - you're store in your DB = "sessionID" -> "logged in"
when he return after a week, you can (server side) either accept his session-ID from the cookie - and from DB you can get his "logged-in" status, or, you can force login him once again (for example because of expiration)
all of the above is without any risk storing passwords in any way
1) I think so. Because even with secure flag, cookie will be stored in browser cache in plain text
2) It depends on browsers and OS. For Safari in Mac, you can find it in your ~/Library/Cookies/Cookies.plist You can see cookies with Secure flag but in plain text. It may be protected so only owner can see, but it never be good idea to have plain password anywhere in your computer
Once the secure flag is set to true, the cookie will be stored encrypted in the client even after the browser is closed. As you say it is unsafe/vulnerable.
Resp. 1)
Passwords can be encrypted before sending using Javascript, but it doesn't make much sense because https is doing the encryption for you.
Resp. 2)
The cookies are stored in the browser folder. Anybody can open the folder and see the cookies with a text editor.
The browser will handle the passwords for you. Just using a <input type="password"> and using SSL is secure enough.
And, avoid at all costs storing passwords in cookies.
i was doing some security auditing using SSLSTRIP and the client had their password saved in a cookie, which got me thinking. So I on my account logged into YouTube and grabbed the LOGIN INFO cookie. For the benefit of my privacy i have censored part of the contents, just know that * represents one censored number. This was the contents:
decee*****d0200a8c3f**f1bd2dea**c40AAAB7IjEiOiAxLCAiMyI*IDY0MDYzMjY0MywgIjIiOiAiSjVRRFdmUDR5ZFA1VjZZZHVvNUlldz**IiwgIjUiOiA*NTAzNjAxNzY2NDY1NTM2LCAiNCI6ICJHQUlBIiwgIjciOiAxMzE0ODM1MjI5LCAiNiI6IGZhbHNlLCAiOCI6IDI5NzEwMTU4Njg1N**
I was wondering what type of hash this is, and if it is possible to decrypt? Just some plain old curiosity here, thanks for any replies or thoughts!
Youtube does not store user credentials in a cookie, that "hash" is probably just a random string used as session id, so there is no way you could "decrypt" the username/password from that string.
Cookies should never be used for storing any login credentials. That cookie probably contains some session information that is checked on server side.