wagslane / go-password-validator

Validate the Strength of a Password in Go

Hi, I'm Lane Wagner

• 🖥️ I've been coding in Go primarily for over 6 years
• 🏗️ I'm the founder of Boot.dev
• 🦀 I’m learning Rust and Vue.js at the moment
• 🐦 You can follow me on Twitter @wagslane
• 🎤 You can also listen to my podcast on BackendBanter.fm

go-password-validator's Issues

passwordvalidator.Validate always return nil error, even when the supplied password is well below min entropy

Describe the bug
Validate method always returns nil error, even when password entropy is less than minimum entropy

To Reproduce
No additional steps required, it is a main line usecase. try with password as "123" with minimum entropy as 60
func strongPass(password string) error {
const minEntropyBits = 60
err := passwordvalidator.Validate(password, minEntropyBits)
return err
}

The problem is the following code, when you return error object it is nil to calling function, as the call fmt.Errorf it is by value and is lost on return.

if len(allMessages) > 0 {
	return fmt.Errorf(
		"insecure password, try %v or using a longer password",
		strings.Join(allMessages, ", "),
	)
}

Expected behavior
Should return an error.

Screenshots
None

Environment (please complete the following information):

• OS: Mac OSX

Additional context
None

Passwords with fghijkl are reported as more secure than they are

Describe the bug
The getLength function is supposed to strip sequential characters after a run length of 2. e.g. fghijkl should become fg.

However, because it first replaces the sequence asdfghjkl, it changes fghijkl to fgijk, which then becomes 'fgij, a length of 4.

To Reproduce

#14

Expected behavior
It should change fghijkl to fg

Screenshots
If applicable, add screenshots or console output that helps explain the situation

Environment (please complete the following information):

• OS: [e.g. Linux Ubuntu]

Additional context
Add any other context about the problem here.

10001010101010101001110101010101010101010101010101010101 should be secure

So the password 1010101010101011101101000000010111011011101001010001001101011011 is calculated as only having a length of "2" and a base of 10. So it would be about 6 bits according to this. But the generation method clearly is generating a binary string with length 64, for a total of 64 bits of entropy.

Leet-speak characters shouldn't count as special characters

title

Allow configuration such as error messages and character sets

Is your feature request related to a problem? Please describe.

I was looking around if we have any go packages to handle password strength validation and I stumbled upon this.
I do like the idea behind this and I have a few suggestions that may come in handy:

• Allow custom error messages or expand the validate function to provide analytical data which can be used to determine error messages outside of the package (the primary idea of this is to allow i18n).
• Allow the validator to be configured with custom character sets or programmatically determine used character sets to support use cases that would require characters outside of the baked-in character sets.

Describe the solution you'd like

My first point should be straightforward on how it could be implemented; something in the lines of returning a struct which outlines the boolean flags used internally (hasReplace, hasLower, ...).

For the second one, I am quite unsure on how (if even possible) to implement as changes to the character sets would affect the entropy and what level would be considered secure (the table in your README).

Is this something you would consider your package to support?
With your insight and if we decide to use this approach for Corteza, I can assist with the implementation.

Squash common sequences

12345 should count as 1

qwerty should count as 1

Mention zxcvbn in the Readme - show the pros and cons

title