nbutton23/zxcvbn-go

zxcvbn password complexity algorithm in golang

This is a goLang port of python-zxcvbn and zxcvbn, which are python and JavaScript password strength generators. zxcvbn attempts to give sound password advice through pattern matching and conservative entropy calculations. It finds 10k common passwords, common American names and surnames, common English words, and common patterns like dates, repeats (aaa), sequences (abcd), and QWERTY patterns.

Please refer to https://dropbox.tech/security/zxcvbn-realistic-password-strength-estimation for the full details and motivation behind zxcbvn. The source code for the original JavaScript (well, actually CoffeeScript) implementation can be found at:

https://github.com/lowe/zxcvbn

Python at:

https://github.com/dropbox/python-zxcvbn

For full motivation, see:

https://dropbox.tech/security/zxcvbn-realistic-password-strength-estimation

---

Use

The zxcvbn module has the public method PasswordStrength() function. Import zxcvbn, and call PasswordStrength(password string, userInputs []string). The function will return a result dictionary with the following keys:

Entropy # bits

CrackTime # estimation of actual crack time, in seconds.

CrackTimeDisplay # same crack time, as a friendlier string: # "instant", "6 minutes", "centuries", etc.

Score # [0,1,2,3,4] if crack time is less than # [10^2, 10^4, 10^6, 10^8, Infinity]. # (useful for implementing a strength bar.)

MatchSequence # the list of patterns that zxcvbn based the # entropy calculation on.

CalcTime # how long it took to calculate an answer, # in milliseconds. usually only a few ms.

The userInputs argument is an splice of strings that zxcvbn will add to its internal dictionary. This can be whatever list of strings you like, but is meant for user inputs from other fields of the form, like name and email. That way a password that includes the user's personal info can be heavily penalized. This list is also good for site-specific vocabulary.

Bug reports and pull requests welcome!

---

Project Status

Use zxcvbn_test.go to check how close to feature parity the project is.

---

Acknowledgment

Thanks to Dan Wheeler (https://github.com/lowe) for the CoffeeScript implementation (see above.) To repeat his outside acknowledgements (which remain useful, as always):

Many thanks to Mark Burnett for releasing his 10k top passwords list: https://xato.net/passwords/more-top-worst-passwords and for his 2006 book, "Perfect Passwords: Selection, Protection, Authentication"

Huge thanks to Wiktionary contributors for building a frequency list of English as used in television and movies: https://en.wiktionary.org/wiki/Wiktionary:Frequency_lists

Last but not least, big thanks to xkcd :) https://xkcd.com/936/

zxcvbn-go's Issues

dateWithoutSepMatch(..) not working

While writing test i found that dateWithoutSepMatch(..) is not working.

I have yet to dig into this one and figure out why.

DOS Exploit

Hey, just wanted to let you know I've gotten reports from users of my library: Nbvcxz that are getting a DOS every so often by specifically crafted passwords.

I even found a tool created by a government contractor used for issuing a DOS against programs using libraries containing the vulnerable (to combination explosion) algorithms from the original zxcvbn implementation:

• https://github.com/twosixlabs/acsploit
• GoSimpleLLC/nbvcxz#60

I've solved this by implementing a maxLength type configuration...but that isn't totally done yet as I feel like I still need to have it do dictionary checks against the full-length password without any transformations. Working on finishing that feature and putting out a release.

Far less data in zxcvbn-go/data vs zxcvbn/data

Is there any reason why there seems to be a lot more data here: https://github.com/dropbox/zxcvbn/tree/master/data ? For example the surnames file at zxcvbn/data has 88,000 words, but the surnames in zxcvbn-go/data appears to be about half around 40,000. If this is not on purpose, then I can make the updates to add the extra words to make the package more secure.

pprof memory heap

I tried https://golang.org/pkg/net/http/pprof/ on my project and it is showing multiple entries for zxcvbn library.

Below are some instances from /debug/pprof/heap

