search

OWASP / ASVS

Application Security Verification Standard
Creative Commons Attribution Share Alike 4.0 International
2.72k stars 664 forks source link

2.1.8 Password Strength Meter Question #622

Closed jamesjardine closed 5 years ago

jamesjardine commented 5 years ago

The requirement is for a password strength meter, and I saw the other questions that show that research says they help people choose stronger passwords. My question is with 2.1.9 stating there should be no complexity requirements, what is a strength meter measuring? Is it solely on the number of characters? I haven't looked at the research that says it helps people pick stronger passwords, but seems to me that complexity is out, length is in, so what are the key indicators that we should be checking for?

mastacheata commented 5 years ago

Complexity in terms of character space is only going to protect you against easy dictionary based passwords. You CAN point users to choosing passwords with numbers and symbols, but usually that only makes sense for short length passwords. As soon as a certain length is crossed (the standard suggests 12 characters), complexity basically doesn't matter anymore (given the user didn't choose anything from the dictionary or personally identfyable information)

(i.e. "1WorldTradeCenter" is better than "Password", but it's not really a good password and "P@ssw0rd" is a really bad attempt at choosing a password that meets complexity requirements)

jamesjardine commented 5 years ago

Thanks. I understand how passwords work. I guess my question is, by removing complexity requirements and just going with length, what is the point of 2.1.8? Ok, maybe not the point, since there are so many references to some research that says it helps people choose a better password.. but what is the password strength meter supposed to work on? If I were to go to a client and say, "hey, you should implement a password strength meter" I need to be able to identify what that actually means. What is the meter checking? In 2.1.9, the requirement is to not have complexity requirements. So, if the strength meter is not checking for complexity, what is it checking for? Is it as simple as just checking that the length is sufficient?

mastacheata commented 5 years ago

I didn't design that requirement, but it's apparently imported from NIST 800 63b 5.1.1.2 They reference this document evaluating different password strength meters: https://madiba.encs.concordia.ca/~x_decarn/papers/password-meters-ndss2014.pdf

That study references the open source password strength meter from Dropbox as a good design: https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-strength-estimation/

Apparently the last person who touched that requirement was @vanderaj, but not sure if he decided to import that in the first place or if he/whoever did that just copied all the NIST requirements without checking their usefulness.

Personally I would not include a strength meter in my applications. It's misleading at best. People will think their password is safe if the meter fills up, but if they use that same password elsewhere and it gets leaked, the strength of the password doesn't matter at all. But that's just my opinion.

jamesjardine commented 5 years ago

To be honest, I would not include one either, and that is why I am questioning it. While I haven't dug into either of those, it looks like most of the information in those links are going back to 2012. I guess that makes sense since in 2012 they were recommending forcing users to comply with complexity requirements that required a number, capital, lowercase, and special character. My understanding is that currently NIST has dropped those requirements and turned the focus on the length of the password. If that is the case, then it seems that a password strength meter seems irrelevant unless all it is doing is showing stronger for each character you add over 12.

This really turns into an issue of working with application teams and using ASVS as a standard. If we cannot justify a requirement, then it makes things really difficult. I can't use this as a baseline approach for teams when I am saying (even at a level 1), oh, you don't need this, and you don't need to do that. There shouldn't be much question on whether something should be a requirement or something is just a nice to have. For me, this is similar to things like the requirement to temporarily show the password. Just because some devices or systems do this by default (like mobile devices), doesn't mean it is a must for every application. Especially since many people use password managers and just copy and paste their passwords into the box, they don't type them anyway. When we start adding on things people don't get, we start losing the ability to get the things we actually need done.

elarlang commented 5 years ago

The requirement is for a password strength meter, and I saw the other questions ...

Just for "documentation", this other question was/is #420

mastacheata commented 5 years ago

For me, this is similar to things like the requirement to temporarily show the password. Password managers are not that ubiquitious once you leave the tech scene. So these people will mistype and want to correct errors instead of having to retype the whole password.

This really turns into an issue of working with application teams and using ASVS as a standard. If we cannot justify a requirement, then it makes things really difficult. I can't use this as a baseline approach for teams when I am saying (even at a level 1), oh, you don't need this, and you don't need to do that. There shouldn't be much question on whether something should be a requirement or something is just a nice to have.

The ASVS is not mandated by a standardization body like ISO or IETF where many people have to vote on each change. At OWASP you can create an issue, make a suggestion and if a maintainer likes the idea or if you have enough random strangers supporting your idea it will most likely be included in the standard. The ASVS doesn't have any optional requirements and probably when picking up requirements from other standards some should better be left out, but that didn't happen here in time for the V4 release. (probably, because noone ever really thought about how to explain to a customer that this is a good requirement) It's unlikely for this requirement to drop out of V4.0.x anymore, but I would definitely vote for dropping it in 4.1 as well.

My understanding is that currently NIST has dropped those requirements and turned the focus on the length of the password.

That requirement for a password strength meter is included as a recommendation in the NIST standard as it is available on their website right now. It's not a strict-follow requirement, but only a recommended one. The ASVS has no means of declaring a requirement optional, but (at least in 3.0.1) the preface states that you shouldn't take the ASVS as is anyways and adapt it to the needs of your application, with the levels being more of a guideline than a strict border.

jamesjardine commented 5 years ago

I appreciate the response and the reference back to the other issue raised. Regarding the other issue, that PDF seems to be 4+ years old. I guess my question really should be, should this be changed from a standard to a recommendation. Maybe I take things a little too literal. When I see standard, I treat it as an audit tool where things are not really optional, unless you don't have certain functionality. In reality, this feels more like a great set of recommendations that people could look at, learn, and implement the ones that fit their application. Maybe it is just semantics, but I want to make sure that I am using the resources as they should be.

jamesjardine commented 5 years ago

To stay relevant to the original question, I do believe you have answered the question. i appreciate the information you have provided. I am closing the issue.