Simple password entropy check CPU time approaches heat death of the universe

[melezov]

It seems that running it against relatively simple, albeit long password such as aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa seems to exceed what little CPU power we have here in our data centre, effectively making our system very secure by being very dead.

Is there anything that could we could do (configuration-wise) except slicing it up or taking a substring?

Example repro via standalone jar:

>java -jar nbvcxz-1.3.1.jar
Commands: estimate password (e); generate password (g); quit (q)
Please enter your command:
e
Please enter the password to estimate:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

The aaa example is just for the repro, in reality our password field (was) unbounded.

[Tostino]

Looking into it. I had tested with long passwords previously, there must have been a regression that didn't get caught in the unit tests.

Thank you for bringing it to my attention.

[Tostino]

Alright, this was fixed with something I was planning on implementing eventually, due to this issue being possible.

I implemented a timeout for the findBestMatches algorithm which can be configured. If it exceeds the time specified, it will fallback to the findGoodEnoughMatches algorithm which is much faster, but also less likely to find the optimal match combination.

Commit: a61cb5f