Generate Strong Password

[andale82]

At the moment,
I could choise what kind of characters (lowercase, UPPERCASE, digits, hexadecimal digits, symbols) can be used to generate a password.
I think that gorilla password, must create password with all type of characters.

In other words:
If I want lowercase letters, uppercase letters, digits, and symbols,
gorilla password have not generate this password:"nzGnNQwuGOSPulSy" because it has not digits and it has not symbols.

Thanks

[rich123]

The character choices in Gorilla's password character chooser indicate which characters Gorilla is allowed to select from for password generation.

The actual generation is a random selection of X characters (the desired length) from the set of allowed characters. Because of the random selection, it is possible to have a password generated that does not contain at least one character from each set (because the selection is random).

But trying to force selection of at least X characters from each grouping adds huge complexity to the selection algorithm, that additional complexity then risks making the algorithm significantly less secure.

For websites that enforce the silliness of attempting to measure password complexity by testing for "at least 1 letter, at least 1 number, at least one punctuation, etc." (which are all based around trying to force a human to increase the complexity of a human selected password) what I usually do is generate a PWGorilla randomized password, and if it is missing characters the website demands, either just immediately generate another, or simply insert into the PWGorilla generated password an additional character that the website is demanding be present.

I refer to this enforcement as 'silliness' above because a password, randomly selected from the full set of allowable characters, is more secure, complex and stronger, even if it omits one character type, than what results from the password complexity measurement algorithms when a human is performing the selection, which often result in a human choosing something like "Password!2". This password which would pass the algorithm, it has at least 1 upper, 1 lower, 1 punctuation, and 1 numeral, but is not at all secure, complex, or strong, meanwhile the algorithm would reject your sample of "nzGnNQwuGOSPulSy" even while this is significantly more secure, complex, and stronger than "Password!2".

[andale82]

I understand that
(l+U+d+s)^n is more sure than (l+U+d+s)^(n-4) + U + d + s + i
where (l: lowercase, U: uppercase, d: digits, s: symbols) and n numbers of characthers.

But I think that having to adapt to the constraints of websites, gorilla password should allow me to choose whether to make the choice of characters a constraint or a simple extension of the dictionary with which to compose the password.

[rich123]

At the moment the selections for password policy are built as extensions of the dictionary of allowed characters from which PWGorilla performs a random selection of "password length" characters.

I.e., if only "use lowercase letters" is enabled, then the selection dictionary contains only lowercase letters, and therefore the random selection will generate with only lowercase letters.

The hard part would be enforcing 'presence' of particular subsets of characters within a randomly generated password without also damaging the character selection algorithm to such an extent that the result is far from random. I.e., the algorithm at the moment is simple and straightforward, roughly it is:

build dictionary of allowed characters
loop for length times:
randomly pick one character from dictionary of allowed characters and append to generated password candidate
end loop

Adding code to enforce "at least one numeral, at least one punctuation, etc." will seriously complicate that otherwise simple algorithm. And complication has been the bane of security/encryption code since the beginning of time, because where there is additional complexity, there are often unseen security holes lurking.

Additionally, the 'constraints' aspect becomes a bottomless rabbit hole of never ending issues, because as soon as I add new constraint W because someone discovered website X used it, someone else will discover that different website Y also has different, as yet unsupported, constraint Z. It would take some time to even piece together a UI that could generically handle the majority of constraints that websites dream up, and even then it likely would not handle them all.