Simple improvements to password validation

We previously tried to implement a “password strength indicator” into Ghost (ref #5309), but got stuck on the libraries being too big. However, in abandoning strength indication, we’ve totally missed out on adding very simple rules to prevent the most obvious and heinous of password mistakes.

We want to both increase the minimum length for passwords, and add a couple of very simple rules.

The most important thing about these new validation rules, is that they MUST not interfere with existing users being able to login or save their profile. The new validation rules must also not prevent old blog content from being imported. They should ensure that a user creating an account, or changing a password, get validated more strongly.

The first 3 tasks go together, to cover making a single change to these rules and then ensuring that it doesn’t impact anything it shouldn’t. Once that is done, each of the following rules can be added one-by-one.

Increase minimum length:

• Increase password minimum from 8 to 10 characters (ensure it is messaged properly)
• Testing to ensure this does not impact on saving user profiles, imports or any other user-based action where the password is not being changed.
• Improve importer logic, see notes below

Add simple rules:

• Design note: adding rules will require a new validation error message, this will need to be run past @JohnONolan
• Disallow obviously bad passwords: 1234567890, qwertyuiop, asdfghjkl; and abcdefghij.
• Disallow passwords that contain the words “password” or “ghost”
• Disallow passwords that match the user’s email address
• Disallow passwords that match the blog domain
• Add a very simple entropy measure with a cut off e.g. if 50% or more of characters are the same - this prevents ‘aaaaaaaaaa’ and ‘ababababab’ style passwords.

Advanced changes (these are for a new issue, later):

• Research an advanced entropy measure, with a score system
• Maybe add a larger library, but using lazy loading (this is now possible)
• Add a signal strength indicator to the UI

Ref material: https://blog.codinghorror.com/password-rules-are-bullshit/

Notes on Import rules:

At the moment, our import rules for passwords are a bit weird. There are 2 modes:

1. “importPersistUser” mode, is a special mode in which users should be persisted exactly as they were. No validations should be run.
2. “normal” mode, in which we expect to be importing a JSON file which is an original export, but it may also be user generated. Here, validations should run but the outcome is slightly different…

Validating the field should be a case of: Check if the contents of the field is a hash:

• If it is a hash, don’t need to validate, re-hash-the-hash, store that.
• If it is not a hash, all the normal password validation rules should be run, then hash.

@kirrg001 can you confirm this logic please?

[ermyril]

Hello!

Sorry for bumping an old issue, it’s more like a feature request, but please add more descriptive validation errors. It’s definitely not obvious what’s wrong when an application just tells you “Sorry, you cannot use an insecure password” when you’re just typed something like “GhostinglyCrypticGibberish8*5%”

[JohnONolan]

Sorry for the ambiguous error message! Usually shows up if you’re using “ghost” as part of the password - which I agree is confusing. We’ll update