Substituted characters not fully implemented

[aattwood]

It seems that some substituted characters e.g. @ for a and 5 for s are implemented, but some are not.
I have tested 2u and uu for w e.g.
P@55w0rd provides a basic score of 0
P@55uu0rd provides a basic score of 4

I found a list of substituted characters at:

https://en.wikipedia.org/wiki/Munged_password

[Tostino]

Sorry for the delay in responding to you.

That'd be because what is in place currently is just a "l33t" table lookup for single character replacements.

See: https://github.com/GoSimpleLLC/nbvcxz/blob/master/src/main/java/me/gosimple/nbvcxz/resources/ConfigurationBuilder.java for the getDefaultLeetTable() implementation.

So, with the current design there is no easy way to replace 2 characters with 1 character (uu or 2u with w)... that does seem like a good idea though, if you or anyone else have time to implement an "unmunger", feel free and I will give any support I can in getting it merged.

Otherwise i'll just keep this open and will eventually get to it.

[Ronan-H]

I'm giving this a shot. It's pretty tricky, most of the leet substitution code has to be rewritten to allow for arbitrary string -> string substitutions. There are some questions to be asked about how you want it done but I'll just go with what I think works best and you can review it in the pull request (if I actually get this done...)

[Ronan-H]

From DictionaryMatcher#translateLeet():

// Do not bother continuing if we're going to replace every single character
if(replacements.keySet().size() == password.length())
    return translations;

Why shouldn't passwords that are made up entirely of leet characters be translated?

[Tostino]

@Ronan-H really appreciate the work on this! I will review it as soon as I can get up for air at work, it's been really crazy for me, and I don't want you to think I am just ignoring ya.

I honestly cannot remember why that was put in place, it may have been an optimization to speed the dictionary checker up without causing any known regressions. I will look at my commits and see if I can recall.

[Tostino]

And...that's exactly what it was: 65a1e54

As i'm sure you're aware, the complexity of this problem can get out of hand quite quickly causing an extreme performance issue if the number of options on how to cost this is allowed to explode to any granularity. So that's why I put some "stops" in place to limit the explosion of possibilities that need to be considered for each password to only the ones which were more likely to be a hit.

If that can be relaxed in some way without degrading performance a ton that'd be great.

[Ronan-H]

@Tostino Ok, I've added that optimization to my PR. Something like 31!+3 still gets matched to elite somehow, I guess that has to do with how the string gets broken up? EDIT: Actually I may have rushed that one...

Don't worry about merging my PR any time soon, I just wanted something fun to work on while I'm waiting to start work :)

---

I know what you mean about the performance issues, things start to slow down when you're testing combinations of combinations of combinations...I feel like it's a bad place to optimize though personally. The above example with 31!+3 -> elite can be translated extremely quickly, and yet it gets skipped and matched as brute force. Anyway, I fixed that optimization and it can always be taken our or traded for another optimization later if you want.