3

I have a website which have a "remember me" functionality. When someone clicks that functionality it sets the user password and username in a cookie to remember him/her. Okay, fine.

But, that cookie is a HTTPonly cookie (no worry for XSS) with the Secure flag set. Is it enough security in there?

Now that cookie cannot travel in the plain text (as per the secure flag), it cannot be read through javascript (document.cookie). So my opinion is that this implementation is secure enough. But I am curious to know of yours.

  • Enough security for what? What are you trying to defend against? – rink.attendant.6 Dec 1 '17 at 5:17
  • Is it secure to set the passwords when we use the remember me function? – Utkarsh Agrawal Dec 1 '17 at 5:19
  • 7
    There are so many things wrong with storing user credentials in a cookie. Cookies should only store a token to match with a server-side session store as well as non-sensitive data. This article is a good read on how to implement "Remember me": paragonie.com/blog/2015/04/… – rink.attendant.6 Dec 1 '17 at 5:27
  • 1
    Troy Hunt has a blog post explaing what is wrong with this approach and how to do it right: troyhunt.com/how-to-build-and-how-not-to-build – Anders Dec 1 '17 at 9:42
7

There are some problems with this scheme.

  1. You should never store the actual password in the cookie. Store a temporary session token that is associated with the account (on the server) and then you can delete that token when the user logs out. If you're just storing the user's credentials, there's no way to end a session (on the server side) without ending all the sessions (by invalidating the creds).
  2. Storing the password in the cookie means that anybody who gets access to the cookie (for example, another user on the same computer) will always be able to log in as the "remembered" user by looking at those credentials, memorizing them, and taking them to another computer. Session tokens should be long and random, and ideally short-lived.
  3. HttpOnly does NOT provide protection against XSS. It's not even close. All it does is prevent script from reading the cookie. Somebody can still take over the session of the logged-in user's browser, and take any action the user could take, and send the attacker everything that the user can see. In fact, there's an entire exploit framework that explicitly does this, essentially letting the attacker remote-control the victim's browser session. You still need careful XSS protections.
  4. HttpOnly won't protect at all if there's any page that reflects the cookie's values back from the server. An XSS could just read the server's response. In fairness, you didn't say there was any such page, but I just wanted to highlight how threadbare the "protection" of HttpOnly really is. Anything that you think "this wouldn't be secure, except for HttpOnly" is almost certainly not secure even with it.
  • So this is what I want, that shows Httponly can't enough secure. Attacker can still pic the user's cookie by another means? But I really don't know what other means? But I am googling if I fail to find I will come again to ask you. I want to upvoted to but as you know I can't... :p. And thanx for answering. – Utkarsh Agrawal Dec 1 '17 at 8:27
  • Depending on your specific application, you may also want to limit the scope of the cookies using the domain setting, and you may want to limit the lifetime of the cookie. Do you want the cookie to persist forever? – iainpb Dec 1 '17 at 9:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.