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 _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx