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