New lesson: Session-based authentication #29082
Conversation
'Persisting logins' was a glorified intro anyway
Only up to the original login process
Reordered setup code blocks for easier content flow. Decided to introduce the session store and secret explanations here instead of their own sections later on (not really needed there).
New order allows for a more natural way of explaining how express-session populates req.session. That can be explained at the start and options explained to reflect that, instead of explaining options in a bit of a black hole then provide the context later in the lesson.
Made more sense to talk about logging out after logging in, then talk about password hashing afterwords.
Use subsections for better content organisation and linking
"Session-based authentication" is a more appropriate title for the lesson than just "Sessions", given that sessions are not exclusively used for auth purposes.
Makes sense to showcase them directly rather than just via text example after the fact
|
|
||
| #### Session store | ||
|
|
||
| Let's talk about our session config which we apply to every incoming request (by mounting it on `app`). Firstly, we use the [connect-pg-simple](https://www.npmjs.com/package/connect-pg-simple) library to make express-session store session data in our database (creating a "session" table if it does not already exist). Without this, sessions would be stored in memory by default which would not persist through any server restarts! |
There was a problem hiding this comment.
Is there pedagogical benefit to having the learner make their own sessions table and writing their own helper functions to do CRUD ops on them? If the aim of the lesson is to get to grips with sessions, I'm not sure it's a good idea to abstract away the actual persistent session info
There was a problem hiding this comment.
Possibly. My understanding from prior discussion (which may be flawed) was to stay with express-session but handle it manually rather than as part of passport and its strategies. But if @01zulfi thinks it'll be even better to do this lesson with properly manual session management then the lesson can be amended accordingly.
|
|
||
| By far the worst way we can store passwords is to just store them in plaintext like we've done in our example app earlier. Even if we encrypted the passwords, all an attacker would need is the key to decrypt all the passwords. Let's face it, if someone managed to gain access to your database, it probably wouldn't be very hard for them to get the encryption key (assuming they don't already have it). | ||
|
|
||
| Remember [hash functions](https://www.theodinproject.com/lessons/javascript-hashmap-data-structure#what-is-a-hash-code) from the Hashmap lesson? We want to hash our passwords, then store the hash since hashes are one-way functions. We also want to [salt](https://en.wikipedia.org/wiki/Salt_(cryptography)) the password when hashing to prevent identical passwords from being stored with identical hashes. On top of all that, we also want the hash function to be purposely slow - not so slow that a normal user will be waiting ages just to log in but certainly slow enough to minimize the number of attempts an attacker might be able to make in a given amount of time. |
There was a problem hiding this comment.
I think "prevent identical passwords from being stored with identical hashes" doesn't do the best job at making the point. I can see that we don't want to rabbit hole into rainbow tables here, but I wonder if "prevent attackers being able to compare hashes against precomputed hashes of common passwords" is just enough to get the idea across
| const user = rows[0]; | ||
|
|
||
| // argon2.verify requires an argon2 hash as the first argument | ||
| // so we must early return if there is no matching user |
There was a problem hiding this comment.
There's a timing attack here, which leaks usernames. Do we think a note about this? Or just ignore it
There was a problem hiding this comment.
I'm surprised I glossed over this, considering I mention generic validation feedback earlier in the lesson. Will address this - thinking of using a predetermined argon2id hash as a fallback if user?.password short circuits so that argon2.verify() can still run fine. Then only go down the happy path if both user exists and password matches.
Any alternative suggestions?
There was a problem hiding this comment.
That's probably the simplest approach. You probably want to pick a huge random string to hash, since if you use something that someone actually tries as a password, you might accidentally grant a session to a user that doesn't exist. Maybe hash a uuid.
Obligatory I am not a cybersec guy message.
Or some logic such that if you use the fallback, you return false regardless, and the verify is awaited only as time wasting
There was a problem hiding this comment.
Yeah, the random argon2 hash would just be to force the hash verification. Then change the following conditional to if (user && isMatchingPassword)
Because
As part of the Node revamp's 2nd milestone
This PR
Issue
Closes #28847
Additional Information
Pull Request Requirements
location of change: brief description of changeformat, e.g.Intro to HTML and CSS lesson: Fix link textBecausesection summarizes the reason for this PRThis PRsection has a bullet point list describing the changes in this PRIssuesection