I'd love to have nbvcxz translated into as many languages as possible. Currently, it's got an English and French translation. I sadly am not multilingual, so I can't really do anything here. I am hoping some users who are multilingual can take a little bit of time to translate the not terribly large amount of text into whatever languages they are able to.

The two files which need to be translated to another language can be found here: https://github.com/GoSimpleLLC/nbvcxz/blob/master/src/main/resources/feedback.properties and here: https://github.com/GoSimpleLLC/nbvcxz/blob/master/src/main/resources/main.properties

Edit: We have had some translations completed already, so i'll list them here. French Russian Ukrainian Afrikaans Hungarian Spanish Portuguese

If you know the language, feel free to review each: https://github.com/GoSimpleLLC/nbvcxz/tree/master/src/main/resources

We are currently building password rating into two separate clients, one Java, one C++ and would like to use native password rating libraries.

For Java we are already using nbvcxz, for C++ we want to use zxcvbn.

Ideally both clients would identify the same passwords as weak. However, reading https://github.com/GoSimpleLLC/nbvcxz#differentiating-features, I'm assuming this never was a goal of nbvcxz (which I understand). What would it take to give nbvcxz a "compatability" mode that would make it produce the same (or at least almost the same) results as zxcvbn?

As a best-effort measure: are there some configurations that would get nbvcxz results closer aligned to the zxcvbn results?

Not sure if this is an issue or if we haven't implemented something correctly. We're trying to use the library for password validation, and we've found that 200+ simultaneous connections fill the JVM heap and crash our servers. Basically we have an API enpoint that the user calls and passes their password. When then call nbvcxz.estimate(password).

First, thank you for providing that awesome library!

Second, I need just like zxcvbn does, an enum indicating if the password is either, worst, bad, wak, good or strong. According to zxcvbn, it's possible to do that, based on guesses:

result.score      # Integer from 0-4 (useful for implementing a strength bar)

  0 # too guessable: risky password. (guesses < 10^3)

  1 # very guessable: protection from throttled online attacks. (guesses < 10^6)

  2 # somewhat guessable: protection from unthrottled online attacks. (guesses < 10^8)

  3 # safely unguessable: moderate protection from offline slow-hash scenario. (guesses < 10^10)

  4 # very unguessable: strong protection from offline slow-hash scenario. (guesses >= 10^10)

This would be accessible calling getScore() in me.gosimple.nbvcxz.scoring#Result

nbvcxz does not currently use modules. When we use it in a JDK9 modular application, Java turns the JAR into a so-called automatic module, whose name is derived from the file name. However, the default name does not follow the recommended module naming conventions (reverse-dns style, module name derived from the main exported package).

It is possible to specify a stable automatic module name through a Automatic-Module-Name manifest entry, while still targeting JDK8:

Automatic-Module-Name: me.gosimple.nbvcxz

Selecting a stable module name is very important, because Java does not allow two modules to own the same package. So either provide the module name through the manifest file or event better: Provide a complete module declaration.

Hey there again, you have stated the following in the README: "Anyone else using the library in their application, i'd love to hear and put a link up here."

I developed an android application around this library, so I would really appreaciate it if you would add my app to this list :).

Here the link again: https://github.com/cyb3rko/pazzword

L33tified words seem to get only partial dictionary matches.

Result

The password Ch1ck3n1970 currently yields:

• BruteForceMatch: C
• BruteForceMatch: h
• BruteForceMatch: 1
• BruteForceMatch: c
• DictionaryMatch: ken (male_names)
• YearMatch: 1970

For comparison, this is Chicken1970:

• DictionaryMatch: chicken (passwords)
• YearMatch: 1970

Expected

For Ch1ck3n1970 I would expect the same matches as Chicken1970:

• DictionaryMatch: chicken (passwords, Leet Substitutions true)
• YearMatch: 1970

In this example I have configured nbvcxz with an additional single-entry dictionary to test how a common password occurrence (surname or given name plus a few numbers) is handled:

// Just a random string for testing. Please assume for the sake of the example that
// 'Gohklhiepu' is the user's surname.
Map<String, Integer> excludeMap = new HashMap<>();
excludeMap.put("Gohklhiepu", 0);

