Password Generation Routine Is Weak

[MookLeToad]

The following routine is used for password generation and will lead to weak passwords a (relatively) large percentage of the time:
openssl rand -base64 10 | tr -d OoIi1lLS | head -c12;echo

The first issue arises from generating a random string which is not divisible by 3. Due to the way base64 encodes characters this will always result in a output that is padded with two "=" characters. These will be characters 15 and 16, which will (most of the time) not be part of the 12 characters used for the password. Unless;
The 2nd issue arises from the "OoIi1lLS" characters being removed from the generated string. If enough characters are removed then the "=" padding characters will be the 12th and (sometimes) 11th characters of the generated password. This happens ~25% of the time (in a test of 100,000 generated passwords).
An extension of the 2nd issue also occurs when a more significant portion of the random and base64 encoded string contains the blacklisted characters. Of the 100,000 generated password sample 1.3% were 11 characters long, 0.2% were 10 characters long, 0.03% were 9 characters long and 0.01% were 8 characters long. Keep in mind that every one of these diminished passwords will end with two of the "=" padding characters, i.e those characters are known so brute-forcing efforts only need to consider the remaining characters.

The overall result of this is the setting of unintentionally weak passwords for admin accounts and the generation of password hashes that go from infeasible in their entropy and complexity to bruteforceable in minutes/hours.

As a slight update, this routine could theoretically set a password of 2 characters where those characters would be "==" each and every time.

[RareAir12]

You look like a monkey and you smell like one to

[meepmeep129]

You look like a monkey and you smell like one to

This has been the most constructive feedback on this bug in 4 years.