Jonathan Billings billings at negate.org Tue Feb 3 20:35:44 UTC 2015 > Honestly, of all the faults and foibles in the Red Hat/CentOS installer, > I'm > amazed that someone is complaining about that. Someone is trying to keep the scope of such faults and foibles on topic, otherwise they'd easily be tempted to get carried away. "Oh No! They released a > product that's *incrementally* more secure than before! Heavens > Above! (faints)" I agree it's incremental, in the realm of turning hours into days, or days into weeks. I think we're well past 8 character passwords taking centuries to crack by brute force. Therefore I think it's a distraction, pointlessly incremental for staving off remote login attacks. The common attack vectors on users gets them to reveal their password, no matter its length. Or tricks them into agreeing to escalating process privilege even without a password. If you want something meaningful, disabling sshd by default has a more meaningful effect, and it's more typical (at least in terms of deployment volume) so everyone should be familiar with the idea. This is one of those decisions many software products have to make: > Weighing the general security gained by requiring somewhat more secure > passwords against the inconvenience of having to remember a somewhat > more secure password. Since it's possible to get around the > requirement in multiple ways, it makes sense to lean toward the more > secure option. Make it inconvenient to be less secure. I can set "moon" as the password on OS X, as an admin. Do you think a company, and its users, with such a big target on their backs, haven't considered the benefit of requiring somewhat more secure passwords? So far they've spent quite a lot of development effort (their own and 3rd party developers) on sandboxing functionality and constant policy adjustments over the past few years. If it were worth it, it'd be a lot easier to just say, shift the burden to the user, and make them pick a 10 character password. Chris Murphy