add password hardness evaluation

[eabili0]

No description provided.

[claudiosegala]

I already implement a way that the user can change it? Or it can be just on front-end and the endpoint of creating and update of users?

[eabili0]

A validation logic should exist both in the frontend (for feedback) and backend (for guarantee).

Hardness evaluation says to the user how strong the password actually is. The actual logic behind it has not yet been decided and is open for discussion. Any ideas?

One that I was thinking is not imposing the existence of certain characters (like so many identity managers do) but rather we should create an entropy heuristics taking in consideration:

1. cg how many character groups are used (numbers, special, normal);
2. d how many characters are different among each other; and
3. s overall size of the password.

These dimensions should then be multiplied by each other and we grade it according to specific thresholds.

Example:

Say we define a weak threshold to be 14, medium threshold to be 90, strong threshold to be 210. Then, the following passwords would be classified as:

• 11111 -> cg * d * s = 5 -> less than 14 (considered invalid);
• 11111111111111 -> cg * d * s = 14 -> equals to 14 (considered weak);
• 12345678912345 -> cg * d * s = 90 -> equals to 90 (considered medium);
• AG*642N+_321 -> cg * d * s = 396 -> above 210 (considered strong);

What do you think, @claudiosegala?

[eabili0]

Applying this heuristic with a hard rule of password size (ex. at least 12 chars), would be enough to add the security one expects from an identity manager, in my opinion.

[claudiosegala]

@abilioesteves I am worried that making this entropy might not be a good approach.

Your proposal

Advantages

• Password Size Rule alone limit a lot of weak passwords
• Shows the users that he is opting for a less secure password instead of blocking (passing the responsability to the user)

Disadvantages

• Hard to find a good threshold for invalid, weak, medium and strong
• Allow users to use weak passwords
• A little hard to tell the user why his password is invalid or weak
• Too long passwords might bother the user

My proposal

I am basing my proposal in a discussion I had with Erick and the articles Your Password is Too Damn Short and Password Rules Are Bullshit. In this article, we see that mainly we should be worried about the size of the password and make some recommendations which I agree with.

• Check the size of the password
• Check the number of unique characters in the password
• Try to check if the password is contained or contains user name, email,...
• Compare password with a dataset of leaked passwords
• Show a text about 'Things to avoid in passwords' by hovering over a help icon
• Make sure to control how many logins tries are allowed in a minute

Advantages

• Password Size Rule alone limit a lot of weak passwords
• Make it hard to use weak passwords
• It is possible to tell the user how to improve
• Consientize the user
• Does not allow password that was leaked

Disadvantages

• Too long passwords might bother the user

On this issue

If this approach is chosen, it would be advised to break into three issues. One to check the password with a dataset, another to control login tries and the last for the rest.

Observations

• By using 7 unique characters and password size of 12 or more would mean at least an entropy score of 84 on your entropy.
• Both methods would still allow 'claudiosegalarodrigues' as password, but the hover text would instruct the user to avoid it.

[erickmoreno]

Considering the directions taken in this issue, I would suggest that to implement the step cited as "Compare password with a dataset of leaked passwords" by @claudiosegala, we should consider the haveibeenpwned API.

[eabili0]

Awesome, @claudiosegala! I agree with you.

Have you thought about how we are going to communicate to the user how good/bad is his password, based on your proposal? I can see clearly the difference between valid and invalid passwords, but I don't see clearly how one can understand if his password needs any improvement.

@erickmoreno, thanks for your input!

[eabili0]

@erickmoreno, with regards to haveibeenpwned, how exactly would that fit into our password hardness evaluation policy?

The way I see, since we are using salts, how exactly would I ever get a match with their password database? Thanks!

[erickmoreno]

More than salts, we are using different hash algorithms.

Considering that, we cannot verify our already saved passwords. The call to this API must be done from the frontend as a step to prevent users from keep using already hacked/public passwords.

[eabili0]

So, after discussing with @erickmoreno, my understanding of this haveibeenpwned proposal is the following:

1. at registration/update we SHA1 the password and verify if the password attached to that email account/username has been leaked, by consuming an external service;

2. the dataset @claudiosegala has talked about would then be dynamic in nature, not static, which is a good thing;

3. since this mechanism's algorithm varies between our service and haveibeenpwned, we would't be able to generate 'password change' alerts, given that the probability of a match would be extremely low due to salt's randomness.

With that in mind, @erickmoreno, I see that there is a possible problem when the external service is unavailable. Do you have any fallback strategy in mind, in case we cannot communicate with haveibeenpwned? Maybe cache the hashes every time we communicate?

Also, I didn't understand why this communication needs to happen in the frontend. Shouldn't we just do it in the backend before password encryption?

Thanks!

[erickmoreno]

The fallback IMO is just let the user go on with the register process. We should never let this be a wall against the user, and we should never store the password either.

Regardless the frontend calling haveibeenpwned, I'm just assuming that the process to validate/verify the users password is been done on the frontend and we are not transmitting the plain text password across our services.

Te only requirement is that this must be done before any hash/encryption operation over the password, but can be placed where the other validations are been executed.

There's one more reason to put the call to any outside API on the backend, avoid possible network restrictions on the client side.

[eabili0]

The fallback IMO is just let the user go on with the register process. We should never let this be a wall against the user, and we should never store the password either.

I think matching the given password with a "password blacklist" of sorts, is imperative to improve our security standards. I would like to see this being done with haveibeenpwned but also with another fallback mechanism in case the communication with that service breaks.

There's one more reason to put the call to any outside API on the backend, avoid possible network restrictions on the client side.

This is exactly the reason why I questioned the point of putting this logic on the frontend. Since we cannot make assumptions regarding client network restrictions, we should definitely implement this logic on the backend. That would also be more reasonable given a fallback mechanism needs to be in place - which may require communication with a database and other components.

--

I'll open an issue to target this haveibeenpwned integration. Thanks @erickmoreno!

[eabili0]

With your guys inputs, our first policy should be the following:

1. Passwords must have at least 12 characters; (length)
2. At least 7 different characters; (entropy)
3. The password cannot be obvious, e.g. username or email (naiveness);

At this moment, there will be no feedback of how strong the password actually is, only if the password is strong enough to be acceptable or not.

A hover hint should be provided with the 3 rules above and an example of a strong password.

To be implemented in other issues:

4. Passwords will be matched against a "password blacklist";
5. Rate limit the number of requests to the login api;

@claudiosegala, please proceed with the implementation of the first 3 rules for this issue and the frontend details.

Thanks!

[claudiosegala]

@abilioesteves Do I create the issues for topics 4 and 5 you described?

[eabili0]

@claudiosegala, they have already been addressed: #30 and #31