-
Notifications
You must be signed in to change notification settings - Fork 366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Authenticator.verifyPasswordStrength thinks "password123" is a good password #36
Comments
From chrisisbeef on October 28, 2009 22:02:53 This algo needs to be addressed for ESAPI 2.1 or 3.0. At this point in time, I would At the point that we address this, a good deal of the functionality that is in the Status: Accepted |
From chrisisbeef on October 28, 2009 22:11:22 Labels: -Release-2.1 Milestone-Release2.1 |
From kevin.w.wall@gmail.com on May 08, 2010 18:59:41 Agree that this whole algorithm needs to be addressed. The best approach would be to |
From manico.james@gmail.com on November 06, 2010 23:41:42 In FileBasedAuthenticator, I just noticed there were several additions
So, my question is "why is this check not part of the password strength I'd propose moving a check like this into the the public Alternately, we could generalize it even more by separating this out of |
From manico.james@gmail.com on November 06, 2010 23:41:51 Labels: -Milestone-Release2.1 Milestone-Release2.0 |
From chrisisbeef on November 20, 2010 13:16:06 Labels: Component-Authenticator |
@kwwall , while we were working to resolve the intermittent test failures From the FileBasedAuthenticator it was suggested on a couple of occasions that the implementation may not be as "production worthy" as we'd like. I believe at one point we were discussing either deprecating the impl or moving it into test scope to discourage its use. With that in mind, is this issue work that we want to maintain? |
We either need to fix it or deprecate it. Ideally, when you deprecate something, we ought to replace it with something (better). Generally an annotation like: That said, I do have a few ideas, but I'd prefer to wait to implement them after we kick out this release. |
Sounds good. I'll try to follow up with you after the release. |
From cyounk...@gmail.com on August 04, 2009 11:11:31
In AuthenticatorTest.java there is this test:
try {
instance.verifyPasswordStrength("password", "password123");
fail();
}
catch ...
The test passes, indicating that verifyPasswordStrength raised an exception
about the password quality, but only because it is too similar to the
previous password (the first param). Passing in an empty string instead of
"password" will cause the test to fail, because in the default
implementation, "password123" will have a "strength" of 22. 11 chars * 2
charsets = strength of 22, which is > than the 16 limit. Can't we come up
with a better metric? A couple suggestions:
new password. Also, make generateStrongPassword call verifyPasswordStrength
before returning output.
compare the password to a dictionary list, and that the default
implementation does not do this.
about number of bits of entropy? First, check what charsets are being used.
Add up the length of the charactersets in use, yielding the length of the
whole charset of the password, N. The entropy per symbol is then log(N)
base 2, and multiplied by the length of the password will give its entropy
in bits.
This metric is less valid for human-generated passwords. An alternative is
to up the strength limit. What version of the product are you using? On what operating system? SVN revision 574 .
Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=26
The text was updated successfully, but these errors were encountered: