Security checklist..

[dberesford]

Some overlap with #48 but want to be sure we support this:

• Can the application support the below shown password strength requirements:
  • Password must be at least 8 characters long and meet at least two of the following conditions: Mix of letters and numbers , Mix of upper and lower case letters and Special characters (e.g., # & * ! $)
  • configurable password age
  • configurable password history
• Is the user required to change their password after the first logon?
• Is the password masked while being entered on the screen?
• Are credentials stored encrypted or hashed?
• Is the Auto-Complete feature on the login page turned off?
• Does the application account lockout trigger after 5 or less failed attempts?
• Do you have a documented process to unlock an account?
• Do you ensure that application configuration files do not store the username or password?
• Do you have a documented process to recover a forgotten password?
• Does the application show a generic error message when an incorrect username and/or password are entered without revealing which one is incorrect?
• Is the application designed not to allow browser caching of user’s login?

[AdrianRossouw]

From the v2 roadmap in #58 ...

logs

• any action taken by any user should be logged (login, logout, create user, renew session, change password, etc.)
• preference for logging to stdout/stderr as it is the unix standard and leaves it to the system to handle logs but direct to files is ok
• do not log sensitive information (email/passwords are sensitive information), username ok.
• log client's IP address
• log timestamp (millisec accuracy)

settings

• Ability to restrict passwords to follow some rules. For example:
  • at least N chars and any 2 of:
    • mix of numbers and letters
    • mix of upper and lower case letters
    • special characters
• Password storage is through a salted hash with the iteration count configurable and updatable during the lifespan of the application
• Sensitive application configuration done through ENV variables and not stored on the file system (eg. DB credentials, cookie secret, etc.)
• cookies must be HTTPS-only in production
• session timeout should be configurable (at least in minutes)

session

• session IDs must be unpredictable (/dev/random based). A hashing algorithm - however long and complex - never adds entropy
• logout must destroy the session token immediately
• only 1 session per user at a given time (login destroys an existing session)
• session cookies have no un-encrypted sensitive information

data validation

• prevent script injections
• validate length of user inputs

Error handling

• server errors don't leak stack traces, SQL error or any sensitive information to the client.

Misc

• CSRF protection
• Automatic disabling of accounts after N unsuccessful logins. Administrator action needed.
• Administrators can never know a user's password. On-boarding can be done through a reset link sent by email
• Reset password can be done by pre-registered users themselves, with configurable expiry of the reset token
• Force users to change password every N days
• Disable users after 180 days of inactivity
• Return generic error when incorrect credentials are entered

[AdrianRossouw]

From those, the biggest missing feature is that it doesn't support account lockout at the moment.

The next biggest warning sign is forcing password changes every N days, which could imply keeping track of the previous password.

But more than that, when taken with the configurable salt + iteration count, it could mean we need to keep track of when passwords were created, and the previous iteration count.

[mirceaalexandru]

We might need to overwrite some seneca actions from seneca-user. Right now the implementation of seneca-user is using the iteration count from seneca-user's options:

https://github.com/senecajs/seneca-user/blob/master/user.js#L381

On the other hand we can change the seneca-user implementation to allow specifying on change_password and register user a specific rounds value - but as you said, this should then be saved in the user entity - and make sure is not reported externally, when the retrieve user action is executed.

[mirceaalexandru]

Another thing about:

• Password storage is through a salted hash with the iteration count configurable and updatable during the lifespan of the application

is that in the current implementation the iteration count cannot be changed during the lifespan of the application, as if we are changing it, the existing users will not be able to login anymore until they will reset their passwords. So we should save the iteration count in the user entity.