On Jul 28, 2015, at 2:46 PM, Chris Murphy <lists at colorremedies.com> wrote:> > My dad will absolutely stop using his iPad if it ever > requires him to use anything more than 4 numeric digits for his > password. The iPad never leaves the house.iPads can?t be coopted into a botnet. The rules for iPad passwords must necessarily be different than for CentOS.> the Mac has SSH PKA required.True, but more on-point here is that OS X ships with sshd disabled by default. You have to dig into the pref panes and tick an obscurely-named checkbox to enable it.> Their online services are another > matter, those I've made very clear they will be strong or they don't > get to play.The Apple ID password rules are a fair bit stronger than the libpwquality rules we?ve been discussing here, and have been so for some time: https://support.apple.com/en-us/HT201303 Given that recent OS X releases want to use your Apple ID as the OS login credentials, that effectively makes these the OS password quality rules, too. Fedora is late to the party, and CentOS consequently even later.
On Tue, Jul 28, 2015 at 5:46 PM, Warren Young <wyml at etr-usa.com> wrote:> On Jul 28, 2015, at 2:46 PM, Chris Murphy <lists at colorremedies.com> wrote: >> >> My dad will absolutely stop using his iPad if it ever >> requires him to use anything more than 4 numeric digits for his >> password. The iPad never leaves the house. > > iPads can?t be coopted into a botnet. The rules for iPad passwords must necessarily be different than for CentOS.Windows has a lower minimum acceptable password quality than CentOS. OS X has a lower minimum still than Windows - as in, a single number is accepted. For an admin. With sshd enabled. And yet the Mac world does not burn. That doesn't mean single digit passwords are good, or should be recommended. It just means Apple doesn't care to fight that battle, or dump requirements onto the user. Instead they dump requirements onto the OS and onto application developers with better defaults: sshd is disabled, application binaries must be signed, App Store applications run in something like a sandbox, etc. So they are building up defenses elsewhere, rather than shifting the responsibility onto the user in the form of weird and confusing password requirements and the commensurate UI.> >> the Mac has SSH PKA required. > > True, but more on-point here is that OS X ships with sshd disabled by default. You have to dig into the pref panes and tick an obscurely-named checkbox to enable it.Two points of clarity: 1. the quoted text above is a configuration change I made; OS X does not require PKA out of the box. 2. Fedora Workstation has sshd disabled by default, and you have to dig into the pref panes to enable an identically named service "Remote Login"; although enabling it takes solidly three more clicks on GNOME than OS X. So in some strange sense it's less likely to be inadvertently enabled on GNOME.>> Their online services are another >> matter, those I've made very clear they will be strong or they don't >> get to play. > > The Apple ID password rules are a fair bit stronger than the libpwquality rules we?ve been discussing here, and have been so for some time: > > https://support.apple.com/en-us/HT201303 > > Given that recent OS X releases want to use your Apple ID as the OS login credentials, that effectively makes these the OS password quality rules, too.No that's not true. The user is encouraged to authenticate this way, they are not required to, it's very easy to bypass. I don't use it. Windows has a similar behavior, but rather strongly implies it's the only way to setup a user account (via an Outlook account) but that too can be bypassed. What is currently in Anaconda master branch, which is how Fedora Rawhide has behaved for ~ 6 months, is you get a show stopper installation if you don't meet the minimum password requirement. And that requirement is not stated or explained. It's basically "it's not good enough, try again".> Fedora is late to the party, and CentOS consequently even later.Where Fedora and CentOS are late to the party are improving defenses that don't require the user to do anything differently. -- Chris Murphy
> On Jul 28, 2015, at 5:46 PM, Warren Young <wyml at etr-usa.com> wrote: > > The Apple ID password rules are a fair bit stronger than the libpwquality rules we?ve been discussing here, and have been so for some time: > > https://support.apple.com/en-us/HT201303 > > Given that recent OS X releases want to use your Apple ID as the OS login credentials, that effectively makes these the OS password quality rules, too.Disingenuous. It does not REQUIRE you to use your AppleID as the user password, and it?s probably not a good practice anyway. Using it as an example is silly, in that it LOWERS security. Comparing CentOS (an OS quite often used on servers on well-protected networks) to a consumer-grade OS that wants to integrate your login to ?the cloud?, is rediculous. Of COURSE the defaults for a cloud connected machine are higher. Nate
On Jul 29, 2015, at 2:51 PM, Nathan Duehr <denverpilot at me.com> wrote:> >> On Jul 28, 2015, at 5:46 PM, Warren Young <wyml at etr-usa.com> wrote: >> >> The Apple ID password rules are a fair bit stronger than the libpwquality rules we?ve been discussing here, and have been so for some time: > > Disingenuous. It does not REQUIRE you to use your AppleID as the user password, and it?s probably not a good practice anyway.I don?t see how you got any requirement from my post. I pointed out that it was only a ?want? in the post you quoted. I?m not trying to obscure anything, just pointing out that other OSes are in fact already moving toward libpwquality-like restrictions. Windows 8+ makes bypassing the cloud login even more difficult than Apple does, and Chrome OS doesn?t even offer the option. iOS requires a cloud login now on hard boots. It allows a short PIN for unlocking a device that is only sleeping, but the equivalent of that in CentOS would be a separate password on the X screensaver, which really isn?t on-point here. I assume Android does this now, too. (Haven?t used Android myself since 2.3.) The important point is that there?s a clear trend here. The fact that you can currently bypass the cloud login in some of these cases does not invalidate that point.> Using it as an example is silly, in that it LOWERS security.Really? As others have already pointed out in this thread, the local-only password policy on these OSes is far weaker than the rules proposed for F23. Human nature and the contents of this thread should tell you how many people will use stronger local passwords than these cloud services demand. You may point out that the move to a cloud authentication system extends the attack surface out into the public Internet, but when you implement a public login service using strong security ? as it appears that Apple, Google, and Microsoft have done ? it?s still a net win. As I have already pointed out, a 9-character purely-random password can survive a million years of constant pounding with reasonable rate limiting. Given that Microsoft, Apple, and Google all do more than just rate limiting on their cloud login systems, that means that even a relatively short but random password will survive any sustained frontal attack. Offline attacks are far more dangerous, but strong mitigations for those have been well-known for decades. I assume that Google, Apple and Microsoft are using these techniques to defeat offline attacks, in case their secure password stores are ever compromised. (Key derivation, salting, hashing, zero-knowledge proofs...) I am not wholeheartedly in favor of these cloud login systems, nor am I arguing that CentOS 8 should have one, too. I am only pointing out that the security features they?ve all been designed with are worth emulation in CentOS?s local-only password authentication system, too.> Comparing CentOS (an OS quite often used on servers on well-protected networks)CentOS should not require a well-protected network in order to be secure. It should be secure in its own right, from the moment it first boots after installation. Anyway, your premise that your CentOS boxes are on networks so well protected that you don?t need strong passwords is quite unsound: https://en.wikipedia.org/wiki/Stuxnet https://en.wikipedia.org/wiki/Certificate_authority#CA_compromise https://en.wikipedia.org/wiki/RSA_SecurID#March_2011_system_compromise I doubt your LAN is more secure than that of RSA, Iran?s nuclear program, and several CAs. Security professionals do not rely solely on borders to secure individual systems. They rely on defense in depth, a concept at least as old as the ancient Greek phalanx formation: https://en.wikipedia.org/wiki/Phalanx