V6: Password strength meter is flawed and misleading

Open
  • Is something wrong?
#43,006 0 comments 2 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript
Domain
frontend, security

Research direction

The payload does not name the meter's source file, so first locate the password strength component in the v6 JavaScript sources and the scoring object it uses. Compare its current weights (length, character classes) with the proposed config in the issue. Done would mean a maintainer-agreed scoring model and a documentation note on composition rules, so expect the scope to be settled in the thread before any code change.

Written by the indexing model from the issue text.

Description

feature js v6

The new password strength meter does not reflect an understanding of actual password strength and how password attacks happen.

Checking for specific character classes overweights fake "complexity" and underweights length, especially with lengths beyond 15 that become impractical to brute force. Password possibilities = C^L where C is character set and L is length. Clearly length is exponentially more important than character variation, but the meter does not implement this simple mathematical understanding.

For example, the meter claims that n1*rA.Q6 is “stronger” than !)%^#*}/]]/ or {{{{---||||, but the last two passwords are significantly stronger because a) the characters are less probable, and b) they have ten characters instead of eight, adding 19 bits of entropy [log2(95^3)] and making them around 850,000 times harder to guess in an exhaustive search.

Worse, this component could be abused by clueless developers to implement composition rules, which are specifically forbidden in US National Institute of Standards and Technology (NIST) Digital Identity Guidelines.

As a guide, the meter is vaguely helpful, in spite of low scores for literally billions of strong passwords. At the very least it should have documentation added to explain the issues above and strongly discourage Bootstrap users from restricting password input based on score.

Even just changing the default scoring would help. The following is based on actual probability of characters in passwords, including how it affects Markov chains in hashcat and similar password cracking tools.

{
  minLength: 0.5,        // Meets minimum length
  extraLength: 1.5,      // 4+ characters over minimum
  lowercase: 0.1,        // Contains lowercase letters
  uppercase: 0.5,        // Contains uppercase letters
  numbers: 0.3,          // Contains numbers
  special: 0.7,          // Contains special characters
  multipleSpecial: 1,  // Multiple special characters
  longPassword: 4      // 16+ characters
}
Dominant language
MDX
Stars
175k
Forks
78.7k
Avg merge
1d 7h
Merged PRs (30d)
103

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from twbs/bootstrap

All issues in twbs/bootstrap

Similar issues

More Web Dev issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.