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

[Lewis Gardner]

Michael,

It is very difficult to keep people from harming themselves, and others...

I'm glad to get more clarity on this issue since it is a question I have 
to answer on a regular basis. I think Munroe's suggestion is a good one 
and it is very interesting that his example is exactly 24 characters. 
Maybe this is a common limitation.

I have been suggesting his method of longer plain passwords as a simpler 
method for users to have more secure and easier to remember passwords. I 
did notice that when I entered a password longer than 24 characters the 
GUI never warned that password is too long. It just wouldn't save and 
gave a fairly cryptic error message indicating that the second entry of 
the password field must be fixed.

Thanks for your thoughtful response!


Michael Stauber wrote:
> 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.
>