5

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.

Improve this question
4
  • Enough security for what? What are you trying to defend against? Commented Dec 1, 2017 at 5:17
  • Is it secure to set the passwords when we use the remember me function? Commented Dec 1, 2017 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/… Commented Dec 1, 2017 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 Commented Dec 1, 2017 at 9:42

1 Answer 1

Reset to default
10

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.
Improve this answer
2
  • 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. Commented Dec 1, 2017 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? Commented Dec 1, 2017 at 9:17

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.