9 ms·

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

253 points by troyhunt 13y ago

kijin 13y ago
> A more pragmatic mitigation is to still separate the auth cookie from a dedicated “remember me” cookie and use the latter to re-authenticate the user but impose some restrictions. What are the benefits of using a separate cookie for the "remember me" feature, provided that you impose the same restrictions (e.g. requiring the password again before accessing sensitive areas of the website) and same security measures like "httponly" & "secure"? I've been using a single cookie with a randomly generated and periodically replaced session identifier, which expires at the end of the session by default but lasts longer if the user selects "remember me". I'd like to know whether there is a compelling reason to switch to two cookies.
- jbri 13y ago
  How do you tell if the user's session has expired so you know to ask them to re-authenticate before doing anything sensitive?
  - kijin 13y ago
    AFAIK the re-authentication thing has nothing to do with expiring sessions. The whole point is to ask users to re-authenticate even though their sessions are still alive and well. Enter your password again to change your privacy settings, etc.
- ajanuary 13y ago
  I think the restrictions are things like restricting by IP, reducing simultaneous use, throttling the rate you can create new sessions. With a unified token, you have to always trust it for as long as the 'remember me' token is alive. With split tokens, you can do a sanity checks like those mentioned above on every session initialisation. The value of splitting the tokens into separate cookies seems to be simplicity of implementation. You can rely on the browser to invalidate the session cookie on a browser close, but leave the 'remember me' cookie (as far as you can rely on the browser to do anything). Every useful restriction I can think of seems brittle, so I guess it's weighing up security against support.
- dasil003 13y ago
  One significant benefit is being able to enforce a one-time use policy the remember-me cookie. If you only utilize it when the user is not logged in, then you use it to authenticate, set a regular session cookie, and generate a new remember-me cookie. If an old remember-me cookie is ever used that means someone probably sniffed the cookie, and you can invalidate all sessions at that point and even force a password reset if you are particularly paranoid. You can't do this with the regular session cookie because a user might have multiple tabs open. For remember-me the same effect is only a race condition if the user opens two tabs simultaneously.
  - kijin 13y ago
    > You can't do this with the regular session cookie because a user might have multiple tabs open. Why not? It's considered standard practice to refresh regular session identifiers every X minutes, and this rarely causes race conditions unless your app is AJAX-heavy. My apps regenerate the session identifier every time it detects that it has been more than 5 minutes since the last regeneration. So if a user who has been away for a few hours returns to the site, his session identifier will be immediately regenerated and the old one will become useless. If race conditions become a serious issue, I can allow the old session identifier to continue to work for the next 30 seconds or so. It also shouldn't be too difficult to add a feature that throws tantrums if someone continues to use the old one much later than that.
    - mmcnickle 13y ago
      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.
      - kijin 13y ago
        If the attacker uses a compromised remember-me cookie, it will also be regenerated for him. Same problem.
        13y ago
- mmcnickle 13y ago
  The justification is earlier in the article [1]. It slightly lowers the attack cross-section. If you implement the separate login cookie scheme described in the linked article[2] you also get a limited ability to detect hijacked sessions and limit the length of time an attacker has access to the account. [1] "One argument against long expiration of auth cookies is that they’re effectively keeping the user authenticated and at risk of attacks such as CSRF or clickjacking. Of course the application needs to exhibit other risks in order for an attacker to capitalise on the long lasting cookie but the whole defence in depth argument comes up again." [2] http://jaspan.com/improved_persistent_login_cookie_best_practice http://jaspan.com/improved_persistent_login_cookie_best_prac...