// Just like the README.
List<Dictionary> dictionaryList = ConfigurationBuilder.getDefaultDictionaries();
dictionaryList.add(new Dictionary("exclude", excludeMap, true));

Configuration configuration = new ConfigurationBuilder()
        .setDictionaries(dictionaryList)
        .setMinimumEntropy(30d)
        .createConfiguration();

Nbvcxz nbvcxz = new Nbvcxz(configuration);


// Test A.

Result result = nbvcxz.estimate("Gohklhiepu");

System.out.println(result.getEntropy());
// 0.0

for (Match match : result.getMatches()) {
    System.out.println(match.getDetails());
    // DictionaryMatch
}


// Test B.

result = nbvcxz.estimate("Gohklhiepu3425");

System.out.println(result.getEntropy());
// 60.29210956096036

for (Match match : result.getMatches()) {
    System.out.println(match.getDetails());
    // A series of BruteForceMatch
}

As expected, using the fictional dictionary word as password gives 0.0 entropy.

Surprisingly, word + 3425 (which is a rather weak password if we assume that word is the user's surname and the number his postal code or house number) results in a rather high entropy of 60.3. It looks like the word is not recognized as a dictionary word — all matches are BruteForceMatch.

Could this be a bug?

/u/finlay_mcwalter on reddit said:

From the linked explanation: ...looking for matches in any part of the password on: word lists, ... I wonder if, rather than (or perhaps as well as) looking for matches in any part, it would be more productive to compute the Levenshtein distance between your various "bad passwords" and the candidate password? With that, a password of paXssXwoXrd, which has only a Levenshtein distance to password of 3, would be flagged as weak, whereas it has none of the bad characteristics you're currently looking for. Some of the daft ways people "harden" their passwords, like l33t and cASEsWappING, will produce pretty low Levenshtein statistics without the need for a dedicated matcher.

Portuguese is my mother language, and I found some typos on pt bundle. So I'm contributing with my changes to upstream. All words are following the last spelling reform, so I believe it will work for all countries who speaks Portuguese.

I also changed bundle values to Unicode because the current version on master branch are printing messages like "Repetições" instead of "Repetições".

Thank you.

Hey there,

first: nice lib, thanks for your work!

My Problem: I would like to use your library with only my own password matchers. The problem are the BruteForceMatches or the isRandom-check. Is there a way to turn it off?

With the String "+=&/()!" (without quotes) nbvcxz returns a score of 4/4, entropy of around 35 and 7 brute force matches with an entropy of around 5 each. Which seems kinda overrated.

The online demo on the other hand returns a single brute force match with only a score of 2/4. Which seems more appropriate for a password of only 7 chars. I'm sure even some precomputed rainbow tables go up to 8 normal chars (letters, digits and regular special characters)

I don't know what password caused this, but observed the following crash:

java.lang.StackOverflowError
	at java.base/java.util.TreeMap.getEntry(TreeMap.java:350)
	at java.base/java.util.TreeMap.get(TreeMap.java:279)
	at me.gosimple.nbvcxz.matching.DictionaryMatcher.replaceAtIndex(DictionaryMatcher.java:68)
	at me.gosimple.nbvcxz.matching.DictionaryMatcher.replaceAtIndex(DictionaryMatcher.java:82)
	at me.gosimple.nbvcxz.matching.DictionaryMatcher.replaceAtIndex(DictionaryMatcher.java:82)
	at me.gosimple.nbvcxz.matching.DictionaryMatcher.replaceAtIndex(DictionaryMatcher.java:82)
	<~700 more identical lines truncated>

This is a condensed version of the configuration that was used:

List<Dictionary> dictionaries = new ArrayList<>(ConfigurationBuilder.getDefaultDictionaries());
DictionaryBuilder userDictionary = new DictionaryBuilder()
        .setDictionaryName("user_details")
        .setExclusion(true);

var relatedWords = List.of("<user email and potentially other user fields>");

if (relatedWords != null) {
    for (String word : relatedWords) {
        userDictionary.addWord(word, 0);
    }
}

dictionaries.add(userDictionary.createDictionary());
dictionaries.add(new DictionaryBuilder()
    .setDictionaryName("example")
    .setExclusion(true)
    .addWord("example", 0)
    .addWord("example.com", 0)
    .createDictionary());

return new ConfigurationBuilder()
        .setDictionaries(dictionaries)
        .createConfiguration();

Using Nbvcxz v1.5.0.

The way that DictionaryMatcher#match works isn't consistent, or at least one could make an argument that it isn't. It gives too high entropy to some passwords that are just "worse" l33t-substituted versions of some other password. For example

The password "passw0rd" will be matched directly to a word found in the dictionary "passwords". In that dictionary "passw0rd" is at rank 411 so it is given an entropy of ~8.68.

The password "p4s5w0rd" will not be matched directly to a word found in the dictionary "passwords". Instead the match-method will try to use l33t-substitutions and one of those substitutions is the word "password". That word is then looked up in the dictionaries and found at rank 2 in the "passwords" dictionary. Thus, the password is given an entropy of ~3.32.

The "easy" fix for this might be to not short circuit the match-method with "continue" in the for-loops, but I'm not sure how that would affect other parts of the system and it will increase the running time of estimating a password.

Note that I'm not saying that "p4s5w0rd" is more secure than "passw0rd" and should get a higher score. What I'm saying is that its estimated entropy shouldn't be lower, since both strings are essentially a l33t-substitution on the word "password" - it's just that one of the strings is a common password while the other one isn't.

In general, if two strings can both be transformed into the same string and that transformed string has a lower entropy than either of the non-transformed strings, then both the non-transformed strings should get the entropy value of the transformed string.

Because ConfigurationBuilder.getDefaultXYZ returns the internal instances (and because of the way the documentation suggests to add stuff to the configuration builder), one can easily add for example matchers multiple times.

public int estimate(String password) {
    List<PasswordMatcher> matchers = ConfigurationBuilder.getDefaultPasswordMatchers();
            matchers.add(new PasswordMatcher() {
                @Override
                public List<Match> match(Configuration configuration, String password) {
                    System.out.println("Called with: " + password);
                    return new ArrayList<>();
                }
            });
    Configuration config = new ConfigurationBuilder()
        .setPasswordMatchers(matchers)
        .createConfiguration();
    Nbvcxz tester = new Nbvcxz(config)
    Result result = tester.estimate(password);
    return result.getBasicScore(); // Yes I've seen that you dislike this, but just to illustrate! :)
}

Running the above once will print "Called with ...". Running it a second time will print "Called with ..." twice, a third time trice, a fourth time will print it four times and so on.

One can get around this by either creating the configuration once (and not every time a test is made) or by wrapping the return value of ConfiguratioBuilder.getDefaultPasswordMatchers() in a new ArrayList.

This is not a big bug but given the documentation I spent a good half hour scratching my head as to why I was getting multiple calls to my "PasswordMatcher".

Best Regards, Per-Erik

For issue #45

Arbitrary string to string substitution implemented, so "P@55uu0rd" -> "password" works, as does "8u2T3RfL?" -> "butterfly" from the wikipedia page. I wrote DictionaryMatcher.testArbitraryLengthSubstitutions() to test a few more examples. leetTable has been replaced by the MungeTable class which facilitates some of the substituting. MungeTable is initialized in ConfigurationBuilder as before, you can try adding some more substitutions there, I just added the few from the wikipedia page and some extra ones that I thought up. PasswordChain is used to store the list of possible substring permutations. I rewrote translateLeet as getUnmungedVariations, and rewrote replaceAtIndex. They kind of work in the same way, just with a list of String[] instead of an in-place char array. There are some very obscure limitations, but I doubt they could be much of an issue. Efficiency wise it's probably worse than before, but I guess it depends on what your expectations are. It still takes a fraction of a second to estimate a reasonably sized password, at least.

Also, I changed the pom.xml java version from 1.7 to 8 so I could use streams and lambdas, is that an issue?

Let me know if you want me to do more on this, I'm sure it's not perfect. There are loads of occurrences of "leet" in comments and method names etc. that should probably be something like "munge" now...