Importance of session secret key in Express web framework

1. Because PHP is not Nodejs. Session management in PHP is different from session management in node: node never dies, unlike PHP, which is constantly invoked by your server daemon (apache, IIS, what have you), asked to generate some content, then end its process. Node is the equivalent of Apache plus PHP.
2. It's used to encrypt the session cookie so that you can be reasonably (but not 100%) sure the cookie isn't a fake one, and the connection should be treated as part of the larger session with express.
3. This is why you don't put the string in your source code. You make it an environment variable and read it in as process.env("SESSION_SECRET") or you use an .env file with https://npmjs.org/package/dotenv, and make sure those files never touch your repository (svn/git exclusion/ignores) so that your secret data stays secret.
4. the secret is immutable while your node app runs. It's much better to just come up with a long, funny sentence than a UUID, which is generally much shorter than "I didn't think I needed a secret, but some rando on Stackoverflow told me Express needed one so here we are".

How I use sessions:

.env file (always in my .gitignore file so it never hits my public repos):

SECRET="This is my funky secret oh my god it has ninja turtles"

app.js:

var express = require('express'),    env = (function(){      var Habitat = require("habitat");      Habitat.load();      return new Habitat();    }()),    app = express();app.use(express.compress()); // gzip all the things. If possible.app.use(express.bodyParser());app.use(express.cookieParser());app.use(express.cookieSession({  key: "mysite.sid",  // seeing this tells you nothing about the actual secret:  secret: env.get("SESSION_SECRET"),  cookie: {    maxAge: 2678400000 // 31 days  }}));app.use(express.csrf());

That CSRF bit ensures that page requests are coming from your own site, not cURL requests or embeds in other people's websites. http://expressjs.com/api.html#csrf for more info on that.

I think that the major point is missed in the other answers, which is whether the secret parameter is making session management more secure. it is discussed nicely in this Security.StackExchange question: Why is it insecure to store the session ID in a cookie directly?

I recommend reading it (not only the top voted answer there is relevant).

Trying to sum it up: it won't reduce segnificantly the chances of a session being guessed and hijacked in case that the session IDs are large random numbers, but it will obviously help greatly if the session IDs are custom like incrementing IDs, which is possible in ExpressJS.

Users can use whatever session IDs they want. Perhaps someone feels like they should use an auto incrementing number from the SQL database, it doesn't matter, because we protect their uninformed decision by signing the value, elongating the key.

My confusion was between server-side sessions and client-side sessions. Before today, I had not known about client-side. A clear explanation of the difference is found below.

Why CherryPy session does not require a secret key?

Thinking of the server-side model, I was very confused where encryption would be required in sessions.