brown9-2 13y ago
How does the "reference implementation" of ASP.NET actually work? Is the cookie's value mapped to some in-memory entry in the application server, is it stored in a database, etc? It seems that the article doesn't say.
- sigil 13y ago
  > Is the cookie's value mapped to some in-memory entry in the application server, is it stored in a database, etc? Neither. At login the server signs the new session cookie with a secret application key. Later, when a client requests a page and sends over the session cookie, the server verifies the signature. If it matches, the data in the session cookie -- which usually includes the username, whether they're logged in, and for how long -- can be trusted. This is nice because it makes scaling a stateful site easier. Server-side session stores often become the bottleneck. Also, from a REST standpoint, updating a session database during a GET request (eg to freshen the session) is problematic. ASP.net was the first time I remember seeing the signed session cookie trick, but most web frameworks have it now: django -- https://docs.djangoproject.com/en/dev/topics/http/sessions/#using-cookie-based-sessions https://docs.djangoproject.com/en/dev/topics/http/sessions/#... rails -- http://guides.rubyonrails.org/security.html#session-storage http://guides.rubyonrails.org/security.html#session-storage flask -- http://flask.pocoo.org/docs/api/#sessions http://flask.pocoo.org/docs/api/#sessions node -- https://github.com/mozilla/node-client-sessions https://github.com/mozilla/node-client-sessions mojolicious -- http://toroid.org/ams/etc/mojolicious-session-cookies http://toroid.org/ams/etc/mojolicious-session-cookies
dendory 13y ago
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.
- atburrow 13y ago
  What if the user gets their session hijacked when they're on a static or long-term dynamic IP? If the user were to relogin, their session ID would be the same. I think it would be beneficial to at least store a salt associated with their session and regenerate the salt when authenticating. sha256($password . $ip . $random_salt) You could also regenerate the salt periodically.
  - stouset 13y ago
    No. None of these. Please stop. The system is entirely broken. No amount of tweaking is going to fix it.
- sehrope 13y ago
  > since I already store sha256 Storing SHA-256 of passwords is a bad idea. You should use either scrypt, bcrypt, or at the very least PBDKF2 (with a large number of rounds). For a signed token round tripped to the client you should use an HMAC[1]. [1]: http://en.m.wikipedia.org/wiki/Hash-based_message_authentication_code http://en.m.wikipedia.org/wiki/Hash-based_message_authentica...
- danielweber 13y ago
  I have two ISPs at home. What happens when the next day my router decides to use the other IP address?
- markdown 13y ago
  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)
WA 13y ago
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 $EXPIRATION_TIMESTAMP on the server. You could also follow a layered approach: If the user logs in every few days, re-authenticate him using the auth token from the cookie. But if the user was seen more than $MAX_INACTIVE_DAYS ago, do not re-authenticate and terminate all sessions, even if the "remember me" function is set to half a year or so.
- kijin 13y ago
  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?
  - j_s 13y ago
    Implement cookie expiration server-side.
    - jessaustin 13y ago
      Would anyone be tempted to do this "client-side"? What would that even mean, besides what the browser does automatically? Or are we just saying, "don't trust that the client won't send expired cookies"?
  - WA 13y ago
    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.
mmahemoff 13y ago
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. And Troy is spot on about the middle ground of "logged-in-ness". Developers are finally realising what Amazon knew all along, that it's not binary. You can keep the user partially logged in, while requiring authentication to perform sensitive tasks.
- winthrowe 13y ago
  > When was the last time you have to re-authenticate on a native mobile app? All the time. The Facebook android app is horrible.
  - bmm6o 13y ago
    Not to refute your experience, but I've never had to re-auth facebook on my android.
  - randomchars 13y ago
    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.
- sergiosgc 13y ago
  Yup. Mozilla persona browser integration should already be here. Then, web apps can delegate auth to the browser much as native apps delegate to the operating system.
danielweber 13y ago
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.
- dmckeon 13y ago
  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.
- unclebucknasty 13y ago
  Not to mention the sheer convenience of one less thing to type--especially helpful if you are on a mobile device, where typing is still a pain vs. on a full keyboard.
thesis 13y ago
Can someone explain how the example of the JSON encoded cookie could be used for XSS?
- wasd 13y ago
  I'm not sure either. I hope someone can enlighten.
- yahelc 13y ago
  > 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.
- bigiain 13y ago
  I don't know if it's what Troy was implying, but JSON as a cookie payload along with the seemingly ubiquitous "parsing JSON using YAML and the YAML parser executing it as arbitrary code" vulnerability seems like it'd at least be worth attempting to attack there. (Probably not what Troy was thinking, since that'd result in server-side SQLi or arbitrary code execution problems, not client-side ones like XSS. Also, I thnik Troy is more a .Net/asp kind of guy, not a Ruby-ist - which might make that YAML parser issue in Ruby/Rails not something he's concerned about)
