Replies: 3 comments 4 replies
-
FWIW, "BR1@N Thompson password" on https://www.passwordmonster.com/ is classed as weak with a crack time of 19.25 minutes. That is without the user's name being known... |
Beta Was this translation helpful? Give feedback.
-
Hey, thanks for the testing the the new password test page. Differences in scoring Customer matcher To only use one matcher you could use the option directly, access the matcher and generate a new instance of it
With the results of the dictionary matcher you could proceed with your own implementation. New password checker page I would move this issue to the discussion tab if it's fine for you. |
Beta Was this translation helpful? Give feedback.
-
I might be a little confused here but is there any way to use a custom matcher (or any other method) to have a password fail/score low in the case where it contains certain strings, so I could have a password fail if "Brian Thompson" (and possibly any l33ts of it) are found in the string? Thanks. |
Beta Was this translation helpful? Give feedback.
-
I may well be missing something here, but this example appears to be very insecure: -
const userInputs = ["Brian Thompson"]
I've ran the following tests and there are the result: -
TEST 1
Password: "Brian Thompson"
TEST 2
Password: "Brian Thompson " (note the space at the end)
TEST 3
Password: "Brian Thompson password"
TEST 4
Password: "Brian Thompson 1234"
In test 1, it rightly gives a score of zero and a warning for "Brian Thompson" as "Brian Thompson" is a user input.
In test 2, a single trailing white space will give a score other than 0 and a warning.
In test 3, "Brian Thompson password" will give a score of 3 and no warnings/suggestions, despite it seems to be what should be considered a low (or lower) entropy password assuming the attacker has the user's name. This would seem to be an error that should be addressed as I think it creates opportunity for weak passwords.
In test 4, a password of "Brian Thompson 1234" - which I think we should consider to have a similar entropy/obviousness to that of test 3 - returns a score of 2 with warnings/suggestions. Is this not inconsistent with test 3's feedback?
Also, should there not just be a case for the failing of a password if it has "Brian Thompson" or a l33t of "Brian Thompson" anywhere in the password string? Should we not consider user input + " password" to be rather obvious?
The user can write their own function to check the password for substrings of user inputs but this is 1) hackish 2) difficult to take into account l33t as l33t would have to be done by a separate package (unless the zxcvbn-ts l33t function can be made available for direct import).
Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions