acsploit #60
Comments
|
Their password to check against us is now no problem, it's taken care of by the max length configuration implemented here: c387d54 The code that generated this password: https://github.com/twosixlabs/acsploit/blob/fd5602adf9f312482b8010abf6b4691f08929bc4/acsploit/exploits/passwords/zxcvbn.py It still takes ~400ms to calculate, but that can can be worked on separately. This got rid of the pathological case by default. |
This was referenced Jan 26, 2023
|
As @formigarafa mentioned here: #74 (comment) I went an implemented a check for dictionary max length to short cut a lot of logic. In the dev branch, this is now running in ~70ms with the password limited to 256 characters total: |
|
There was another exploit mentioned in the main zxcvbn repo: dropbox/zxcvbn#327 This has to do with the lazyAnchored check we do in the repeat matcher, but it isn't being hit for us now as mentioned in that thread. |
|
I found a blog post explaining the exploit from the authors: https://twosixtech.com/algorithmic-complexity-vulnerabilities-an-introduction/ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I noticed that nbvcxz was mentioned as being targeted by: https://github.com/twosixlabs/acsploit
Ensure the generated passwords don't cause issues.
The text was updated successfully, but these errors were encountered: