This is why I prefer not to pass session information to the client in the first place. Have the session key be just an opaque, cryptographically random token that is then associated with data on the server (via a keystore of some sort). Then the cookie becomes nothing more than a bearer token.
There are some use cases this does not cover, such as authentication across multiple systems, where one or more may not have access to the authentication source, but even in that case it'd be preferable to have a separate, internal, private microservice that exchanges tokens for session information.
None of this will stop an attacker that has network access, but that's not what the article is considering, and if somebody is inside your network you might have bigger problems than session hijacking.
The reason is that, at scale, all the little things matter. Having to query your database for _every_ user request, to convert their session token into the server-side underlying data, gets expensive and slow. And it's a centralizing force in the architecture, requiring your session management database to be accessible by all your user facing servers.
So they store the data with the client, who can pass it back to the server with every request. One less DB query.
There are various rebuttals to that approach, even at scale, etc, etc. I'm certainly not advocating for it. But that's what some big applications landed on. Big apps drive most of the development of free tools, libraries, and frameworks. So it's no surprise that a lot of free tools handle this use case, even by default.
In the majority of cases, the not at scale cases, of course it doesn't make sense. Most all the hot new tools don't make sense. But again, that's just an artifact of software economics. The majority of the money is made by the big apps, so most tools are built for the big apps.
It's just a shame that new developers get caught up in these hip tools and base their understanding of the ecosystem on them.
Session key verification can be a cross cutting concern that is good enough for scale (API gateway, reverse proxy, cross cutting service). And with a verified session key, each service should be able to optimize for restoring data belonging to that session key.
If the data leaves your server, it is considered potentially malicious and you have to verify and validate everything anyway. Also, with client-side stored data you lose control over the client-server state unless you validate against the server state. But then you lose all the advantages of client-side storage. Crypto cannot mitigate that.
Most of the big companies to my knowledge generally don't depend on client side storage of session state (they might in a few isolated cases, but in general avoid it).
Google uses interesting approach to handling service accounts: JWT is used as user credential once to get the access token (session credentials) that is reused between requests.
Good article and callout for those projects (and mine). I am doing an express alternative[1] with something that is not secure as a temporary session secret[2] formed with `secret: 'secret-' + parseInt(1000000 * Math.random())` so I'll modify it to use a real random key from a crypto library or display a prominent warning. Then I am also documenting it in a small production security guide [3]. Also, if the key in the documentation is used there's a warning[4] similar to how Dropbox stops you from using 'correct-horse-battery-stapler' as a password.
If you have any other tip/recommendation I'd be really thankful.
BTW, doesn't SSL/TLS mitigate this a lot? Like, if the user is using SSL then only with physical access to a decrypted device would an attacker be able to impersonate the user, limiting greatly the possible attacks. And if someone has access to your decrypted device then you have bigger problems. Though devs who don't change 'super secret' are probably probably less likely to set up https...
Edit: I almost didn't include the BTW comment because I agree that it is an important part of security, so I didn't want to make it sound less severe, but I am curious about attack possibilities with https enabled.
SSL doesn't protect you from a malicious user who is trying to crack the key used on the cookie you gave him. It just means that no one else will eavesdrop on the malicious user's connection.
The attack in the article isn't about a malicious user eavesdropping and obtaining someone else's cookie directly. It's about a user who gets a cookie from the server, brute-forces to determine the key used to sign the cookie, and then uses that key to generate cookies that authenticate them as other users (or that execute code during deserialization, etc).
@franciscop -- keep an eye out for the rest of the article (it's already written and will be released soon). I go over the impacts of an attacker knowing the secret in much more detail. I also have sections on prevention for both application developers and library/framework authors that I think you'll find interesting!
I'll wait for it, because I don't fully understand @AgentME's comment "to generate cookies that authenticate them as other users". Those auth cookies would have a hashed token per user that must be created and validated in the back-end (besides the encryption). So just storing 'user-ID' should not be enough, you'd have to be able to decrypt a real user's cookie to know this token hash (and for this reason just guessing numbers/users ID would not be enough as well).
The cookie that the user gets might be something like userid + ":" + HMAC(server secret, userid). The user who gets that cookie can brute-force HMAC(x, userid) with different values of x until they get a match for the string in their cookie, at which point they know the server secret. Then with the server secret, they can generate a valid cookie for any userid.
That is exactly what I mean, you are not supposed to save the user id (hashed, encrypted or otherwise) in the cookie. You are supposed to save a random secure token that will be associated to that user's device/login. If you save the user id it'd be as an index, not for auth as the token is for that. See http://stackoverflow.com/a/32218069/938236
Of course then it depends on the developer, so statistically speaking there will be a % who do what you suggested and making it secure from the library/framework side would help some users, so I'm all in for it.
That strategy is often called sessions or a stateful-cookie. It requires all of the servers that accept that cookie to be able to share their session state (or for a strategy like sticky sessions to be used). The strategy I described is stateless: the servers only need to share the secret in order to verify the cookie. It's a popular strategy but it does have some trade-offs, such as being vulnerable to anyone who knows the secret.
Let's say your Python web application pickles your sessions so you can store more than just JSON serializable fields. Unpickling can result in the execution of arbitrary Python code and the only thing normally protecting you is that you MAC your session with the secret key (which was just cracked...)
The cookies spec really should be incorporated into the SSL/TLS layer. Right now it's basically performing two encryption/signing steps immediately after each other, one at the web server, and another for the applications server. This is a pain-in-the-ass for the web server framework and adds several milliseconds of redundant latency.
The cookie data should be signed with the web server's private key.
Of course folks are much more likely to misuse their cookie secret than purposefully break a library function. That said you can look at the history of most projects that use HMAC to authenticate data and they did it wrong.
What do people here use to store password for servers ? Plain text configuration files ? I have pwd of DB in config files and found no way to put it elsewhere.
Plain text can work, assuming that it is access controlled in a secure environment. Often times, during the build process, a secure secret management system or process will handle the combining of the code with configuration. For example, your developer (with no secret access) could commit code and Jenkins can fetch the configuration file from a secure and access-controlled service. Then the built code has the secrets and the developer does not. There are a lot of approaches to doing it at scale. See https://gist.github.com/maxvt/bb49a6c7243163b8120625fc8ae3f3... for a good overview.
Environment variables which depending on the host are done differently. For heroku it's a setting, for a bare bones server it'd be a plain file called .env.
I write most of my web apps using Sinatra (as per the article example), but do it using the Padrino [1] framework. Padrino by default sets the Sinatra session secrets to a long hash, which negates the developer from having to remember to do all this housekeeping later to tighten security on the app.
I don't know why anyone would ever do this since there is no cost to SECRET_KEY = os.urandom... or even just hammering on the keyboard. It is not like you are ever going to be challenged for that password? You could even say here is another line of code that will compromise your server:
No; Django does that, and the result is that people check that random secret into source control. The correct solution is to not have the secret in code at all, but to read it at initialization time out of some kind of secrets management system (traditionally via environment variables). Unfortunately, frameworks generally can't do this in a hosting-setup-agnostic way; you have to understand the specific facilities that your PaaS or deployment system offers for this, and some (looking at you, Google App Engine Standard Environment) don't offer adequate ones.
I am not saying the secret should be in the code itself.
The app generator could generate a .gitignore including another dotfile with the secret in it. Or print a message on how important it is to configure the secret properly.
My point was that a framework should not generate a working value that is insecure. And if generating no value and have the app not start without additional configuration is the best way, this should be the way to go.
ah I can see how that sidebar is confusing now. the point was just to highlight the configuration names across different frameworks. as @ameliaquining points out, a randomly generated secret that's been leaked to github has much the same effect as one that is easily guessed.
I'll think about ways to make it more clear! Thanks
Or, for simple cases where a single server handles all clients (i.e. no load-balanced cloud setup), just generate it on startup. A server restart will invalidate sessions, but oh well.
Default passwords are a problem with the system being configured; not with the configuration. Insecure-by-default systems should not be deployed anywhere.
There are some use cases this does not cover, such as authentication across multiple systems, where one or more may not have access to the authentication source, but even in that case it'd be preferable to have a separate, internal, private microservice that exchanges tokens for session information.
None of this will stop an attacker that has network access, but that's not what the article is considering, and if somebody is inside your network you might have bigger problems than session hijacking.