CODEWITHSUNDEEP
phpnode.jssessionexpress
gluxon
gluxon

Reputation: 770

Importance of session secret key in Express web framework

I'm quite confused by the importance of a session secret. I'm jumping into web development with Express and Node, and at the moment, I'm trying to implement a simple login. The below code is taken from the sessions example in Express.

// Required by session() middleware
// pass the secret for signed cookies
// (required by session())
app.use(express.cookieParser('keyboard cat'));

// Populates req.session
app.use(express.session());

It uses "keyboard cat" as a session secret. Many of the things I've looked around about session secrets recommend me to change this to something custom. I now have 3 specific questions concerning this.

  1. Why have I not seen this before when I was working with PHP?
  2. What is the session secret being used for exactly?
  3. Let's say I change the session key. My code is open source. Won't changing this be a bit redundant in that case? I don't see asking the user for a custom key as an option.
  4. I was thinking of generating a random UUID to fill in the key. Are there problems with this? (in terms of security)

Upvotes: 34

Views: 21292

Answers (3)

Mike 'Pomax' Kamermans
Mike 'Pomax' Kamermans

Reputation: 53665

  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):

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

app.js:

const dotenv = require("dotenv");
dotenv.config();

const express = require("express");
const app = express();

const compression = require("compression");
app.use(compression({ filter: shouldCompress }));

const bodyParser = require("body-parser");
app.use(bodyParser.urlencoded({ extended: false }));
app.use(bodyParser.json());

const cookieParser = require("cookie-parser");
app.use(cookieParser());

const cookieSession = require("cookie-session");
app.use(
  cookieSession({
    name: "session",
    keys: [process.env.SESSION_SECRET],
    maxAge: 2678400000, // 31 days
  })
);

const helmet = require("helmet");
app.use(helmet());

app.listen(...)

Where helmet takes care of the kind of security settings that none of us can remember (cors, csp, etc)

Upvotes: 44

argaz
argaz

Reputation: 1488

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.

Upvotes: 13

gluxon
gluxon

Reputation: 770

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.

Upvotes: 3

Related Questions