2: 3407872 [2: 3407872] @ 0x417259 0x4160d9 0x92cb7a 0x92e0b7 0x92dbbb 0x9306b0 0x7db232 0x53052e 0x40b0d2 0x43c8fd 0x46bd51
0x92cb7a github.com/nbutton23/zxcvbn-go/matching.buildRankedDict+0x13a D:/Project/src/github.com/nbutton23/zxcvbn-go/matching/dictionaryMatch.go:50
0x92e0b7 github.com/nbutton23/zxcvbn-go/matching.loadFrequencyList+0x137 D:/Project/src/github.com/nbutton23/zxcvbn-go/matching/matching.go:51
0x92dbbb github.com/nbutton23/zxcvbn-go/matching.init.1+0x1b D:/Project/src/github.com/nbutton23/zxcvbn-go/matching/matching.go:26
0x9306b0 github.com/nbutton23/zxcvbn-go/matching.init+0x60 D:/Project/src/github.com/nbutton23/zxcvbn-go/matching/spatialMatch.go:80
0x7db232 github.com/nbutton23/zxcvbn-go.init+0x42 D:/Project/src/github.com/nbutton23/zxcvbn-go/zxcvbn.go:19

1: 663552 [1: 663552] @ 0x41d552 0x75205e 0x7c3446 0x7c2228 0x7c4b61 0x7c2208 0x7c12cd 0x7c0df2 0xa0aa78 0xa0a658 0xa0ac6d 0x9306ab 0x7db232 0x53052e 0x40b0d2 0x43c8fd 0x46bd51
0x41d552 reflect.unsafe_NewArray+0x32 C:/Go/src/runtime/malloc.go:803
0x75205e reflect.MakeSlice+0x23e C:/Go/src/reflect/value.go:2044
0x7c3446 encoding/json.(_decodeState).array+0x896 C:/Go/src/encoding/json/decode.go:507
0x7c2228 encoding/json.(_decodeState).value+0x3c8 C:/Go/src/encoding/json/decode.go:364
0x7c4b61 encoding/json.(_decodeState).object+0x1171 C:/Go/src/encoding/json/decode.go:684
0x7c2208 encoding/json.(_decodeState).value+0x3a8 C:/Go/src/encoding/json/decode.go:367
0x7c12cd encoding/json.(*decodeState).unmarshal+0x19d C:/Go/src/encoding/json/decode.go:168
0x7c0df2 encoding/json.Unmarshal+0x132 C:/Go/src/encoding/json/decode.go:96
0xa0aa78 github.com/nbutton23/zxcvbn-go/frequency.GetStringListFromAsset+0xb8 D:/Project/src/github.com/nbutton23/zxcvbn-go/frequency/frequency.go:41
0xa0a658 github.com/nbutton23/zxcvbn-go/frequency.init.1+0x338 D:/Project/src/github.com/nbutton23/zxcvbn-go/frequency/frequency.go:25
0xa0ac6d github.com/nbutton23/zxcvbn-go/frequency.init+0x9d D:/Project/src/github.com/nbutton23/zxcvbn-go/frequency/frequency.go:47
0x9306ab github.com/nbutton23/zxcvbn-go/matching.init+0x5b D:/Project/src/github.com/nbutton23/zxcvbn-go/matching/spatialMatch.go:80
0x7db232 github.com/nbutton23/zxcvbn-go.init+0x42 D:/Project/src/github.com/nbutton23/zxcvbn-go/zxcvbn.go:19

1: 663552 [1: 663552] @ 0x41d552 0x75205e 0x7c3446 0x7c2228 0x7c4b61 0x7c2208 0x7c12cd 0x7c0df2 0xa0aa78 0xa0a721 0xa0ac6d 0x9306ab 0x7db232 0x53052e 0x40b0d2 0x43c8fd 0x46bd51
0x41d552 reflect.unsafe_NewArray+0x32 C:/Go/src/runtime/malloc.go:803
0x75205e reflect.MakeSlice+0x23e C:/Go/src/reflect/value.go:2044
0x7c3446 encoding/json.(_decodeState).array+0x896 C:/Go/src/encoding/json/decode.go:507
0x7c2228 encoding/json.(_decodeState).value+0x3c8 C:/Go/src/encoding/json/decode.go:364
0x7c4b61 encoding/json.(_decodeState).object+0x1171 C:/Go/src/encoding/json/decode.go:684
0x7c2208 encoding/json.(_decodeState).value+0x3a8 C:/Go/src/encoding/json/decode.go:367
0x7c12cd encoding/json.(*decodeState).unmarshal+0x19d C:/Go/src/encoding/json/decode.go:168
0x7c0df2 encoding/json.Unmarshal+0x132 C:/Go/src/encoding/json/decode.go:96
0xa0aa78 github.com/nbutton23/zxcvbn-go/frequency.GetStringListFromAsset+0xb8 D:/Project/src/github.com/nbutton23/zxcvbn-go/frequency/frequency.go:41
0xa0a721 github.com/nbutton23/zxcvbn-go/frequency.init.1+0x401 D:/Project/src/github.com/nbutton23/zxcvbn-go/frequency/frequency.go:26
0xa0ac6d github.com/nbutton23/zxcvbn-go/frequency.init+0x9d D:/Project/src/github.com/nbutton23/zxcvbn-go/frequency/frequency.go:47
0x9306ab github.com/nbutton23/zxcvbn-go/matching.init+0x5b D:/Project/src/github.com/nbutton23/zxcvbn-go/matching/spatialMatch.go:80
0x7db232 github.com/nbutton23/zxcvbn-go.init+0x42 D:/Project/src/github.com/nbutton23/zxcvbn-go/zxcvbn.go:19

