Add score enum indicating password strength

[gosimplellc]

Add score enum indicating password strength

[Tostino]

When I was implementing I had thought about that, but decided not to put that into Nbvcxz because those scores mean different things to different people, and basing it on # of guesses doesn't really do it justice.

For instance if you've hashed your passwords with md5, the number of guesses / sec possible if that password is tried offline is so different than if you had hashed your passwords with bcrypt(14) for example.

So to get a score, you really need to base it on the "time to crack" we calculate, not the estimated guesses required for the password. The other benefit to that, is as new hardware comes out this library is being updated with accurate numbers for guesses/second/$ for each algorithm I included standard (those are all able to be overridden by users as well).

At that point, if there is a good consensus on what a good "time to crack" threshold would be for each of those scores, it would be easy to implement...

I'd love to hear more thoughts on this.

[Rapster]

I understand, but since our front-end password feeback is based on zxcvbn, we have to be coherent on server-side. So I guess a default impl should be based on time-to-crack, but nbvcxz should give the possibility to override that default impl.

If necessary I can provide a PR, but I didn't find so far what is a bad or a good time to crack. I think a good way to mesure that is:

• worst: less than an hour or common word
• weak: less than a day
• good: more than a month
• strong: more than a year ?

I'm extrapolating (not sure it makes sense to you) 😋

[Tostino]

Hmm, maybe instead of absolute values, we can have the score be related to the minimum entropy set within the configuration?

That way we can always return a relevant score based on what the minimum entropy is set to, rather than arbitrary values. Just a thought.

I already did some work this past weekend to make it so minimum entropy can be set by passing in a time to crack rather and a cracking algorithm rather than having to do that math yourself and figure out what a good value is... commit: 1154923

[Togrias]

Hi,

I too have a front-end based on zxcvbn. It would be nice if both ends would give the same results. So if the front-end tells the user their password is acceptable, then the backend should accept it also.

[Tostino]

Agreed that being compatible is a good goal for those reasons, though keep in mind that Nbvcxz is not trying to be a direct clone of Zxcvbn, but also expands on the algorithms provided and fixes some structural issues. They are not guaranteed to score a password the same just FYI.

I will try and get the work done on this sooner rather than later, my day job has been killing me lately.

[Tostino]

Alright I implemented the most basic scoring algorithm right from zxcvbn in commit: 7e3b350

I plan on implementing a more advanced way of scoring based on time rather than guesses in the future, but this is a first step. Any comments before I push out a new release?
@Rapster @Togrias

[Togrias]

Greetings,

What I'm looking for is a scoring algorithm that 100% matches zxcvbn's results (i.e. a complete port). I think the solution is in another library (zxcvbn4j). It's perfectly fine if nbvcxz is advancing in its own direction.

I'm sorry if I misunderstood this library's intentions. It's just confusing because the Zxcvbn github page lists this library as a port.

[Tostino]

Going to close this as release 1.4.3 is now out.

@Togrias Yes, sadly if you want something that will estimate exactly the same in Java as JS, using something else is the only real option. I had originally intended to do an exact port, but I noticed too many flaws with that approach after testing.