- bemurphy 13y ago
  It's really unclear, but I think it's a loose reference to an older hack that involves patching javascript's Array to steal data when parsing JSON. The references to 'old array' and 'new array' in the screenshot seem to be the tipoff. This is my best guess at least. See http://flask.pocoo.org/docs/security/#json-security http://flask.pocoo.org/docs/security/#json-security for info. Most modern browsers don't let you patch Array like this anymore. Also, that's more a csrf issue so, I could be totally wrong.
sehrope 13y ago
Remember me cookies are a specific case of some data sent to the client that the server would like to verify at a later point in time. The most direct way that comes to mind for solving this type of problem is to send the client just a random identifier and have the server look it up in a persistent store upon use. The other way of solving it is to have the server sign whatever data is sent to the client via an HMAC. That combined with some basic serialization gets you a generic approach that you can use for all kinds of things. This also has the scalable benefit that it doesn't require a centralize persistent store. Here's a high level summary of how we handle these use cases: # Server -> Client (Assume server wants to round trip object X) 1. Server serializes X to a URL friendly string (JSON + Base64 works well enough for this) 2. Server calls generateToken(type, message, expiration) which signs the message/expiration with secretKey+type. It then returns a JSON/Base64 serialized map containing message/expiration/hmac. # Client -> Server 1. Client sends back the final JSON/Base64 string 2. Server decodes and extracts the message, expiration, and hmac 3. Server verifies the HMAC by regenerating it and comparing it against the client supplied one 4. Server verifies the expiration date hasn't passed 5. Server returns back the deserialized object Couple of notes: * The HMAC prevents the client from tampering with the message * The 'type' field is so that tokens generated for one request type cannot be accepted somewhere else in the application. It's kind of like namespacing. * The 'type' field does not need to be included in the message itself. It's inferred by the server based on the client request type. * The object/message itself can be blank. In that case this becomes a secure expiring token. Couple of possible extensions/improvements: * If the data being sent back/forth is particularly sensitive you could also have the server encrypt either it or the entire message itself. If it's not though then it would be overkill. * Including the requesting clients IP in the HMAC generation to further limit the set of user's it would validate against is an option as well though generally that's a bad idea. People's IP addresses change fairly often and that kills the basic use case of taking your work home with you.
- mmcnickle 13y ago
  This is a good approach for a lot of things. It's the approach Flask uses for its session data by default. I wouldn't recommend it for authentication in large deployments though. One thing that it doesn't allow for is revocation of individual tokens. Invalidating auth tokens centrally is a very useful capability to have.
scotty79 13y ago
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.
- brown9-2 13y ago
  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.
  - scotty79 13y ago
    I guess no point. Pick the one that you feel better with.
    - scotty79 13y ago
      Also the server should keep it hmac-ed in case db silently leaked.
graycat 13y ago
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.
- yread 13y ago
  You are a bit confused, but I'm not sure why you're being downvoted... > GUID GUIDs are really not the best idea, they can be (sort of) predicted - an attacker can guess which GUIDs are in use as session identifiers. Better to use a random string (generated by a cryptographic random number generator) > without cookies Browsers can store user's password when they request it. It is a security hole, consciously made by the user for added convenience. Also, only the user who made this decision can fall into this hole - it's his credentials that get stolen. > mobile devices ... do not permit cookies they do (although some might not store the cookies for as long as the expiration would require). However, they don't allow the user to store the password (as in the previous paragraph, the remember me function as you call it) To round it up, it's a good thing you're experimenting with your own key/value store and session implementation, but it's usually better to use tested components in production (especially for the session stuff - it's very easy to get wrong). Anyway, keep experimenting, that's the best way to learn - I just hope somebody reviews your stuff before you shoot yourself in the foot :)
