Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Force use of case/digits/etc... #220

Open
ciampix opened this issue Aug 30, 2021 · 2 comments
Open

Force use of case/digits/etc... #220

ciampix opened this issue Aug 30, 2021 · 2 comments

Comments

@ciampix
Copy link
Collaborator

ciampix commented Aug 30, 2021

Sometimes I bump into sites that require you to enter password with Upper/lover case, dots, digits, etc.
Gorilla password generation options permit but not enforce to use those signs, and the end result is that you have to repeat the password generation until it matches the site minimum requirements. I would like that those options would be more strict and not just possibility options.

TIA

@rich123
Copy link
Collaborator

rich123 commented Aug 30, 2021

Greetings Marco. Thank you for the work you have done on the Italian translations.

This should be straightforward, although right at this moment my time is quite limited, so it may be some time before I can work to add a "require at least X of each" selection to the UI.

As a workaround for those sites I've encountered that have such requirements (which do not add security, but those same sites are likely also simply checking off a box on a compliance form as well) is to generate a password, and then for capitol or specific punctuation either capitalize one or more existing random characters or append a required punctuation mark. Now, I'd agree that doing so reduces the "randomness" in a strict sense. But converting this "dbX5Bj#Tuitb" to "dBX5B7j#Tuitb&" to meet such requirements still results in a much more 'randomized' password than what most users might do (which would be some form of "PassWord32$!").

Another issue I've encountered are sites that have hidden "invalid character" requirements. They say something like "at least 2 punctuation or special" but then reject a password containing # or $ or ! with no feedback as to which "character" caused the rejection. I've had to do multiple generations sometimes before I randomly generated one that was "acceptable", which is very frustrating. Sadly, none of us can fix silent rejection of special characters, due to the "silent" part.

@dverbeeck
Copy link

This appears to be a dupe of 210

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants