Password assistant

[milstan]

Context (historical)

To access our system users are required to set a password. And passwords are a good thing, the use of which we like to promote over passworldess login. However, to have a strong-enough password, users are often required to include a certain complexity making the password more difficult to remember.

Why is this an issue

• Presented with a requirement that their password MUST containt X or Y, the users get frustrated and build up resentment against the system. The requirments seem arbitrary (as they vary from system to system) and do not make much sense
• The lack of context exposes the users to even greater risks then what the choise of a weak password would. For instance, the users, not really understanding the reasons behind those requirements, find quick ways to fulfill a requirement - they add caracters they can't remember and then they write the password down.

What should we do about it

• Present an obejctive password strenght metric, making the requirement for a complex password look less arbitrary; and then present mandatory complexities (1 uppercase, 1 lowercase, 1 number or 1 special caracter, longer password) as ideas how to match a sufficient level of complexity. That way, rather than perceiving those constraints as a requirements he must fullfill, the user perceives them as means to an end - an obejctively secure password.
• Ideally, instead of presenting mandates (1 uppercase, 1 lowercase, 1 number or 1 special caracter, longer password) present in the notifaction on the right side a general goal "Pick a password difficult to crack. Make sur you can remmeber it and don't have to write it down or use a secure password mamagement system like bitwarden". At every stroke of the user calculate the objective password strenght score, and give hints how to improve the score.
• To calculate the objective password strenght score, we shall make a component "Password assistant"

High-level Password assistant specification Password assistant is a software component operating in the front end. It takes as an input a string (set of caracters currently typed by the user as password), and returns a set of results including:

• a numeric password strenght score (can be a descret number)
• a textual description of the numeric score. The password asssitant has a table of descriptions corresponding to particular score ranges. For instace for small values of the score the corresponding description would be "A cheap computer can break this password in 8 minutes". For a better one the description could be "A cheap computer can break this password in 10 days. You can certainly pick a better password.", for an even better score "To break this password one would need a super computer, but then they could brek it in a day. You deserve a better password. Anyone can get a supercomputer nowadays". and so on. The textual descriptions should be configurable. There can be one correspondance table (values - descriptions) per language. The language can be a parameter of the Password assistant. The texts should be modifiable without modifiying the code of the Password Assistant. the numeric password strengh score together with corresponding descritpions can be engineered according to the calculation given in this article or some other article having dealt with the evaluation of password strenght.
• a boolean value indicating whether the password is acceptable or not (acceptable numeric password strenght score trashold and/or acceptebale minimal sets of compexities among {minLenght, lowercase,uppercase,numer,specialChar} can be defined as parameters of Password Assistant; minimal acceptable lenght minLenght is also a parameter).
• a textual improvement suggestion. Taking into account the complexities already present in the string, suggest the user to add some of the additional not yet used complexities (among minLenght, lowercase,uppercase,numer,specialChar). For every situation of the existing string, there is a corresponding text presenting remaining complexity opportunities (this correspondance table can be in different languages, language being a parameter of the Password Assistant, and the actual texts can be cahnged without changing the code of the Password Assistant.

The "Password Assistant by blindnet" can be exposed as an open soruce tool.

Goals

• Design an elegant, minimal and useful component that allows to make a shift from "secruity through constraint" to "security through pedadogy"
• Should be both a part of Data Consumer Interface and as something that that can be reused by a larger community.
• Community engagement, impact and notoriety trhough 3rd party adoption of the Password Assistant
• Users of Data Consumer Interface have good enough passwords

Subtasks

• [ ] #693
• [ ] Decide on monorepo manager

[m4rk055]

https://github.com/tests-always-included/password-strength JS library for estimating pass strength. Contains all the features you listed. It uses two techniques: Trigraph entropy bits and Shanon entropy bits and warns about common passwords.

I also think we should use entropy bits rather than fixed set of rules to estimate a strength of a password (if there are no legal restrictions for fixed rules). A password with 100 lowercase characters is strong but doesn't pass our validation.

[milstan]

Great. Let's use it to give information to the user about the password strenght.

We might use the rules as hints, such that the user might increase entropy. If they are mandatory we can say so. I think showing the entropy score is still (regardless of madates) a good way to motivate the user to pick a better password and not resent the system for it.

If there are legal mandates, and the user manages to hit a high-entropy password that doeas not fit a legal mandate, we can tell the users how stupid their government is. I am joking, obviousely. The user is unlikely to spontaneousely come up with a password that has high entropy and does not statisfy the mandate.

@Vuk-BN can you please remind us of the document you once showed that specified password strenght mandates in the USA?

[Vuk-BN]

SOC2 compliance is a set of criteria to evaluate companies on their readiness to protect sensitive information. It is not a prescriptive document, rather a set of criteria a back-end system needs to fulfill.

Check this out >> https://secureframe.com/blog/soc-2-compliance-checklist

[m4rk055]

Seems the password requirements are not explicitly mentioned in SOC 2. I only found the guidelines which are min 8 char, lower, upper, number and symbol.

Quote from this article: | Alternatively, passwords/phrases must have a strength (entropy) at least equivalent to the parameters specified above.

So we might add entropy requirement instead (e.g. pass needs to have over 32 bits of entropy).