stouset 13y ago
There's a lot of misinformation in this thread, so I'm going to describe best practice for this sort of thing. 1. The client authenticates, and asks to be remembered. 2. The server generates a cryptographically random token of at least 128 bits in length. This token is *never* directly stored server-side. 3. The hash (or, possibly, a slow-hash) of the token is saved in the database along with a time of expiry 4. The non-hashed token is sent to the client as a cookie completely independent of the session cookie When the client visits the website: 1. The server checks for the presence of the remember-me cookie 2. If the cookie is set, it is hashed and this hash is searched for in the database (and filtered to tokens with expiry times after now) 3. If the user is successfully logged in, the old token is deleted from the database. A new token is generated and sent to the client by the previously-described process Now for a little bit of explanation. This process completely isolates the authentication token from the session. If a token is somehow intercepted or discovered by an attacker, it is only usable for a single session. Such tokens should never be allowed to serve as permanent entry points into a user's account. The token is never directly stored server-side. This confers two benefits. First, these tokens should be considered password-equivalent — if someone manages to steal your table of remember-me tokens, they would be completely unable to use them to log into a user's account. Second, this prevents timing attacks; if you simply looked for matching tokens in your database, an attacker can (shockingly simply) use timing information to guess a user's remember-me token in O(n) time.
- jessaustin 13y ago
  I don't see why you have to store the hash of the token. You know the key you used for HMACing, why can't you just check that the cookie contains a valid hash of the rest of its data (which is as extensive as you need: session id, expiry, IP, whatever)? To prevent the use of old sessions just make the session id a counter. A single session counter per user is probably less hassle (and more useful) to store than the whole hash.
  - stouset 13y ago
    To avoid the problem of storing the token's hash, you have introduced: * parsing a structured cookie, vs a meaningless 128-bit string * securely storing and managing a secret HMAC key (which may be used to forge or modify credentials) * securely verifying an HMAC using a constant-time string comparision So what, exactly, is the benefit of your proposal over mine? You've removed the (useful) distinction between an authentication token and the user's session. You've introduced significant additional complication and moving components. And you've increased the attack surface for security vulnerabilities. For what? Doing all that to store a 32-bit integer is somehow less hassle than hashing and storing a 128-bit string?

253 points by troyhunt 13y ago

kijin 13y ago

> A more pragmatic mitigation is to still separate the auth cookie from a dedicated “remember me” cookie and use the latter to re-authenticate the user but impose some restrictions. What are the benefits of using a separate cookie for the "remember me" feature, provided that you impose the same restrictions (e.g. requiring the password again before accessing sensitive areas of the website) and same security measures like "httponly" & "secure"? I've been using a single cookie with a randomly generated and periodically replaced session identifier, which expires at the end of the session by default but lasts longer if the user selects "remember me". I'd like to know whether there is a compelling reason to switch to two cookies.

jbri 13y ago
How do you tell if the user's session has expired so you know to ask them to re-authenticate before doing anything sensitive?
- kijin 13y ago
  AFAIK the re-authentication thing has nothing to do with expiring sessions. The whole point is to ask users to re-authenticate even though their sessions are still alive and well. Enter your password again to change your privacy settings, etc.
ajanuary 13y ago
I think the restrictions are things like restricting by IP, reducing simultaneous use, throttling the rate you can create new sessions. With a unified token, you have to always trust it for as long as the 'remember me' token is alive. With split tokens, you can do a sanity checks like those mentioned above on every session initialisation. The value of splitting the tokens into separate cookies seems to be simplicity of implementation. You can rely on the browser to invalidate the session cookie on a browser close, but leave the 'remember me' cookie (as far as you can rely on the browser to do anything). Every useful restriction I can think of seems brittle, so I guess it's weighing up security against support.
dasil003 13y ago
One significant benefit is being able to enforce a one-time use policy the remember-me cookie. If you only utilize it when the user is not logged in, then you use it to authenticate, set a regular session cookie, and generate a new remember-me cookie. If an old remember-me cookie is ever used that means someone probably sniffed the cookie, and you can invalidate all sessions at that point and even force a password reset if you are particularly paranoid. You can't do this with the regular session cookie because a user might have multiple tabs open. For remember-me the same effect is only a race condition if the user opens two tabs simultaneously.
- kijin 13y ago
  > You can't do this with the regular session cookie because a user might have multiple tabs open. Why not? It's considered standard practice to refresh regular session identifiers every X minutes, and this rarely causes race conditions unless your app is AJAX-heavy. My apps regenerate the session identifier every time it detects that it has been more than 5 minutes since the last regeneration. So if a user who has been away for a few hours returns to the site, his session identifier will be immediately regenerated and the old one will become useless. If race conditions become a serious issue, I can allow the old session identifier to continue to work for the next 30 seconds or so. It also shouldn't be too difficult to add a feature that throws tantrums if someone continues to use the old one much later than that.
  - mmcnickle 13y ago
    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.
    - kijin 13y ago
      If the attacker uses a compromised remember-me cookie, it will also be regenerated for him. Same problem.
      - 13y ago
