8 ms·

This seems to be a common practice, storing UserIDs, Usernames, etc. in cookies rather than a unique SessionID that can be used to look those things up (and wil

This seems to be a common practice, storing UserIDs, Usernames, etc. in cookies rather than a unique SessionID that can be used to look those things up (and will expire). I'm curious as to where people are getting the idea to build things that way. Because it never would have occurred to me to do so. Or rather, had it occurred, it would have immediately begged the question of "what happens when the user monkeys with their cookie". Surely everybody else thinks the same way. If so, how do we end up with this? Are there really "Teach yourself in 21 Days" books that have examples with this pattern that people are following? Or does everybody just assume that they're going to be Facebook with 4000 servers and no way to quickly generate or store or manage or look up those keys for millions of simultaneous users, and that it's worth the tradeoff?

agmcleod 10y ago
It's something i've steered away from, or I would encrypt the id before saving it in the session. I don't exactly recall where I picked it up, but i know i've seen it in example tutorials in books with Rails apps.
- nateberkopec 10y ago
  FWIW, all session information (`session[:user_id]`) is stored in an encrypted cookie starting with Rails 4.
deleted 10y ago
[deleted]
Ensorceled 10y ago
It's literally used on hundreds of websites. I'm sure there is a developer out there right now going "How does McDonald's do this?"
ecopoesis 10y ago
I don't think everyone assumes they're going to be Facebook, but they probably do assume (correctly not my opinion) that scaling session management up is a painful, and are doing their best to avoid it. Consider it a teaching moment and show folks how simple it is to store all your session-like stuff in cookies, along with a timeout and a version hashed with the server's secret.
bluedino 10y ago
>> Are there really "Teach yourself in 21 Days" books that have examples with this pattern that people are following? Yes. From Learning PHP, MySQL, Javascript, CSS & HTML5, Third Edition, from O'Reilly publishing: So, to create a cookie with the name username and the value Hannah that is accessible across the entire web server on the current domain, and will be removed from the browser’s cache in seven days, use the following: setcookie('username', 'Hannah', time() + 60 * 60 * 24 * , '/'); And that was published in 2014, not 2004.
- bitexploder 10y ago
  A username is different from a password. There can often be legitimate or at least semi-legitimate reasons to do this. I dunno everyone has to learn how to use cookies if they are building web apps. Password is obviously just bad.
  - nommm-nommm 10y ago
    Everyone, really? I've been building webapps since forever and I've never cookies directly in Javascript like that and I can't, personally, think of a use case where I would do that. I've only used cookies that store a session id and I store everything in the session. The session id cookies are handled entirely by the servlet container. I don't believe I'm doing it horribly wrong.
    - bitexploder 10y ago
      What you stated is pretty normal seeming to me, so no, not "everyone". But I think web developers still need to know what a cookie is and how to use it, even if you dont use them often. They can provide a better user experience remembering some aspects of a user or their session long after it has expired. Many sites have semi-authenticated states where you may not want to hold user data, but still remember some details about their session.
y7 10y ago
User IDs and usernames, are generally public information, so I do not see the problem with storing that in a cookie, as long as you authenticate it (e.g. using a MAC, and you might want to include a timestamp and a version number). It does however sacrifice server-side control of sessions.
jdmichal 10y ago
To answer your question about monkeying: Sign the cookie! We sign session cookies with HMAC, and reset the session if it doesn't match. Doesn't handle replay attacks, but you at least know that you're getting back the same data that you gave the client.
- richthegeek 10y ago
  Does signing the cookie with secondary information such IP or UA help? I know they can both be spoofed, but it's an extra layer...
  - PeterisP 10y ago
    Signing the cookie with IP would break the site for everyone with changing IPs, e.g. mobile users on cellular networks. Web site sessions should persist across IPs.
- jessaustin 10y ago
  Doesn't handle replay attacks... This is why we have CSRF tokens, right? Orthogonal to session cookies, but when used together they avoid this vuln.
ascotan 10y ago
A couple of rambling thoughts on how we get here: 1. Lack of experience. Most web devs that's I've met have never even heard of using expiring session tokens in a cookie. (imho) It's been my experience that most javascript guys can be relatively young as it's the new teaching language (sorry python). They spend most of their time learning react/redux/moxd/angularjs2/vue and just haven't been exposed to security practices like expiring session tokens in cookie. It's not their fault, it's just that we don't know, what we don't know. Not realizing that this practice has been around for almost 20 years, the developer invented a new way of logging in using cookies. 2. Most people don't take security seriously. I recently had a conversation with a dev that was being a cool kid by using JWT bearer tokens. He was putting admin=true inside the bearer token and signing it. I asked him what would happen if I stolen his token. Would I become the admin? The answer appeared to be yes, the software would read the bearer token, inject admin=true into your session, and give you admin rights on the webserver. However, he explained the expiration of the JWT token was 1 hour. So I steal and use your token I only have 1 hour to become admin on your site?, I asked. Apparently he felt that was good enough. 3. Security is expected to be provided by the framework. XSS, CSRF, SQL injection - don't worry we're using Django. That seems to be the expectation of most people. You don't need to know about security, because the framework handles that. The problem is that this only gets you so far, there are things that live outside of the scope of the framework that you probably should know about, but don't. (I guess storing the user's password in a cookie would be one of those)
- devwastaken 10y ago
  >It's been my experience that most javascript guys can be relatively young I really don't understand how these people make it through the magic 'must have 5 years experience' marker and just don't know proper security practices. It seems like people just lie on that.
  - stanleydrew 10y ago
    They lie because the constraint is a lie. The years of experience requirement is entirely made up by a lazy hiring manager, and is just a poor proxy for "has this person tried and failed and learned enough from their mistakes to make well-reasoned decisions about future things without my constant oversight and input."
apocalyptic0n3 10y ago
We were doing that previously in our homegrown framework. Session would include id, username, and an expiration timestamp along with a salted hash of that data to confirm. We've since moved away from it (and the entire homegrown framework, actually) because we realized it didn't make anything easier, but we've never had an issues with that data being in the session (it was all publicly available regardless). In the end, though, it is probably best to err on the safe side and only expose a salted and hashed session ID via cookies, and then doing a server side lookup to get the necessary data (which you would need to do regardless)
DonaldFoss 10y ago
It seems we revisit this topic or a branch of it often enough that it's almost becoming a meme. Here is a 2-page, 7.4K security checklist. If you verify and check each box, your application won't be bulletproof (it is software and you have 3rd party libraries), but it will be close to air tight. --Disclaimer: I have nothing to do with this security checklist or its authors, except appreciation and respect. Security Guide For Developers - Latest: https://github.com/FallibleInc/security-guide-for-developers/blob/master/security-checklist.md https://github.com/FallibleInc/security-guide-for-developers... --Donald

agmcleod 10y ago

It's something i've steered away from, or I would encrypt the id before saving it in the session. I don't exactly recall where I picked it up, but i know i've seen it in example tutorials in books with Rails apps.

nateberkopec 10y ago
FWIW, all session information (`session[:user_id]`) is stored in an encrypted cookie starting with Rails 4.

deleted 10y ago

[deleted]

Ensorceled 10y ago

It's literally used on hundreds of websites. I'm sure there is a developer out there right now going "How does McDonald's do this?"

ecopoesis 10y ago

I don't think everyone assumes they're going to be Facebook, but they probably do assume (correctly not my opinion) that scaling session management up is a painful, and are doing their best to avoid it. Consider it a teaching moment and show folks how simple it is to store all your session-like stuff in cookies, along with a timeout and a version hashed with the server's secret.

bluedino 10y ago

>> Are there really "Teach yourself in 21 Days" books that have examples with this pattern that people are following? Yes. From Learning PHP, MySQL, Javascript, CSS & HTML5, Third Edition, from O'Reilly publishing: So, to create a cookie with the name username and the value Hannah that is accessible across the entire web server on the current domain, and will be removed from the browser’s cache in seven days, use the following: setcookie('username', 'Hannah', time() + 60 * 60 * 24 * , '/'); And that was published in 2014, not 2004.

bitexploder 10y ago
A username is different from a password. There can often be legitimate or at least semi-legitimate reasons to do this. I dunno everyone has to learn how to use cookies if they are building web apps. Password is obviously just bad.
- nommm-nommm 10y ago
  Everyone, really? I've been building webapps since forever and I've never cookies directly in Javascript like that and I can't, personally, think of a use case where I would do that. I've only used cookies that store a session id and I store everything in the session. The session id cookies are handled entirely by the servlet container. I don't believe I'm doing it horribly wrong.
  - bitexploder 10y ago
    What you stated is pretty normal seeming to me, so no, not "everyone". But I think web developers still need to know what a cookie is and how to use it, even if you dont use them often. They can provide a better user experience remembering some aspects of a user or their session long after it has expired. Many sites have semi-authenticated states where you may not want to hold user data, but still remember some details about their session.

y7 10y ago

User IDs and usernames, are generally public information, so I do not see the problem with storing that in a cookie, as long as you authenticate it (e.g. using a MAC, and you might want to include a timestamp and a version number). It does however sacrifice server-side control of sessions.

jdmichal 10y ago

To answer your question about monkeying: Sign the cookie! We sign session cookies with HMAC, and reset the session if it doesn't match. Doesn't handle replay attacks, but you at least know that you're getting back the same data that you gave the client.

richthegeek 10y ago
Does signing the cookie with secondary information such IP or UA help? I know they can both be spoofed, but it's an extra layer...
- PeterisP 10y ago
  Signing the cookie with IP would break the site for everyone with changing IPs, e.g. mobile users on cellular networks. Web site sessions should persist across IPs.
jessaustin 10y ago
Doesn't handle replay attacks... This is why we have CSRF tokens, right? Orthogonal to session cookies, but when used together they avoid this vuln.

ascotan 10y ago

A couple of rambling thoughts on how we get here: 1. Lack of experience. Most web devs that's I've met have never even heard of using expiring session tokens in a cookie. (imho) It's been my experience that most javascript guys can be relatively young as it's the new teaching language (sorry python). They spend most of their time learning react/redux/moxd/angularjs2/vue and just haven't been exposed to security practices like expiring session tokens in cookie. It's not their fault, it's just that we don't know, what we don't know. Not realizing that this practice has been around for almost 20 years, the developer invented a new way of logging in using cookies. 2. Most people don't take security seriously. I recently had a conversation with a dev that was being a cool kid by using JWT bearer tokens. He was putting admin=true inside the bearer token and signing it. I asked him what would happen if I stolen his token. Would I become the admin? The answer appeared to be yes, the software would read the bearer token, inject admin=true into your session, and give you admin rights on the webserver. However, he explained the expiration of the JWT token was 1 hour. So I steal and use your token I only have 1 hour to become admin on your site?, I asked. Apparently he felt that was good enough. 3. Security is expected to be provided by the framework. XSS, CSRF, SQL injection - don't worry we're using Django. That seems to be the expectation of most people. You don't need to know about security, because the framework handles that. The problem is that this only gets you so far, there are things that live outside of the scope of the framework that you probably should know about, but don't. (I guess storing the user's password in a cookie would be one of those)

devwastaken 10y ago
>It's been my experience that most javascript guys can be relatively young I really don't understand how these people make it through the magic 'must have 5 years experience' marker and just don't know proper security practices. It seems like people just lie on that.
- stanleydrew 10y ago
  They lie because the constraint is a lie. The years of experience requirement is entirely made up by a lazy hiring manager, and is just a poor proxy for "has this person tried and failed and learned enough from their mistakes to make well-reasoned decisions about future things without my constant oversight and input."

apocalyptic0n3 10y ago

We were doing that previously in our homegrown framework. Session would include id, username, and an expiration timestamp along with a salted hash of that data to confirm. We've since moved away from it (and the entire homegrown framework, actually) because we realized it didn't make anything easier, but we've never had an issues with that data being in the session (it was all publicly available regardless). In the end, though, it is probably best to err on the safe side and only expose a salted and hashed session ID via cookies, and then doing a server side lookup to get the necessary data (which you would need to do regardless)

DonaldFoss 10y ago

It seems we revisit this topic or a branch of it often enough that it's almost becoming a meme. Here is a 2-page, 7.4K security checklist. If you verify and check each box, your application won't be bulletproof (it is software and you have 3rd party libraries), but it will be close to air tight. --Disclaimer: I have nothing to do with this security checklist or its authors, except appreciation and respect. Security Guide For Developers - Latest: https://github.com/FallibleInc/security-guide-for-developers/blob/master/security-checklist.md https://github.com/FallibleInc/security-guide-for-developers... --Donald