Enforce master password strength

project:self-host

#1

Hi,

Would be nice to be able to enforce master password strength.
Think about company logins shared in an organization, and some people using weak master passwords…
Would then be nice to be able to define some rules each master password would have to follow :

  • minimal length ;
  • character classes ;
  • uppercase / lowercase ;

For example in the configuration file of a self-hosted Bitwarden instance.
Or in the settings of an organization, when users are invited to register.

Thank you !


Warn users about using a weak master password
#3

The intent here is good but anyone with interest in a feature such as this ought to read the following post by Jeff Atwood: https://blog.codinghorror.com/password-rules-are-bullshit/.


#4

Hi @kspearrin,

I’ve seen you’ve just implemented master password strength verification in web vault, advising user to choose a stronger password if needed. Nice !

Would be nice to give the server admin the ability to enforce master password strength so that user can’t use a weak password.
Technically, selecting character classes (lowercase, uppercase, numbers, special characters…) to enforce, and a minimal length ? Or simply a regex in the server configuration file…

Then, you could add such generated rule as a pattern option to the HTML form field, for example :
pattern="(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[^0-9a-zA-Z])[^\0]{16,}"
Which is : numbers, lowercases, uppercases and special characters required, with a min length of 16.

Of course this does not prevent a “malicious” user to bypass the constraint (but why would he do this ?!), but as verification can’t be done on server side, I see no other way.

Many thanks :+1:


#5

Enforce LENGTH, not complexity. Complexity rules are proven to reduce usability and lead to patterns in the DB since almost all users simply add !1

If you’re still using password complexity requirements in your organization you are 10 years behind. As in it was 10 years ago that the person at NIST started recommending them and now the same person at NIST is recommending against them.


#6

I d’ont see why forcing users to use various character classes in their master password would lead to security issues. The character range to use in a brute-force attack would simply be larger.
Anyway, let’s then give the admin the ability to enforce a rule of his choice :slight_smile:


#7

Forcing password rules such as specific characters and forced reset is funny because many compliance regulations require it because NIST used to recommend them, but now that NIST recommends AGAINST them… it’s taking a while for regulators to change the rules


#8

Password complexity rules are a road to hell. I can’t tell you how many times I’ve encountered sites or apps that either had documented password rules that differed from what the resource actually allowed or required, or that had rules, but didn’t document them at all, which forced rage-inducing repeated guesswork.

If nothing else, making password creation unduly onerous makes users write them down. I have a wall full of Post-it Notes, because at work (1) I have to abide by certain password rules; (2) I cannot use a password manager like Bitwarden; and (3) I cannot opt to use a security key instead. What choice do I have? Reset constantly (not feasible), or write them down. I recently stuffed all the Post-it Notes in my backpack, right with my laptop. Immensely insecure, but I feel I’ve been left with no real choice.

People forced to use hard-to-remember Bitwarden master passwords will likely write them down also.

From an article linked to by another user:

Password rules are bullshit

  • They don’t work.
  • They heavily penalize your ideal audience, people that use real random password generators. Hey guess what, that password randomly didn’t have a number or symbol in it. I just double checked my math textbook, and yep, it’s possible. I’m pretty sure.
  • They frustrate average users, who then become uncooperative and use “creative” workarounds that make their passwords less secure.
  • They are often wrong, in the sense that the rules chosen are grossly incomplete and/or insane, per the many shaming links I’ve shared above.
  • Seriously, for the love of God , stop with this arbitrary password rule nonsense already. If you won’t take my word for it, read this 2016 NIST password rules recommendation. It’s right there, “no composition rules”. However, I do see one error, it should have said “no bullshit composition rules”.

Also (coincidentally, from my perspective), LifeHacker posted this article today: How Password Constraints Give You a False Sense of Security.


#9

So, what are the drawbacks implied by forcing users to have their master-password (and only their master-password, without expiration) constrained by my previous example rule ?
(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[^0-9a-zA-Z])[^\0]{16,}

My main concern is to avoid having users choosing master-passwords such as “hello” to protect shared company collection items.
I think any user can easily imagine a “passphrase” he could easily remember, following the enforced rule.


#10

I believe the idea is that such constraints reduce the pool of possible passwords, and with fewer possible passwords, they are easier to defeat. Not that all constraints are bad.


#11

I asked a friend of mine who sucks at passwords:

“If I asked you to make a password 8 or more characters with 3 types out of 4 (lowercase, uppercase, numbers, or symbols) would you use a password you already have for other sites?”

He said “yup” I asked “how long is that password?” he said “8 characters”

Let’s say his password was Dogs4ev!

Rather, if we just say “15 characters or longer”

lovedogsforever seems like something that person might come up with.

Looking at it from a simple brute force perspective: even with lowercase only and no numbers 70 bits or more entropy could be contained.

Looking at it from a dictionary perspective: 3 words from a dictionary of 4096 common words is 36 bits, plus plural-non-plural is around one bit for each word for nouns only, so 38 ish bits.

Meanwhile, 8 character password can only hold 48 bits max entropy even with 66 types of characters…

But in actuality, many people reuse passwords that are 8 characters around all websites, there are very few patterns using 1 dictionary word with numbers and capitalization ending with ! usually… these are probably less than 20 bits of guessing…

This can be best summed up by xkcd. “correct horse battery staple” is 28 long btw. 25 without spaces. Even if you made each word 4 letters 4 words with no spaces would be 16 characters long.

3 words would be 5 letters each without spaces.

Which is why I say 15 or longer… the only “rules” I might enforce are:

  1. not all numbers and spaces
  2. No sequences: 1234567890, abcdefg…, qwertyuiopasdfghjklzxcvbnm, whatever the azerty keyboard order is etc.
  3. No repeats longer than 3 characters. prevents “padding” (my pw is 15 zeroes!!! etc.)… 3 because many words use repeats of 2, and maybe there are some words with 3 same letters in some language… but 4 or more is just padding.

#12

An interesting case from history:

I recently visited the Bletchley Park museum, where you can learn loads of stuff about how they cracked Enigma in WWII. A feature of Enigma was that a letter in the cipher text would never stand for itself in the clear text. This constraint had been added by the designers in a belief it strengthened the encryption. In reality, this one rule was a major help to the codebreakers because it reduced the entropy and hence the possibilities to be searched.

This misunderstanding about encryption rules has been going on a long time!


#13

Based on the master password strength verification in web vault, here is another idea.
We could :

  • force a minimal length (greater than the default 8 characters) ;
  • force a minimal password score (good, strong).

User could then choose characters he wants, be it would be sure his master password is long enough, and is good or strong enough.

Thank you @kspearrin :+1:


#14

Password strength enforcement is worthwhile if it is done well, not stupidly. People have outlined above many of the ways in which it is often done stupidly, leading to a net decrease in security rather than an increase.

See, e.g., https://github.com/dropbox/zxcvbn, for a good password strength estimator.

I don’t know how Bitwarden did it in the web vault, but I hope they were smart about it. :wink:

I agree that it should be possible for organizations to enforce password strength requirements.


#15

We use zxcvbn for password strength testing.