mmcnickle 13y ago
The justification is earlier in the article [1]. It slightly lowers the attack cross-section. If you implement the separate login cookie scheme described in the linked article[2] you also get a limited ability to detect hijacked sessions and limit the length of time an attacker has access to the account. [1] "One argument against long expiration of auth cookies is that they’re effectively keeping the user authenticated and at risk of attacks such as CSRF or clickjacking. Of course the application needs to exhibit other risks in order for an attacker to capitalise on the long lasting cookie but the whole defence in depth argument comes up again." [2] http://jaspan.com/improved_persistent_login_cookie_best_practice http://jaspan.com/improved_persistent_login_cookie_best_prac...

brown9-2 13y ago

How does the "reference implementation" of ASP.NET actually work? Is the cookie's value mapped to some in-memory entry in the application server, is it stored in a database, etc? It seems that the article doesn't say.

sigil 13y ago
> Is the cookie's value mapped to some in-memory entry in the application server, is it stored in a database, etc? Neither. At login the server signs the new session cookie with a secret application key. Later, when a client requests a page and sends over the session cookie, the server verifies the signature. If it matches, the data in the session cookie -- which usually includes the username, whether they're logged in, and for how long -- can be trusted. This is nice because it makes scaling a stateful site easier. Server-side session stores often become the bottleneck. Also, from a REST standpoint, updating a session database during a GET request (eg to freshen the session) is problematic. ASP.net was the first time I remember seeing the signed session cookie trick, but most web frameworks have it now: django -- https://docs.djangoproject.com/en/dev/topics/http/sessions/#using-cookie-based-sessions https://docs.djangoproject.com/en/dev/topics/http/sessions/#... rails -- http://guides.rubyonrails.org/security.html#session-storage http://guides.rubyonrails.org/security.html#session-storage flask -- http://flask.pocoo.org/docs/api/#sessions http://flask.pocoo.org/docs/api/#sessions node -- https://github.com/mozilla/node-client-sessions https://github.com/mozilla/node-client-sessions mojolicious -- http://toroid.org/ams/etc/mojolicious-session-cookies http://toroid.org/ams/etc/mojolicious-session-cookies

dendory 13y ago

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.

atburrow 13y ago
What if the user gets their session hijacked when they're on a static or long-term dynamic IP? If the user were to relogin, their session ID would be the same. I think it would be beneficial to at least store a salt associated with their session and regenerate the salt when authenticating. sha256($password . $ip . $random_salt) You could also regenerate the salt periodically.
- stouset 13y ago
  No. None of these. Please stop. The system is entirely broken. No amount of tweaking is going to fix it.
sehrope 13y ago
> since I already store sha256 Storing SHA-256 of passwords is a bad idea. You should use either scrypt, bcrypt, or at the very least PBDKF2 (with a large number of rounds). For a signed token round tripped to the client you should use an HMAC[1]. [1]: http://en.m.wikipedia.org/wiki/Hash-based_message_authentication_code http://en.m.wikipedia.org/wiki/Hash-based_message_authentica...
danielweber 13y ago
I have two ISPs at home. What happens when the next day my router decides to use the other IP address?
markdown 13y ago
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)