2: 416 [3: 624] @ 0x415e91 0x92cb7a 0x92e0b7 0x92dbbb 0x9306b0 0x7db232 0x53052e 0x40b0d2 0x43c8fd 0x46bd51
0x92cb7a github.com/nbutton23/zxcvbn-go/matching.buildRankedDict+0x13a D:/Project/src/github.com/nbutton23/zxcvbn-go/matching/dictionaryMatch.go:50
0x92e0b7 github.com/nbutton23/zxcvbn-go/matching.loadFrequencyList+0x137 D:/Project/src/github.com/nbutton23/zxcvbn-go/matching/matching.go:51
0x92dbbb github.com/nbutton23/zxcvbn-go/matching.init.1+0x1b D:/Project/src/github.com/nbutton23/zxcvbn-go/matching/matching.go:26
0x9306b0 github.com/nbutton23/zxcvbn-go/matching.init+0x60 D:/Project/src/github.com/nbutton23/zxcvbn-go/matching/spatialMatch.go:80
0x7db232 github.com/nbutton23/zxcvbn-go.init+0x42 D:/Project/src/github.com/nbutton23/zxcvbn-go/zxcvbn.go:19

1: 16 [1: 16] @ 0x4532ce 0x453156 0x7c6c9f 0x7c5360 0x7c21e2 0x7c3622 0x7c2228 0x7c4b61 0x7c2208 0x7c12cd 0x7c0df2 0xa0aa78 0xa0a7e7 0xa0ac6d 0x9306ab 0x7db232 0x53052e 0x40b0d2 0x43c8fd 0x46bd51
0x7c6c9f encoding/json.(_decodeState).literalStore+0x14ef C:/Go/src/encoding/json/decode.go:833
0x7c5360 encoding/json.(_decodeState).literal+0xf0 C:/Go/src/encoding/json/decode.go:717
0x7c21e2 encoding/json.(_decodeState).value+0x382 C:/Go/src/encoding/json/decode.go:370
0x7c3622 encoding/json.(_decodeState).array+0xa72 C:/Go/src/encoding/json/decode.go:518
0x7c2228 encoding/json.(_decodeState).value+0x3c8 C:/Go/src/encoding/json/decode.go:364
0x7c4b61 encoding/json.(_decodeState).object+0x1171 C:/Go/src/encoding/json/decode.go:684
0x7c2208 encoding/json.(_decodeState).value+0x3a8 C:/Go/src/encoding/json/decode.go:367
0x7c12cd encoding/json.(_decodeState).unmarshal+0x19d C:/Go/src/encoding/json/decode.go:168
0x7c0df2 encoding/json.Unmarshal+0x132 C:/Go/src/encoding/json/decode.go:96
0xa0aa78 github.com/nbutton23/zxcvbn-go/frequency.GetStringListFromAsset+0xb8 D:/Project/src/github.com/nbutton23/zxcvbn-go/frequency/frequency.go:41
0xa0a7e7 github.com/nbutton23/zxcvbn-go/frequency.init.1+0x4c7 D:/Project/src/github.com/nbutton23/zxcvbn-go/frequency/frequency.go:27
0xa0ac6d github.com/nbutton23/zxcvbn-go/frequency.init+0x9d D:/Project/src/github.com/nbutton23/zxcvbn-go/frequency/frequency.go:47
0x9306ab github.com/nbutton23/zxcvbn-go/matching.init+0x5b D:/Project/src/github.com/nbutton23/zxcvbn-go/matching/spatialMatch.go:80
0x7db232 github.com/nbutton23/zxcvbn-go.init+0x42 D:/Project/src/github.com/nbutton23/zxcvbn-go/zxcvbn.go:19

