jsha
Use a sessions table to authenticate users
Right now when a user logs in we store their access token and secret in the Express cookie session, and use that to authenticate subsequent requests. The cookie session should be safe from theft because it is marked both HTTPOnly and secure. However, it's larger than necessary and including this data is not best practice. Instead we should have a server-side session table and a random session id in a user's cookie that gets looked up in that table to authenticate them. We should use pre-existing middleware for this.
Thinking of tackling this one next.
Looking at [email protected] since it's a maintained, lightweight middleware built for our stack.
Latest versions depend on sequelize >= 2.0.0-dev12, but 1.0.0 could be rolled into current app as-is.
Worth pursuing? :+1: :-1:?
This ticket is worth pursuing. The library you linked looks promising, though it appears to have a subtle timing issue that I recently fixed in BlockTogether. See http://codahale.com/a-lesson-in-timing-attacks/ for background on timing attacks. The issue is that an attacker should not be able to one-by-one guess characters in a session cookie based on timing information. Even when a field is indexed using a hash index, DB lookup is not designed to not leak timing information. One way to fix is to look up on part of the sid (enough to return just one result), then compare the rest of the sid using constant-time compare (e.g. scmp library).
The other thing I notice about this library is that it doesn't have any process to generate sids. We can do this ourselves, of course, but this is one of the things I'd expect in a session library, so it feels like this library is a bit slim (perhaps intentionally so). Would you mind poking around a bit more to see what else is out there?
Thanks, Jacob
Update: connect-sequelize is a fork that diverged prior to sequelize 2 migration to fix a major error, and has its own npm package.
These middleware pass express-session's autogenerated sid through to sequelize layer. That defaults to a 24-byte uid generated with uid-safe, but can be overridden if needed.
The only other express/connect middleware for a sequelize session store is c3store, which has essentially the same functionality (including lack of constant-time compare) but is written in coffeescript.
In short: I'll look into best-practice for preventing timing attacks in get/set queries as used in connect-sequelize and submit a PR. If maintainer accepts and pushes to npm we should be in a good place. If not, there aren't any better options ready at hand.