WA 13y ago

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 $EXPIRATION_TIMESTAMP on the server. You could also follow a layered approach: If the user logs in every few days, re-authenticate him using the auth token from the cookie. But if the user was seen more than $MAX_INACTIVE_DAYS ago, do not re-authenticate and terminate all sessions, even if the "remember me" function is set to half a year or so.

kijin 13y ago
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?
- j_s 13y ago
  Implement cookie expiration server-side.
  - jessaustin 13y ago
    Would anyone be tempted to do this "client-side"? What would that even mean, besides what the browser does automatically? Or are we just saying, "don't trust that the client won't send expired cookies"?
- WA 13y ago
  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.

mmahemoff 13y ago

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. And Troy is spot on about the middle ground of "logged-in-ness". Developers are finally realising what Amazon knew all along, that it's not binary. You can keep the user partially logged in, while requiring authentication to perform sensitive tasks.

winthrowe 13y ago
> When was the last time you have to re-authenticate on a native mobile app? All the time. The Facebook android app is horrible.
- bmm6o 13y ago
  Not to refute your experience, but I've never had to re-auth facebook on my android.
- randomchars 13y ago
  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.
sergiosgc 13y ago
Yup. Mozilla persona browser integration should already be here. Then, web apps can delegate auth to the browser much as native apps delegate to the operating system.

danielweber 13y ago

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.

dmckeon 13y ago
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.
unclebucknasty 13y ago
Not to mention the sheer convenience of one less thing to type--especially helpful if you are on a mobile device, where typing is still a pain vs. on a full keyboard.

thesis 13y ago

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

wasd 13y ago
I'm not sure either. I hope someone can enlighten.
yahelc 13y ago
> 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.
bigiain 13y ago
I don't know if it's what Troy was implying, but JSON as a cookie payload along with the seemingly ubiquitous "parsing JSON using YAML and the YAML parser executing it as arbitrary code" vulnerability seems like it'd at least be worth attempting to attack there. (Probably not what Troy was thinking, since that'd result in server-side SQLi or arbitrary code execution problems, not client-side ones like XSS. Also, I thnik Troy is more a .Net/asp kind of guy, not a Ruby-ist - which might make that YAML parser issue in Ruby/Rails not something he's concerned about)
bemurphy 13y ago
It's really unclear, but I think it's a loose reference to an older hack that involves patching javascript's Array to steal data when parsing JSON. The references to 'old array' and 'new array' in the screenshot seem to be the tipoff. This is my best guess at least. See http://flask.pocoo.org/docs/security/#json-security http://flask.pocoo.org/docs/security/#json-security for info. Most modern browsers don't let you patch Array like this anymore. Also, that's more a csrf issue so, I could be totally wrong.

sehrope 13y ago

Remember me cookies are a specific case of some data sent to the client that the server would like to verify at a later point in time. The most direct way that comes to mind for solving this type of problem is to send the client just a random identifier and have the server look it up in a persistent store upon use. The other way of solving it is to have the server sign whatever data is sent to the client via an HMAC. That combined with some basic serialization gets you a generic approach that you can use for all kinds of things. This also has the scalable benefit that it doesn't require a centralize persistent store. Here's a high level summary of how we handle these use cases: # Server -> Client (Assume server wants to round trip object X) 1. Server serializes X to a URL friendly string (JSON + Base64 works well enough for this) 2. Server calls generateToken(type, message, expiration) which signs the message/expiration with secretKey+type. It then returns a JSON/Base64 serialized map containing message/expiration/hmac. # Client -> Server 1. Client sends back the final JSON/Base64 string 2. Server decodes and extracts the message, expiration, and hmac 3. Server verifies the HMAC by regenerating it and comparing it against the client supplied one 4. Server verifies the expiration date hasn't passed 5. Server returns back the deserialized object Couple of notes: * The HMAC prevents the client from tampering with the message * The 'type' field is so that tokens generated for one request type cannot be accepted somewhere else in the application. It's kind of like namespacing. * The 'type' field does not need to be included in the message itself. It's inferred by the server based on the client request type. * The object/message itself can be blank. In that case this becomes a secure expiring token. Couple of possible extensions/improvements: * If the data being sent back/forth is particularly sensitive you could also have the server encrypt either it or the entire message itself. If it's not though then it would be overkill. * Including the requesting clients IP in the HMAC generation to further limit the set of user's it would validate against is an option as well though generally that's a bad idea. People's IP addresses change fairly often and that kills the basic use case of taking your work home with you.

