[BlueOnyx:21469] Re: Password issues on BlueOnyx in general

[Michael Stauber]

Hi Lewis,

> As an aside, How long can a password be on BlueOnyx? I tend to agree
> with Randall Munroe and his excellent presentation at
> https://xkcd.com/936/ but I worry that passwords are truncated "under
> the hood".

Thank you for bringing this up, as it outlines some room for improvements.

CentOS 6 and 7 use sha512 for generating the password hashes. CentOS 5
used sha256. Both sha256 or sha512 mean that the maximum password length
could potentially be unlimited. For practical reasons we might still
want to impose a limit, such as something between a sensible 80 to 1024
characters at the most, as some components might have issues with
anything too excessively large.

During user password changes via the GUI the GUI requires that the
password is at least 6 characters long, but not longer than 24
characters. It also uses cracklib and a supplied dictionary to make sure
that the password is sufficiently complex and not a dictionary word and
that it absolutely does NOT equal the current username of that user.
Don't laugh, but this is problem number one: username = password or a
variation of this where the username is an integral part of the
password. That throws the entropy right out of the window.

All in all the methods the GUI imposes on password changes do help, but
some sillishly simple passwords are still possible simply. Especially if
non-English dictionary words are part of the password. And of course: It
could be that you still have some user accounts around that came aboard
via CMU and were never changed in the many years that we've been forcing
the complex password mechanism onto users. That's how I've been had back
in March this year as one legacy email user had been around since the
CentOS4 days and still must have used something stupidly simple as password.

The reason for the 24 character maximum length was perhaps CentOS 4.
Although it used MD5 for passwords which also supported unlimited length
passwords, the stored hashes were too short and collisions were easily
possible were two different passwords resulted in the same length
limited hash.

Speaking of this: The 24 character limit for password length can now be
bumped massively and I will publish an update for this within the next
few days. However, this is a somewhat complex change with effects on
PAM, password related Perl and PHP modules, CCEd code and CODB schema
files, so I need to test this really thoroughly before I can publish this.

> Of course with the features on BO once does not get many guesses but
> as a general rule it might be better to steer users in a better
> direction of easier to remember but harder to brute force passwords.

Generally I agree with the suggestions from this famous xkcd comic, but
passwords are always a hot topic to which everyone has his or her own
unique approach. Most of which aren't bad either. Forcing people to
change their behavior (or their passwords) usually alienates them or
gets them onto the barricades.

For example I hate it when Google, Apple, Steam or Amazon don't allow me
to re-use prior passwords, even if they were unique (and certainly not
used somewhere else), sufficiently complex and still easy enough to
remember. Because that's how you easily forget them after such a forced
password change. Especially if you don't have to type them in constantly.

The cracklib implementation we did for BlueOnyx a few years ago was
certainly a necessary and good step, but off and on I still get some
funny remarks about it from users.

All in all: If we can offer more ways to implement better password
implementations to users (without taking anything away that's not
absolutely necessary), then that's a good idea. Like allowing longer
passwords than 24 characters.

As for brute force password guessing attempts: The GUI comes with
PAM_ABL out of the box, which is better than nothing. But it's still a
good idea to augment that with Fail2ban from the BlueOnyx shop.

However: I've seen enough cases where Botnets have been used for
password guessing and against that a method that blocks an offending IP
after so and so many password failures might not be good enough. I've
seen attempts where they immediately continued from another IP once a
previous one had been blocked. Or where the attack was so distributed
that they remained under the blocking threshold by not re-using the same
IP for these tests for a long enough period to not trigger the defenses
at all.

If this becomes more common, we might need something that takes an
overall look at failed logins for users (user based, not IP based) and
then raises a red flag. Which could include temporarily not allowing any
logins for a while for that user unless the IP(s) he comes from
succeeded with a login in the past and had next to no recent login
failures. However: This will be so error prone and potentially upsetting
for users, that it must raise a notice to the server admin whenever this
limit is enforced, so that he knows about it during the inevitable
support call from that upset client. So if this comes, it might be best
if it just hollars and lets the server admin know before it does
anything drastic.

-- 
With best regards

Michael Stauber