go-password-validator icon indicating copy to clipboard operation
go-password-validator copied to clipboard

Allow configuration such as error messages and character sets

Open tjerman opened this issue 4 years ago • 2 comments

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.

tjerman avatar Nov 15 '21 14:11 tjerman

I like both of these suggestions, I think step # 1 is the change the API to programmatically list the character sets used, like you mentioned. Maybe that's just a new exported function?

I also like the idea of allowing the user to specify sets of characters... Maybe we make a new struct type that holds the sets, and the ones listed in the readme are the "DefaultSets" or something

wagslane avatar Dec 07 '21 21:12 wagslane

What I was sort of thinking of is automatically determining what character set(s) the user is using based on the Unicode blocks that contain the given characters.

To outline the whole idea I had:

  1. define (all/most) of the Unicode blocks along with their size
  2. define a new/update existing API functions (if you wish to preserve backwards compatibility or not) where one of the arguments would be a config struct allowing you to define what character sets you'd permit users to use.

The code would then automagically determine what Unicode blocks the user is using with their password which would allow your entropy calculation algorithm to remain practically the same (there may need to be some weighting for larger blocks such as Japan and Chinese)

As for the errors, you could provide a set of messages in the config struct (noted under point two a bit earlier) or you could have a predefined set of errors (such as ErrorMissingSpecialCharacters) which could be detected and properly handled by the caller. Since some character sets may define different errors I do think the prior option may be better (perhaps, probably, maybe).

I'll do some fiddling around the idea when I find some time; I think this could be a fun little thing to mess around with.

tjerman avatar Dec 10 '21 10:12 tjerman