Different ways to authenticate

• Cookie-based authentication
  • The server stores the session id.
• Token-based authentication
  • JSON Web Token (JWT)
  • The server does not store the token.
• Third-party access, OpenId Connect, SAML

The authentication method you choose to use depends on the type of application. For a web application, cookie- or token-based authentication is often appropriate.

Cookie-based authentication

Password security (for the user)

• Passphrase instead of password?
• NEVER ever use the same password on multiple sites!
• Always turn on two-factor authentication (2FA) if it is an option.
• Do not try to remember your passwords, use a password manager.
  • A password should be 10 characters long, minimum; the longer the better.
  • Using numbers and/or special characters does not make a password stronger.
• Never give an honest answer to a password recovery question.
  • Generate a random password and store it in your password manager.

Password security (for the server)

• Managing passwords is risky and complex!
• Send passwords only over HTTPS.
• Passwords should be stored in an hashed format using strong cryptographic algorithms.
  • A password should never be able to be read back!
  • Always hash a password using a secure hashing algoritm (Argon2, bcrypt, scrypt) before storing it.
    • Avoid MD5, SHA1, SHA2, SHA3, SHA256, etc., because they are not safe password hashing algorithms.
  • Allow looooong passwords.

Rainbow tables

• A rainbow table is a precomputed table with hashed "known passwords" for cracking passwords.

• A rainbow table attack is easily prevented by using salt techniques.

Salting

• Rainbow tables becomes useless by adding a small chunk of random data, called a salt, to the password before it is hashed.
• The same password has different hashes if the salt is unique to each user.

Authorize on the server

• The server must perform the authorization because the request coming from a client cannot be trusted.
  • It is not sufficient to simply hide the delete button at the client from a user that are not allowed to delete something at the server.
• Your authorization process should always, in a perfect world, prevent access to requested resources by default.
  • It is safer to prevent access by default and override any requests that do not require permission.
• Resource authorization can be complex because it validates whether or not a user allowed access to a specific resource.
  • A user should be able to modify their profile and only their own profile.
  • It is easy to allow access to a resource if the user just needs to be logged in.

How to manage login

• The user submits a login form and the credentials are compared with the data in the database.
  • Create a new session cookie, store user data in session store, and redirect.
  • If the authentication fails show a custom flash error message or send the status code 401 Unauthorized.
  • Applying the principle of separation of concerns is a good idea by adding static methods to the Mongoose schema to authenticate users.
• (Do not forget to give the user a possibility to log off!)

Authenticating a user (1 of 2)

• Lookup the user in the database and compare, using a 'constant-time' algorithm, the provided password with the hashed one from the database.
  • If the authentication fails, throw an error, otherwise, return an object representing the user.

Authenticating a user (2 of 2)

• Regenerate a session cookie, store user data in the session store, and redirect.
• If the authentication fails redirect to the login page and show an error message (or send the status code 401).

How to authorize

• When defining a route you can provide multiple callbacks. You can use this mechanism to authorize the requested resource.