Live data from Hacker News

How to build (and how not to build) a secure “remember me” feature

troyhunt.com

31–40 of 65 posts

Re: How to build (and how not to build) a secure “remember me” feature

#31
post #18
post #8

Good article, but one thing is explained in a weird way: Don't bother with cookie expiration. That's the wrong approach, because the cookie is controlled by the user . Always do a server-side check whether or not the auth token in the cookie is allowed to continue the session. So you could simply set the expiration date for a cookie until 2030 but make sure that the auth token from that cookie cannot be used after $E…

Good point, but your explanation is also a bit confusing. If I understand correctly, your point is not so much "don't bother with cookie expiration" as "don't trust cookies to expire when you tell them to". In other words, the server should double-check cookie expiration dates because you don't want somebody fudging your 7-day cookie and using it to log in next year. Am I right?

Technically, the server cannot check cookie expiration dates, because they are never transmitted to the server. Only the cookie content is transmitted.

What I mean is: On the server, you receive an auth token that comes from the cookie. Do the logic whether or not that auth token is valid and may be used to re-authenticate the user on the server only and handle the entire logic for expiration on the server.

Do not rely on the fact that the cookie itself is present, because the user might have fiddled with the expiration date.

Re: How to build (and how not to build) a secure “remember me” feature

#32
Or you can do this:

Client generates random value, puts it into cookie and passes it to server along with valid credentials. Server remebers it for this user and whenever at later time it sees this value in the cookie it logs in this user. Server forgets this value when this user logs out and after some time.

If client does't have javascript or you don't trust randomness it can generate you can create this value on server and make the server set this cookie when it responds to login.

Re: How to build (and how not to build) a secure “remember me” feature

#33

Remembering the username can be pretty useful, especially if you find yourself in a place where you common usernames are taken on other sites and you have to use different usernames in different places.

Being reminded of a username could also be helpful if you have more than one username at a given site - for instance, personal and business accounts for a bank or credit card site, per-project accounts for a contractor, etc.

Re: How to build (and how not to build) a secure “remember me” feature

#34
post #28

Earlier quoted context omitted.

If an attacker uses a compromised session id before it is regenerated, the attacker will receive the regenerated session too. They'll have a long-lived session to the victims account.

If the attacker uses a compromised remember-me cookie, it will also be regenerated for him. Same problem.

If you use the scheme described linked from the article, when the legitimate user logs in again, the attacker will lose access to the session permanently.

Re: How to build (and how not to build) a secure “remember me” feature

#35
Help!

Most of this discussion I understand. One point is, it all involves lots of work with browser cookies stored on the user's computer.

My approach so far is to send the user the character string version of a GUID (globally unique identifier, supposely unique in all space and time, on all computers or some such) in an HTML text box marked as "hidden" so that it doesn't show on the screen. Then I use that GUID value as a key in a key-value store where the value keeps the short term info I want on the user and their 'session'. I wrote my own little key-value store with TCP/IP, some class instance de/serialization, and two instances of a .NET collection class.

However, my understanding is that some browsers are willing to help implement the function "Remmeber me on this computer" without help of cookies. How? My guess: For the text boxes on the login in Web page, in the HTML use names for the boxes that the browser interprets as 'user name' and 'password', and then the browser stores the contents in its dedicated disk space by Web page. Right?

So, there's a 'security hole' here if the user is on a computer shared with other people!

Also, my understanding is that so far on mobile devices, the browsers do not permit cookies. True? And if so, do mobile browsers permit the function of remember me I described above?

Thanks.

Re: How to build (and how not to build) a secure “remember me” feature

#36

Or you can do this: Client generates random value, puts it into cookie and passes it to server along with valid credentials. Server remebers it for this user and whenever at later time it sees this value in the cookie it logs in this user. Server forgets this value when this user logs out and after some time. If client does't have javascript or you don't trust randomness it can generate you can create this value on s…

What is the point of generating this value on the client? The second scenario you describe seems to work the same, minus the need to generate values on the client, with the same outcome.

Re: How to build (and how not to build) a secure “remember me” feature

#37
post #6

I tend to like doing: sha256(sha256($password) . $ip) This encrypts the password and makes the cookie only usable by the IP it was set for. Then to verify the cookie, since I already store sha256 of the password, it's trivial to do, without having to store an additional token for persistence. Of course you can replace sha256 with your fav hashing function.

In most parts of the world, users have dynamic IP's that change every time they connect to their ISP (often multiple times/day in the case of home users)

Re: How to build (and how not to build) a secure “remember me” feature

#39
post #17

Can someone explain how the example of the JSON encoded cookie could be used for XSS?

> What this means is that client script can access those cookies which means that if you can get a piece of XSS onto the site – just as you can on the Aussie Farmers site – you can steal cookies containing passwords if you can get a customer to load the XSS payload

The author is saying that, putting the password in a cookie means that, if there is an XSS vulnerability somewhere, it can be trivially used to steal usernames and passwords, since the XSS can be used to inject code on the site that can grab the values from document.cookie and append them to a hidden iframe.

Re: How to build (and how not to build) a secure “remember me” feature

#40

Regarding how long to keep the "remember me" cookie for, this is one of the overlooked reasons why native apps are eating the web's breakfast. When was the last time you have to re-authenticate on a native mobile app? Maybe it happens on some finance/banking apps, but I don't recall seeing it on apps like Facebook or Kindle for example. Web developers could, for example, add longer times if the user agent is mobile.…

> When was the last time you have to re-authenticate on a native mobile app? All the time. The Facebook android app is horrible.

Not for me. Did you by any chance move the app to your SD card? Apps that use the android Sync provider don't work if they're moved.
Post reply on HN