"Remember Me On This Computer" - How Should It Work?

Question

Looking at Gmail's cookies it's easy to see what's stored in the "remember me" cookie. The username/one-time-access-token. It could be implemented differently in cases where the username is secret, as well. But whatever... the thing is not very high security: you steal the cookie and you're ready to go.

My question is on the functional side, however: when do you wipe their access tokens? If a user logs in without clicking "remember me" on another machine, should it invalidate their access tokens on all machines? I'm asking about how this is traditionally implemented, and also how it should be implemented.

Grandfatherly

I think how to set cookies for security is important when programming any web application - seems completely reasonable – Pinfold

How is this NOT programming related? – Ryanryann

Definitely programming related. – Anvers

C.f. codinghorror.com/blog/archives/001256.html – Relax

possible duplicate of What is the best way to implement "remember me" for a website? – Reserve

@MadKeithV kind of, but I'm asking about a different aspect – Grandfatherly

This is not a duplicate, it is programming related although not necessarily related to code per se. Good question. I'd like to know good answers myself! – Terrorstricken

Answer 1

I regularly use 2 or 3 machines simultaneously, and have "remember me" on all of them. If one of them disconnected the others that would be very annoying, so I wouldn't recommend it.

Traditionally it would use a time-out, the cookie expires after a certain length of time (or when the user signs out).

It all depends on your security model. If you are writing an internal company application where you only ever expect one user to be on one computer then you might want to have tighter restrictions than gmail.

Also, bear in mind the possibility of Denial of Service - if an action on one machine can force another machine to be unusable this could be use to prevent a legitimate user from taking control back in certain scenarios.

Pinfold

+1 I was about to write about the same answer, regularly using the same websites on 4..5 computers and on a mobile phone. – Standley

Thanks for that. So on logout, I could kill all the persistent sessions? That wouldn't be annoying? It sounds fine to me. – Grandfatherly

@daniel: killing all persistent sessions on logout seems like a reasonable thing to do. Otherwise, you'd have to keep the session persistence per computer, as well as per user. This way it could also work as a security measure for the conscious user, who could make sure that he is kicking anyone connected to his account. – Factitious

@daniel: I think you need a mental model of what logout means. If it means "This computer should now be safe for anyone to sue, I don't have to worry" then it should not logout all sessions. For example, I might want to keep my phone logged in when I walk away from the internet cafe. However, if logout means "force anyone who tries to connect to authenticate again" then all users should be kicked off. I'd prefer the former, but a case could be made for the latter – Pinfold

Thanks for your comments, Nick. My concern is, security-wise, is zero, because this remember-me thing is quite risky. I'm just concerned about the gesture of logging off, if you will. Is there any reason for a user to assume that "logout" means "log me off of all remember-me'd sessions?" Anyway, now that my curiosity is piqued, I'll have to try this stuff in a few browsers to see what Google and their usability team have come up with. – Grandfatherly

Answer 2

Logging on from another machine should not invalidate the login associated with a cookie on a different machine. However if the users logsout or "not you? login here" this should clear the cookie on which the user is working.

By the way stealing a cookie can be made hard, by insisting on https and making it not for scripting.

By adding "; HttpOnly" to the out put of your cookie this will make the cookie unavailable to javascript e.g.

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
Set-Cookie: ASP.NET_SessionId=ig2fac55; path=/; HttpOnly
X-AspNet-Version: 2.0.50727
Set-Cookie: user=t=bfabf0b1c1133a822; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Tue, 26 Aug 2008 10:51:08 GMT
Content-Length: 2838

you can read more about this

• for .Net
• Firefox support
• Jeff - Codings hard, lets go shopping

Hogarth

Thanks for that, David. Can you please give me some links or something on what we're talking about with a cookie "not for scripting?" – Grandfatherly

Sorry for the formatting, the code block seems to be deciding on interesting colors – Hogarth

Answer 3

The remember me cookie should identify the machine as well. It should be related to the machine because there are places where you want to be remembered and other places where you don't (home vs work).

Expiration date is set usually to a reasonable period (two weeks) or after the user has explicitly logged off from the machine,

Twenty

What would identify the machine? I can't get the Mac address, the user agent is not unique, and the IP address changes? – Grandfatherly

there's no way to uniquely identify the machine but you can use the standard approximation techniques, combination of IP/UserAgent for exmaple. And fail on the safe side if they change, they change and it's a different machine (even when it's not) – Twenty

Thanks Vinko. I just thought that maybe there was a magic browser key. But if there was, the hackers' sites would know it too... I'll vote you up even though I don't agree with IP-based IDing. – Grandfatherly

Answer 4

What I would do is link each session to an IP address. If the a session token is sent from a different IP than you have for that, reject it.

Mazzard

That wouldn't work for a user who potentially gets a different IP address every time they cycle the power on their modem. Furthermore, it would allow somebody on a corporate network where every machine in the company gets to the Internet through a single proxy server to steal the credentials of another user. IP addresses are no use whatsoever for identifying a user - not even across a single session, as some ISPs might route requests through different non-transparent proxies pretty much at random. – Crosseyed

ditto NickFitz: on SO questions of this type, people always reject IP-based security, since IP addresses change for many users. – Grandfatherly

"(...)since IP addresses change for most users." There fixed that for you. – Factitious

Answer 5

Access tokens should be IP specific so that they can not easily be transferred across machines.

They should also be implemented in a way that allows users to see what machines they have active tokens on.

Sites that choose to kill off a token once a new one is created on another computer - make the choice that their users will not access their service on multiple computers - or if they do - that their usage justifies making them login again.

The policy you employ really depends on the data you are holding and the needs of the user.

Chrysanthemum