mmcnickle 13y ago
This is a good approach for a lot of things. It's the approach Flask uses for its session data by default. I wouldn't recommend it for authentication in large deployments though. One thing that it doesn't allow for is revocation of individual tokens. Invalidating auth tokens centrally is a very useful capability to have.

scotty79 13y ago

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.

brown9-2 13y ago
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.
- scotty79 13y ago
  I guess no point. Pick the one that you feel better with.
  - scotty79 13y ago
    Also the server should keep it hmac-ed in case db silently leaked.

graycat 13y ago

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.

yread 13y ago
You are a bit confused, but I'm not sure why you're being downvoted... > GUID GUIDs are really not the best idea, they can be (sort of) predicted - an attacker can guess which GUIDs are in use as session identifiers. Better to use a random string (generated by a cryptographic random number generator) > without cookies Browsers can store user's password when they request it. It is a security hole, consciously made by the user for added convenience. Also, only the user who made this decision can fall into this hole - it's his credentials that get stolen. > mobile devices ... do not permit cookies they do (although some might not store the cookies for as long as the expiration would require). However, they don't allow the user to store the password (as in the previous paragraph, the remember me function as you call it) To round it up, it's a good thing you're experimenting with your own key/value store and session implementation, but it's usually better to use tested components in production (especially for the session stuff - it's very easy to get wrong). Anyway, keep experimenting, that's the best way to learn - I just hope somebody reviews your stuff before you shoot yourself in the foot :)

stouset 13y ago

There's a lot of misinformation in this thread, so I'm going to describe best practice for this sort of thing. 1. The client authenticates, and asks to be remembered. 2. The server generates a cryptographically random token of at least 128 bits in length. This token is *never* directly stored server-side. 3. The hash (or, possibly, a slow-hash) of the token is saved in the database along with a time of expiry 4. The non-hashed token is sent to the client as a cookie completely independent of the session cookie When the client visits the website: 1. The server checks for the presence of the remember-me cookie 2. If the cookie is set, it is hashed and this hash is searched for in the database (and filtered to tokens with expiry times after now) 3. If the user is successfully logged in, the old token is deleted from the database. A new token is generated and sent to the client by the previously-described process Now for a little bit of explanation. This process completely isolates the authentication token from the session. If a token is somehow intercepted or discovered by an attacker, it is only usable for a single session. Such tokens should never be allowed to serve as permanent entry points into a user's account. The token is never directly stored server-side. This confers two benefits. First, these tokens should be considered password-equivalent — if someone manages to steal your table of remember-me tokens, they would be completely unable to use them to log into a user's account. Second, this prevents timing attacks; if you simply looked for matching tokens in your database, an attacker can (shockingly simply) use timing information to guess a user's remember-me token in O(n) time.

jessaustin 13y ago
I don't see why you have to store the hash of the token. You know the key you used for HMACing, why can't you just check that the cookie contains a valid hash of the rest of its data (which is as extensive as you need: session id, expiry, IP, whatever)? To prevent the use of old sessions just make the session id a counter. A single session counter per user is probably less hassle (and more useful) to store than the whole hash.
- stouset 13y ago
  To avoid the problem of storing the token's hash, you have introduced: * parsing a structured cookie, vs a meaningless 128-bit string * securely storing and managing a secret HMAC key (which may be used to forge or modify credentials) * securely verifying an HMAC using a constant-time string comparision So what, exactly, is the benefit of your proposal over mine? You've removed the (useful) distinction between an authentication token and the user's session. You've introduced significant additional complication and moving components. And you've increased the attack surface for security vulnerabilities. For what? Doing all that to store a 32-bit integer is somehow less hassle than hashing and storing a 128-bit string?