0: 0 [2: 262144] @ 0x44ed58 0x44ea4e 0x92cdf2 0x92dd4e 0x7db01f 0x52e0f8 0x53034d 0x632233 0x4bc551 0x630f5b 0x636522 0x4bc551 0x40a3d9 0x4bc551 0x4be875 0x4bb265 0x46bd51
0x92cdf2 github.com/nbutton23/zxcvbn-go/matching.l33tMatch+0x232 D:/Project/src/github.com/nbutton23/zxcvbn-go/matching/leet.go:19
0x92dd4e github.com/nbutton23/zxcvbn-go/matching.Omnimatch+0x17e D:/Project/src/github.com/nbutton23/zxcvbn-go/matching/matching.go:42
0x7db01f github.com/nbutton23/zxcvbn-go.PasswordStrength+0xaf D:/Project/src/github.com/nbutton23/zxcvbn-go/zxcvbn.go:12

And each time I use library to calculate entropy of password, the heap count is growing.

Repetition matcher fails with special UTF-8 characters

It seems like the repeat matcher has trouble detecting special UTF-8 characters. This is especially unhandy because that includes German umlauts which are fairly common to be used in passwords in German speaking countries.

Here is an example reproducing the issue.

package main

import (
	"fmt"

	"github.com/nbutton23/zxcvbn-go"
)

func main() {
	res := zxcvbn.PasswordStrength("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", nil)
	fmt.Println(res.Entropy)

	res = zxcvbn.PasswordStrength("ööööööööööööööööööööööööööööööööööööö", nil)
	fmt.Println(res.Entropy)

	res = zxcvbn.PasswordStrength("øøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøø", nil)
	fmt.Println(res.Entropy)
}

Demonstration:
https://go.dev/play/p/2u3-KnZXGKK

password on testapp/main.go

lines 14 and 15:

14         //pass := "68f9698fe2540c525fe35b15c6ae1a1788e079962b2ada3d1872c7665c95e148"
15         pass := "NathanButtonTheAmazingAndAwesom12340987tyghjuikolpblkjhgfdsalabcdef"

was that supposed to be there?
I mean, doesn't really look like it was an explicit example.

Go 1.10: adjcmartix.go:85: suspect or: char != "" || char != " "

Version 0.1 does not pass unit tests with Go 1.10:

+ GOPATH=/builddir/build/BUILD/zxcvbn-go-0.1/_build:/usr/share/gocode
+ go test -buildmode pie -compiler gc -ldflags '-extldflags '\''-Wl,-z,relro  '\'''
# github.com/nbutton23/zxcvbn-go/adjacency
./adjcmartix.go:85: suspect or: char != "" || char != " "
FAIL    github.com/nbutton23/zxcvbn-go/adjacency [build failed]

Add test for each matcher

DictionaryMatch
DateWithoutSepMatch
SpatialMatch
RepeatMatch
SequenceMatch

Score deviates from the coffee/javascript version

./testpw Passi0n@ 'fred' 'blogs' 'johnny'
Passi0n@ [fred blogs johnny]
Score: 0

JS equiv. returns score of 1

SpatialMatch not working

While writing test I found that SpatialMatch is not working.

Possible issues

• It looks like my graphs might be messed up.
• Missing qwerty. . .

Score not match

Currently we using "zxcvbn": "^4.4.2" on react
Everything is okay except for the score, on the front end side we got score 4
But in the backend (golang) we got score 2

Setup continuous integration

Setting up continuous integration will make it easy to see the state of master as well as any PRs being submitted.

I'd love to help set this up, but the repository owner needs choose a CI service and enable it in the repo.

go-spew in vedor directory but unused

Maybe I am missing something, but in my copy of this lib, go-spew is imported anywhere. Was it used before and unused now?

Simplify match struct.

See if we can simplify the match struct. There are several fields that are only used for certain matchers. If its possible to simplify the struct then it should make testing and debugging easier.

infinite recursion in getAllPermutationsOfLeetSubstitutions

I haven't been able to get a fix yet, but I have a reproduction case. The string:

%6|a(+|<91%{s91![go0li0soe||

...will produce infinite recursion in that function.

Is the repo still maintained?

Is the repo still maintained? The last commit was ~2 years ago and there seems to be no activity in the issues section as well. If not, can someone suggest an alternative?

Thanks for your good work :)

Pathological worstcase when password is a hex string

Hi,

I think I hit an algorithmic pathological worst case, if the supplied password string is a hex encoded string. I have not been able to reproduce this behavior with other, way longer passphrases.

I've created a gist with a testcase: Gist

At the point where I aborted (password length 32 characters), it is was consuming around 7GBytes of RAM.