On 25/07/15 18:24, Scott Robbins wrote:

On Sat, Jul 25, 2015 at 11:16:18AM -0600, Chris Murphy wrote:

...

On Sat, Jul 25, 2015 at 9:40 AM, Scott Robbins scottro@nyc.rr.com wrote:

...

This might show up twice, I think I sent it from a bad address previously. If so, please accept my apologies.

In Fedora 22, one developer (and only one) decided that if the password chosen during installation wasn't of sufficient strength, the install wouldn't continue. A bug was filed, and there was also a great deal of aggravation about it on the Fedora testing list. So, it was dropped.

However, like a US (and probably other countries) politician who has one bad law suddenly exposed, it seems they are doing it for F23, judging from a test installation. I've filed a bug if anyone wants to chime in and ask them not to do it.

https://bugzilla.redhat.com/show_bug.cgi?id=1246771

This is a good write up on the story: https://lwn.net/Articles/639405/

And the proposal for Fedora 23: https://fedoraproject.org/wiki/Changes/Standardized_passphrase_policy

And the discussion for Workstation's behavior: https://lists.fedoraproject.org/pipermail/desktop/2015-July/012588.html

Kevin Fenzi responded to my post on Fedora testing saying that at least it is FESCO decisions this time, not just a one man one, and asked for patience. (My knee-jerk response is why are they even discussing it after last time, but I refrained.) Thank you for the links Chris.

I can certainly see why it can annoy certain people.

I think a better solution to suite both worlds would be to simply have a boot flag on the installation media such as maybe "passwordcheck=true/false" to enable/disable the strength and check features of password entry and simply show a text box (and confirm) if it is disabled without any password checking.

This way those who need the check disabled for quick deployments can do so and put a stronger password in later at their own time and choosing.

Meanwhile those who wish to have the password checked can also do so.

Thus, both people happy :-).

Personally, I am neither against the idea, nor for it. It doesn't affect me as I usually use strong passwords regardless.

Kind Regards, Jake Shipton (JakeMS) Twitter: @CrazyLinuxNerd GPG Key: 0xE3C31D8F GPG Fingerprint: 7515 CC63 19BD 06F9 400A DE8A 1D0B A5CF E3C3 1D8F

On 07/25/2015 05:00 PM, Gordon Messmer wrote:

On 07/25/2015 11:45 AM, Jake Shipton wrote:

...

I think a better solution to suite both worlds would be to simply have a boot flag on the installation media such as maybe "passwordcheck=true/false"

https://xkcd.com/1172/

It's practically a law that every time someone's workflow is broken, they request an option to change it. Personally, I'm against it. Putting a weak password into the installer *is* a request for a weak password. There's no reason to request a weak password twice (with a boot arg and a weak password) when the alternative is to graphically represent the password strength and let the user decide.

I don't like the change, but at the same time I do all of my installs with kickstart, and such installs are not affected. Kickstart files can contain a hashed password, and since a hashed password can't be checked, it can't be rejected. Thus, any decision FESCO makes won't affect me at all.

One thing that people don't understand or don't want to address is that most KNOWN instances of a Linux machine being hacked/owned/pwned/taken over (substitute your word here) and then rooted happen because of weak passwords.

It is certainly one's own right (at least in my country) to be completely and utterly stupid with your decision making ... but if you have any paying clients who have information on any machines you manage and said clients information gets stolen, if you have weak passwords then expect to shell out some cash for your stupid decision making.

Thank God we are not still using the computer code we did in 1991 when Linux started. Changes impact people, but good for us that the code has changed and moved forward.

If people want weak passwords, I guess you can let people have them .. but it is an idiotic thing to do. It is also one that makes you liable if you lose someone's privacy information because of your decision.

That is just MY opinion .. yours may vary.

Thanks, Johnny Hughes

On Sat, 25 Jul 2015 11:16:18 -0600 Chris Murphy lists@colorremedies.com wrote:

On Sat, Jul 25, 2015 at 9:40 AM, Scott Robbins scottro@nyc.rr.com wrote:

...

This might show up twice, I think I sent it from a bad address previously. If so, please accept my apologies.

In Fedora 22, one developer (and only one) decided that if the password chosen during installation wasn't of sufficient strength, the install wouldn't continue. A bug was filed, and there was also a great deal of aggravation about it on the Fedora testing list. So, it was dropped.

However, like a US (and probably other countries) politician who has one bad law suddenly exposed, it seems they are doing it for F23, judging from a test installation. I've filed a bug if anyone wants to chime in and ask them not to do it.

https://bugzilla.redhat.com/show_bug.cgi?id=1246771

This is a good write up on the story: https://lwn.net/Articles/639405/

And the proposal for Fedora 23: https://fedoraproject.org/wiki/Changes/Standardized_passphrase_policy

And the discussion for Workstation's behavior: https://lists.fedoraproject.org/pipermail/desktop/2015-July/012588.html

Something like this?

Sorry, your password has been in use for 30 days and has expired - you must register a new one." New password roses "Sorry, too few characters." pretty roses "Sorry, you must use at least one numerical character." 1 pretty rose "Sorry, you cannot use blank spaces." 1prettyrose "Sorry, you must use at least 10 different characters." 1fuckingprettyrose "Sorry, you must use at least one upper case character." 1FUCKINGprettyrose "Sorry, you cannot use more than one upper case character consecutively." 1FuckingPrettyRose "Sorry, you must use no fewer than 20 total characters." 1FuckingPrettyRoseShovedUpYourAssIfYouDon'tGiveMeAccessRightFuckingNow! "Sorry, you cannot use punctuation." 1FuckingPrettyRoseShovedUpYourAssIfYouDontGiveMeAccessRightFuckingNow "Sorry, that password is already in use."

BR, Bob Who thinks the password policy in my machines are my concern.

Once upon a time, Warren Young wyml@etr-usa.com said:

Much of the evil on the Internet today — DDoS armies, spam spewers, phishing botnets — is done on pnwed hardware, much of which was compromised by previous botnets banging on weak SSH passwords.

Since most of that crap comes from Windows hosts, the security of Linux SSH passwords seems hardly relevant.

Your freedom to use any password you like stops at the point where exercising that freedom creates a risk to other people’s machines.

Your freedom to dictate terms to me stops at my system, which you cannot access even if I set the password to "12345". You are making an assumption that every Fedora/CentOS install is on the public Internet, and then applying rules based on that (false) assumption.

When root can override a password policy after install, forcing a policy during install is nothing but stupid and irritating. Despite what was said on the Fedora list, this was an active change taken by anaconda developers (to take out the "click again to accept anyway" option), so they should expect people to complain to them and be prepared to handle the response.

On Tue, Jul 28, 2015 at 02:20:06PM -0500, Johnny Hughes wrote:

If RHEL releases source code that does not accept weak passwords, then we will rebuild that source code for CentOS Linux. If they later change the source code to add back weak password support, we will rebuild that too.

Whether we like or dislike the policy doesn't matter in the slightest .. we don't make those kind of choices in CentOS Linux .. we rebuild the RHEL source code.

For what it's worth, at the Fedora level, we are extremely, extremly unlikely to ship code which does not allow relatively-easy site-local configuration of password policy, regardless of whatever defaults we choose. It's also likely that Red Hat will choose different defaults from Fedora for RHEL. That's not my department, but I would certainly be surprised if *that* comes out in a way that doesn't make setting your own policy simple as well, because that's something people want and need.

On 07/28/2015 01:46 PM, Chris Murphy wrote:

Future concern is IPv6 stuff, now that Xfinity has forcibly changed their hardware to include full IPv6 support. I have no idea if this is NAT'd or rolling IPs or what.

All of the routers I've seen merely firewall inbound traffic, allowing none. There's no need for NAT or rolling IPs.

On 07/28/2015 02:08 PM, Chris Murphy wrote:

The whole idea of IPv6 is that, with proper authentication and encryption, we can access any device anywhere. So firewalling everything centrally would appear to break that.

I think you're assuming that IPv6 carries with it a policy, when it is merely the mechanism.

In IPv6, everything should have a unique, routeable address. Whether you can reach an address will be subject to local policy in the future, just as it is now. And just as you cannot currently reach a device in a Comcast/Xfinity residential network under IPv4, you can't under the default IPv6 rules either. I would call that the principle of least surprise.

You can open inbound IPv6 traffic for specific hosts on the routers I've seen.

On Tue, Jul 28, 2015 at 3:10 PM, Robert Wolfe Robert.Wolfe@malco.com wrote:

-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Chris Murphy Sent: Tuesday, July 28, 2015 3:46 PM To: CentOS mailing list Subject: Re: [CentOS] Fedora change that will probably affect RHEL

[...]

What you said:

"Windows Server has power shell disabled by default. The functional equivalent, sshd, is typically enabled on Linux servers. So I think it's overdue that sshd be disabled on Linux servers by default, especially because the minimum password quality under discussion is still not good enough for forward facing servers on the Internet with static IPv4 addresses. They will get owned eventually if they use even the new minimum pw quality, and that's why I see pw quality as the wrong emphasis - at least for workstations."

And my reply:

For things like SSH and RDP I use two-factor authentication using DUO. For the machines that I absolutely have to have these kinds of access two (my BBS for RDP and my mail server for SSH), this works well I think at providing an extra layer of security for both protocols and is quite affordable and is easy to administer.

OK but imagine making that the default, and how many workflows that don't need that level of authentication will be bothered in one form or another: a.) change workflow b.) learn how to revert the behavior.

It's one thing to disable sshd by default because pretty much everyone familiar with a particular distribution will be familiar with console/OOB enabling of sshd, or eventually being used to initially accessing a web interface to enable such a service.

On 07/28/2015 02:15 PM, John R Pierce wrote:

PowerShell does not by itself allow external connections, you'd need to configure a telnetd or sshd server to allow that

WinRM, more likely. Though I understand the MS is working on an SSH server for powershell for some future release.

On Tue, Jul 28, 2015 at 5:46 PM, Warren Young wyml@etr-usa.com wrote:

On Jul 28, 2015, at 2:46 PM, Chris Murphy lists@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.

On Jul 29, 2015, at 2:51 PM, Nathan Duehr denverpilot@me.com wrote:

...

On Jul 28, 2015, at 5:46 PM, Warren Young wyml@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

On Jul 28, 2015, at 1:06 PM, Chris Adams linux@cmadams.net wrote:

Once upon a time, Warren Young wyml@etr-usa.com said:

...

Much of the evil on the Internet today — DDoS armies, spam spewers, phishing botnets — is done on pnwed hardware, much of which was compromised by previous botnets banging on weak SSH passwords.

Since most of that crap comes from Windows hosts

Cite?

Not that it’s relevant, since even if the skew were 9:1, that’s no excuse for not trying to clean up our 10%.

...

Your freedom to use any password you like stops at the point where exercising that freedom creates a risk to other people’s machines.

Your freedom to dictate terms to me stops at my system

That sounds an awful lot like the old canard, “Your right to swing your fist stops at the tip of my nose.” Go down to the local drinking hole tonight and start swinging your fist to within a millimeter of peoples’ noses, and see how far that legal defense gets you.

The only reason we don’t have specific laws that allow the government to force specific password quality policies is that we’ve been trying to self-govern. If you fight our efforts at self-government, you open the door to heavy-handed external government.

You are making an assumption that every Fedora/CentOS install is on the public Internet,

No, I am making the assumption that the vast majority of CentOS installs are racked up in datacenters, VPS hosts, etc. I am further assuming that most of those either have a public IP, or are SSH-accessible once you get past a LAN/WAN border firewall.

A border gateway doesn’t help you with weak SSH passwords if a box on the LAN gets pwned and turned into an SSH password guesser.

The effort to get stronger password minima into Fedora goes back at least four years:

https://fedoraproject.org/wiki/Features/PasswordQualityChecking

If it’s finally time to get it into Fedora, it’s *long* past time to get it into RHEL/CentOS, since those boxes are statistically far more likely to be directly exposed to the Internet.

When root can override a password policy after install, forcing a policy during install is nothing but stupid and irritating.

That’s only true if the majority of people will in fact override the default policy. But as I have repeatedly pointed out here, the stock rules really are not that onerous. They basically encode best practices established 20 years ago.

On Jul 28, 2015, at 5:17 PM, Chris Murphy lists@colorremedies.com wrote:

On Tue, Jul 28, 2015 at 4:34 PM, Warren Young wyml@etr-usa.com wrote:

...

But as I have repeatedly pointed out here, the stock rules really are not that onerous. They basically encode best practices established 20 years ago.

In order to protect a system that's Internet facing with challengeresponseauth (rather than PKA)

In the context of SSH, challenge/response authentication generally means things like OTP fobs and smart cards. It is not a synonym for password auth, it is an alternative to it.

Some definitions of C/R do include password auth under the same umbrella, but SSH uses the term in a more narrow sense, where it means any system where the actual credentials do not cross the wire, only a trapdoor response from which you cannot reverse-engineer the credentials. In that sense, PKA is also a form of C/R auth, though the OpenSSH docs don’t use the term that way.

the minimum password quality would need to be at least initially onerous.

Not true. CentOS 7 limits SSH password guesses to about 50 per second, and then only if you can rope 100 attackers together to go after a single account. A random 9-character password will withstand about a million years of such pounding.

You only need to go beyond that when you’re trying to fend off offline attacks, such as clusters of GPU number crunchers tearing through /etc/shadow.

Whereas if things are properly configured such that ssh is only used internally

I don’t have the luxury of setting such a boundary. I must access remote systems via SSH all the time to do my job.

If your alternative is a VPN, all you’ve done is shift the burden, since that is equivalent to PSK and strong passwords in SSH. In fact, properly configured, SSH is a form of VPN.

On Wed, Jul 29, 2015 at 02:17:23AM +0200, Timothy Murphy wrote:

Is that true, I wonder? For some reason Fedora and CentOS seem reluctant to find out anything about their users (or what their users want).

I can't speak for CentOS, but Fedora, at least, this is absolutely not true. It's just a difficult and expensive thing to do in a meaningful way (and there's considerable concern that doing it in a non-scientific way does more harm than good). So, we do the best we can given the channels we have.

On 07/28/2015 09:01 PM, Chris Murphy wrote:

On Tue, Jul 28, 2015 at 6:17 PM, Timothy Murphy gayleard@eircom.net wrote:

...

Warren Young wrote:

...

No, I am making the assumption that the vast majority of CentOS installs are racked up in datacenters, VPS hosts, etc.

Is that true, I wonder? For some reason Fedora and CentOS seem reluctant to find out anything about their users (or what their users want).

This is just wrong .. we have started Special Interest Groups where people from other places come in a build things that they want who are the users (community). We have guys from arm companies (helping do arm64), Citrix (adding xen support in CentOS-6 and CentOS-7), IBM (building a ppc64 and ppc64le arch), Openstack (via RDO), Open Nebula, Project Atomic, Storage (via glusterfs and ceph) etc. We have guys from CERN helping run our Koji Community Build System. The CentOS-Devel list, where all this feedback is occuring has grown by 10 times since we started the SIG programs. We have several projects in the 2015 Google Summer of Code where the community has input into add on projects for CentOS (like a 32 bit armv7 image builder).

This is confusing. I think it's overwhelmingly, abundantly clear that Fedora care about their users and are listening. CentOS cares with a hard and fast upper limit which is binary compatibility with RHEL. So if you want to change CentOS behavior you'd have to buy into RHEL and convince Red Hat, and then it'd trickle down to CentOS.

This is also true that CentOS Linux, the base, is just a plain rebuild of RHEL source code. That is what it is and what it will always be .. the SIGs (where are building much community interaction) are optional addons to that base.

On Wed, Jul 29, 2015 at 05:58:51AM -0400, Scott Robbins wrote:

I've seen various decisions made by Fedora, which weren't even necessarily bad for its apparent target audience, the desktop user, that, while not insurmountable, get put into RHEL, and therefore CentOS.

I would highly recommend looking into Fedora Server; over the past couple of years, we've made a deliberate effort to address Fedora's cloud computing and traditional server userbases as intentional target audiences. Take a look at

* https://fedoraproject.org/wiki/Server/Product_Requirements_Document#User_Pro... * https://fedoraproject.org/wiki/Cloud/Cloud_PRD?rd=Cloud_PRD#User_Profiles.2C...

and see if you feel like your uses are better represented.

Fedora has made several decisions where a developer or developers will ignore popular opinion. I remember when pkgkit would allow any user to update through the GUI without authentication and it took the story making the front page of slashdot to get it changed.

It may have seemd that way, but I don't think Slashdot was a major factor in this decision either.

Like any organization, Fedora has some people who are very responsive to user input and others who aren't. To me the reason to make noise about something in Fedora is to try to keep it from getting into RHEL and hence CentOS.

I'd like to encourage you to think of this in a different direction. Instead of interacting with Fedora when you want to stop a decision you don't like, help us build something you *do* like.

When people just scream "this new password policy is the worst thing ever quit doing things differently!", developers who are genuinely trying to make things better get discouraged, and while dissuading someone from contributing in this way may _feel_ like a victory when it was something you didn't like, it's a loss long term. So, instead: "I have the use case ABC, which doesn't seem to fit in. I think it's an important situation for target audience, so I propose...".

And, as always, triple bonus points when there's a complete design or an example implementation, because we certainly don't lack for _ideas_.

On 07/29/2015 06:00 AM, Timothy Murphy wrote:

Chris Murphy wrote:

...

...

...

No, I am making the assumption that the vast majority of CentOS installs are racked up in datacenters, VPS hosts, etc.

...

...

Is that true, I wonder? For some reason Fedora and CentOS seem reluctant to find out anything about their users (or what their users want).

...

This is confusing. I think it's overwhelmingly, abundantly clear that Fedora care about their users and are listening. CentOS cares with a hard and fast upper limit which is binary compatibility with RHEL. So if you want to change CentOS behavior you'd have to buy into RHEL and convince Red Hat, and then it'd trickle down to CentOS.

You (and others) are misunderstanding my off-the-cuff remark. It was purely an observation about the lack of statistics. I rarely if ever see a statement of the kind "Among Fedora users 37% use KDE and 42% Gnome". Or (after the remark I was responding to) "83% of CentOS machines are in datacenters, and 7% are home-servers". (Or "x% of Fedora users have turned SELinux to permissive".)

I'm not saying that Fedora or CentOS should work on democratic principles. I welcome Johnny Hughes unambiguous statement that CentOS follows RHEL. This saves a lot of time arguing about things that cannot be changed.

But I hold the (old-fashioned?) view that before expressing an opinion one should get the facts.

We can't gather facts about people .. people go bat shit crazy if their machines report stuff back.

At CentOS, we can't even tell you how many users we have, because we can't possibly buy all the mirrors that are required to give out updates to all users.

Instead, we have a couple hundred mirrors JUST to distribute CentOS to external mirrors run by the community (currently 624 mirrors in 85 countries) when we do a release. We don't have the ability to gather statistics on servers we don't own.

Fedora is in the same boat.

On 07/28/2015 03:06 PM, Chris Adams wrote:

Once upon a time, Warren Young wyml@etr-usa.com said:

...

Much of the evil on the Internet today — DDoS armies, spam spewers, phishing botnets — is done on pnwed hardware, much of which was compromised by previous botnets banging on weak SSH passwords.

Since most of that crap comes from Windows hosts, the security of Linux SSH passwords seems hardly relevant.

I happen to know from firsthand experience that SSH slow bruteforcers on Linux are a significant portion of the 'botnet' traffic out there. How do I know this? From a hacked Linux server which was brute-forced and conscripted into being a slow bruteforcer node back in 2009 or so. The particular payload that was dropped on that box was dropped into a normal user account with a moderately strong (but obviously not strong enough) password, and the code never even attempted to escalate privileges. It didn't need to; the slow bruteforcer started and ran as the normal user account and actively attacked other hosts. It did not attempt to install a rootkit and it ran as a normal user with a program name of something that was not out of the ordinary. It did not trigger our rootkit detector or file modification monitors, since normal user directories aren't normally monitored. Again, the attack vector was a relatively weak password (mixed case, letters and numbers, but less than ten characters long). And it ran slow enough that neither snort nor fail2ban were triggered.

While I am not at liberty to share the specifics of the code or the huge password files it contained, nor can I share the log files, given the amount of traffic generated and its patterns it is pretty easy to figure out that it was part of a very large operation. Due to this we now block outgoing (and incoming) SSH on port 22 by default now, opening holes only upon request (and we're small enough to make that practical). A quick analysis of the code showed some polymorphism in use. The particular slow bruteforcer I found has been adequately documented elsewhere, so I won't go into more details here. But suffice to say that the password file included some very long and random-looking passwords, along with a million words and regexes (a mixed letters and numbers password with '1337' (leet) spelling should be considered as easy to break as that same password spelled with letters only). And looking through my logs I could see attempts on several user ID's from entirely unique IP addresses; no IP address was used more than once.

Better enforcement of password policy on that server would have prevented the attack from succeeding and the machine becoming an attacker itself.

On Tue, Jul 28, 2015 at 11:27 AM, Warren Young wyml@etr-usa.com wrote:

Much of the evil on the Internet today — DDoS armies, spam spewers, phishing botnets — is done on pnwed hardware, much of which was compromised by previous botnets banging on weak SSH passwords.

Your freedom to use any password you like stops at the point where exercising that freedom creates a risk to other people’s machines.

Your freedom to have sshd enabled by default stops at the point where exercising that freedom creates risk to other people's machines.

I can also use that logic with, password based auth by default, rather than PKA by default.

A rather strong argument can be made, much more so than a very weak > weak password quality policy, for sshd on a default 7 day disable timer. That is, by default, after 7 days, sshd is stopped and disabled. In the autopsies of pwned computers is the quickly provisioned server with a standard simple in-house password for such things, with the idea that after configuration the password will get changed or more likely sshd is disabled or it'll be added to firewall filtering. The reality is all the bad practices happen because this quickly provisioned machine is forgotten about for one reason or another, and then it gets owned.

Well, disabling sshd after 7 days would stop all of that and yet doesn't prevent initial configuration.

More likely, I think we'll see either sshd disabled by default or PKA required by default, both being provisioned via Cockpit. And that's because the minimum password quality under discussion is still rather weak when it comes to being able to put a system directly on the Internet or facing it with port forwarding while taking no other precautions. And yet the weak password policy is too strong for many legitimate use cases where the use case/environment aren't high risk for such passwords.

On Tue, Jul 28, 2015 at 5:29 PM, Warren Young wyml@etr-usa.com wrote:

On Jul 28, 2015, at 2:27 PM, Chris Murphy lists@colorremedies.com wrote:

...

On Tue, Jul 28, 2015 at 11:27 AM, Warren Young wyml@etr-usa.com wrote:

...

Your freedom to use any password you like stops at the point where exercising that freedom creates a risk to other people’s machines.

Your freedom to have sshd enabled by default stops at the point where exercising that freedom creates risk to other people's machines.

You’re offering a false choice. We do not have to choose between cutting the tree down or leaving the fruit to rot on the twig. Fedora is rightly choosing to pick this low-hanging fruit.

Disabled by default is in no way cutting the tree down. It happens to be the default on Fedora Workstation. While Fedora Server currently leaves it enabled, there has been some discussion of disabling it by default when Cockpit has a switch for enabling it, and then expect it to be enabled there - that way it's opt in rather than opt out. And the problem with opt out is a lot of users don't know this service is running and exposes them to infiltration unless they have a strong passphrase or use PKA.

If you want a Linux distro that doesn’t ship with sshd enabled by default, that is already available. Given that CentOS does ship with sshd enabled by default, it makes sense that it should not allow itself to be so badly misconfigured that it allows trivial exploits.

Well that's rather difficult for it to know the environment it's in, which is why there's such a thing as defaults. Many people have no idea sshd is enabled by default, meanwhile everyone could voluntarily choose stronger passphrases. Opt out vs opt in, and opt in assures the person doing the setup is making a conscious decision.

...

I can also use that logic with, password based auth by default, rather than PKA by default.

That’s more low-hanging fruit; we might get there someday.

That requires UI work and coordination seeing as it requires a service made active on one computer and keys made on each computer that will access that server, and then a mechanism to securely transfer the pub key to the server. This is non-trivial.

They turned off "PermitRootLogin yes" and "Protocol 1" in EL6 or EL7, the previous low-hanging fruit. Do you think those were bad decisions, too?

Disabling Protocol 1 is a good decision because it negatively impacted essentially no one with sane workflows. The disabling of root I don't disagree with but I think it's specious.

...

A rather strong argument can be made, much more so than a very weak > weak password quality policy, for sshd on a default 7 day disable timer. That is, by default, after 7 days, sshd is stopped and disabled.

The stock PAM on-fail delay is about 2 seconds. I can’t see that sshd has any rate-limiting built into it, but it does limit the number of unauthenticated connections to 100 by default in EL7. Together, this means a small botnet could try 50 guesses at a single account’s password per second.

The current non-policy allows abc1 as a password. According to:

https://www.grc.com/haystack.htm

…that password can be brute-forced in about half an hour at 1000 guesses per second, or 4 days at 50/sec. Your 7-day window is too short, if you don’t institute *some* kind of password quality minima.

It was a number I pulled out of my ass, but it's still better than infinite. The proper value in this case is not one that always assures are particular passphrase won't be brute forced, but one that's high enough that the sysadmin leaves the timer feature intact, while low enough to thwart a non-targeted attack. If you're targeted, you're probably screwed short of a rather strong passphrase or PKA.

Of course, both iptables and firewalld also have rate limiting options. Maybe fail2ban is better because it can apply restrictions per IP so that legitimate attempts get through. I didn't realize PAM has a fail delay, that actually matters.

Also keep in mind that the GRC calculator is assuming you’re brute-forcing it, and not intelligently trying common passwords first, and sensible variations.

The stock rules currently allow “monkey” as a password, which the GRC calculator considers stronger than “abc1” due to the length, but it’s a top-10 most-used password, so it will be among the first to be tried by any intelligent attacker.

So now the problem with this type of policy enforcement in a GUI is you have to create instructions for the user to follow in order to successfully pick a minimally acceptable passphrase without iterating. Iteration means failure.

And no OS does this right now. Everyone is completely permissive because no one wants to replicate a UI across completely different applications: the installer, Gnome Initial Setup, and Gnome Users & Groups.

I still think informed consent is the way this will probably end up working - meaning the user is informed their password is common (dictionary word, derivative, or a top 10,000 most common password) should not be used but give them a way to use it anyway.

...

And yet the weak password policy is too strong for many legitimate use cases where the use case/environment aren't high risk for such passwords.

Really? Which of these new rules is onerous?

http://manpages.ubuntu.com/manpages/trusty/man8/pam_pwquality.8.html

All of them. Those rules are absurd to require by default on a computer in a low risk environment. I would never accept such a product that required such login rules.

On 07/28/2015 04:29 PM, Warren Young wrote:

They turned off "PermitRootLogin yes" and "Protocol 1" in EL6 or EL7, the previous low-hanging fruit. Do you think those were bad decisions, too?

As far as I know, PermitRootLogin has not been set to "no" by default. At least, I've never seen that on a system I've installed. Am I missing something?

On Jul 28, 2015, at 8:37 PM, Gordon Messmer gordon.messmer@gmail.com wrote:

On 07/28/2015 04:29 PM, Warren Young wrote:

...

They turned off "PermitRootLogin yes" and "Protocol 1" in EL6 or EL7, the previous low-hanging fruit. Do you think those were bad decisions, too?

As far as I know, PermitRootLogin has not been set to "no" by default.

My mistake. I grepped sshd_config on a fresh EL7 machine here and saw

#PermitRootLogin yes

and assumed it meant “no”. It’s just documenting the default.

I explicitly set it to “no” on systems I am solely in control of, and I’d prefer that upstream changed that default in the precursor(s) to CentOS 8, too. EL7 ships ready to use sudo out-of-the-box, if you tick the “administrative user” checkbox on the non-root user during install. That removes the last good reason to allow remote root logins by default.

On 07/30/15 19:56, Always Learning wrote:

On Tue, 2015-07-28 at 14:27 -0600, Chris Murphy wrote:

...

The reality is all the bad practices happen because this quickly provisioned machine is forgotten about for one reason or another, and then it gets owned.

Linux users take a lot more care, and pride, in maintaining their systems well and reading the daily logs too. Most increase security on their machines. They have no wish to lose their work, their time and effort investment and their increased Linux-enabled productivity.

Not always. I bet you are. But I support a big group of scientists, and when choosing Linux for laptop they usually pick Ubintu. Guess why? Because all just works, no need to invest (waste actually) their precious time into fiddling with the system. They can just do their science. I don't intend to blame anybody for what or how they do. I just would like everybody to realize the reality.

Valeri

If you want to offer advice and save the world from spam, viruses, Trojans and other crap, please join a Windoze forum and make your positive contribution there ;-)

Thanks,

On Jul 28, 2015, at 4:37 PM, Nathan Duehr denverpilot@me.com wrote:

...

On Jul 28, 2015, at 11:27, Warren Young wyml@etr-usa.com wrote:

So no, your local password quality policy is not purely your own concern.

Other than DDoS which is a problem of engineering design of how the network operates (untrusted anything can talk to untrusted anything)

I’m not sure how you mean that comment.

If you’re saying that the Internet is badly designed and that we need to rip it up and replace it before we can address DDoSes, you’re trying to boil the ocean. We have real-world practical solutions available to us that do not require a complete redesign of the Internet. One of those is to tighten down CentOS boxes so they don’t get coopted into botnets.

If instead you’re saying that DDoSes are solvable with “just” a bit of engineering, then that’s wrong, too. It takes a really big, expensive slice of a CDN or similar to choke down a large DDoS attack. I do not accept that as a necessary cost of doing business. That’s like a 1665 Londoner insisting that city planning can only be done with close-packed wooden buildings.

I don’t believe that the Internet must go through the equivalent of the Great Fire of 1666 before we can put our critical tech onto a more survivable foundation.

what “risk” is created to other people’s machines who have done appropriate security measures by a cracked machine owned by an idiot

Resource waste is enough by itself. How many billions of dollars goes into extra bandwidth, CDN fees, security personnel, security appliances, etc., all to solve a problem that is not necessary to the design of the Internet in the first place?

Back before the commercialization of the Internet, if your box was found to be attempting to DoS another system, you’d be cut off the Internet. No appeal, no mercy. It’s all /dev/null for you.

Now we have entrenched commercial interests that get paid more when you get DDoS’d. I’ll give you one guess what happens in such a world.

easily handled in minutes, if not seconds, by fail2ban?

fail2ban isn’t in the stock package repo for CentOS 7, much less installed and configured default. Until it is, it’s off-topic for this thread.

Mind, I’m all for fail2ban. If Fedora/Red Hat want to start turning it on by default, too, that’s great.

Equating this to “vaccination” is a huge stretch.

Why? If you are unvaccinated and catch some preventable communicable disease, you begin spreading it around, infecting others. This is exactly analogous to a box getting pwned, joining a botnet, and attempting to pwn other boxes.

When almost everyone is vaccinated, you get an effect called herd immunity, which means that even those few who cannot be vaccinated for some valid medical reason are highly unlikely to ever contract the disease because it cannot spread properly through the population.

It’s more like saying the guy who left his front door unlocked all day is a threat to the neighbor’s house.

That’s only true in a world where you have armed gangs running through the streets looking for free fortifications from which to attack neighboring houses. That is the analogous situation to the current botnet problem.

If that were our physical security situation today, then I would be advocating fortifying our physical dwellings, too.

Thankfully, that is not the case where I live.

The difference appears to be one of global society, rather than technology, but obviously we aren’t going to solve any of that here.

You can’t “catch the insecure”… hahaha… it’s not a virus.

Take an unvaccinated child on a long vacation to some 3rd world cesspit, then report back on how that worked out.

“Like every other creature on the face of the earth, Godfrey was, by birthright, a stupendous badass, albeit in the somewhat narrow technical sense that he could trace his ancestry back up a long line of slightly less highly evolved stupendous badasses to that first self- replicating gizmo — which, given the number and variety of its descendants, might justifiably be described as the most stupendous badass of all time. Everyone and everything that wasn't a stupendous badass was dead.”

― Neal Stephenson, Cryptonomicon

We don’t have time to wait for CentOS to become autonomous and evolve its own badass immune system. We have to give it one ourselves.

On Jul 28, 2015, at 8:50 PM, Chris Murphy lists@colorremedies.com wrote:

On Tue, Jul 28, 2015 at 6:32 PM, Warren Young wyml@etr-usa.com wrote:

...

On Jul 28, 2015, at 4:37 PM, Nathan Duehr denverpilot@me.com wrote:

...

...

Equating this to “vaccination” is a huge stretch.

Why?

It's not just an imperfect analogy it really doesn't work on closer scrutiny.

Every analogy will break down if you look too closely. The question is, is it a *useful* analogy?

...a login password is...about user authentication...not...meant or designed to provide immunity from malware.

Fine. If you want to be picky, a better analogy to a good password and reasonable limits on SSH logins is a healthy integument and healthy cell walls.

Has that changed any of the conclusions about bad passwords? No. Therefore we have succeeded in clarifying nothing except our application of biology, which is interesting, but not on topic here.

That we're trying to use it to prevent infections is more like putting ourselves into bubbles; and humans put into bubbles for this reason are called immune compromised.

Now it is you who are off the rails. The hygiene hypothesis explains a great deal about human disease because we have an active immune system to deal with an evolving set of biological challenges.

CentOS’s immune system doesn’t get stronger purely by subjecting it to more attacks. It improves only through human intervention.

So this push to depend on stronger passwords just exposes how "immune compromised" we are in these dark ages of computer security.

While true, that doesn’t tell us that it is a good idea to allow weak passwords.

If you will allow me to return to biology, it’s like saying that prophylaxis is a bad idea because it points out how imperfect our immune systems are. Stop covering your face when you sneeze, stop using condoms, stop going to the dentist: we need stronger humans, so let’s evolve some!

There are overwhelmingly worse side effects of password dependency than immunization.

That seems like a falsifiable statement, so I expect you will be able to point to a scientific paper that supports that assertion.

And also, a large percent of malware doesn't even depend on brute force password attacks.

So let’s dial back my previous proposal. We’ll just stop using dental prophylaxis, then, because it doesn’t prevent the contraction of oral STIs.

Just because one particular method of prophylaxis fails to protect against all threats doesn’t mean we should stop using it, or increase its strength.

On Jul 29, 2015, at 3:16 PM, Chris Murphy lists@colorremedies.com wrote:

On Wed, Jul 29, 2015 at 2:15 PM, Warren Young wyml@etr-usa.com wrote:

...

Just because one particular method of prophylaxis fails to protect against all threats doesn’t mean we should stop using it, or increase its strength.

Actually it does.There is no more obvious head butting than with strong passwords vs usability. Strong login passwords and usability are diametrically opposed.

Security is *always* opposed to convenience.

The question is not “security or no security,” it’s “how much security?”

The correct answer must balance the threats and risks. Given that the threats and risks here are nontrivial, the password quality restrictions should also be nontrivial.

The rate of brute force attack success is exceeding that of human ability (and interest) to remember ever longer more complex passwords.

You must consider offline and online attack scenarios separately.

Online we have already dealt with: 50 guesses max/sec, allowing a 9-character random password to survive a million years of constant attack.

Offline is an entirely separate matter, and is already addressed by /etc/shadow salting and hashing in CentOS. We know how to make it even stronger if the threat requires it: move to OTP keys, use a better KDF than SHA512, etc.

I just fired my ISP because of the asininity of setting a 180 compulsory expiration on passwords.

Good for you. Password expiration is silly. A good strong password should last years under any reasonable threat.

But we’ve not been talking about password expiration here.

The highest risk, by a lot, is from a family member.

Of course. It’s why Bruce Schneier wrote only one book on cryptography, but several on human factors.

That does not tell us that we should be sloppy with our crypto and authentication methods, though.

it doesn't scale

I’m still not seeing how it’s difficult to remember, securely record, type, or transcribe a password that will pass the new restrictions. They’re on the mild side, as these things go.

If you wanted to use the GRC password haystack calculator results to argue for a slight reduction in the defaults, I could get behind that.

Six random characters pulled only from the unambiguous subset of the alphanumeric set, no uppercase, and one symbol gets you a password that should withstand constant pounding for the life of the machine. I could live with that minimum.

I have no strong feelings on the new libpwquality rules, exactly. What I do feel strongly about is that there should be *some* reasonable minima that can’t easily be bypassed. Where that level is set is not only a sensible subject for debate, it is one that’s easy to separate from emotion; it’s basically a question of arithmetic.

Making policies opt out let alone compulsory is unacceptable.

I don’t see why we can’t take some responsibility for this mess and try to build up some herd immunity.

Even as the policies get stronger people's trust in password efficacy relating to security continues to diminish.

Passwords are what we have today. Strengthening them to a level that will suffice until something better comes along is reasonable.

On 07/29/2015 07:40 PM, Chris Murphy wrote:

On Wed, Jul 29, 2015 at 4:37 PM, Warren Young wyml@etr-usa.com wrote:

...

Security is *always* opposed to convenience.

False. OS X by default runs only signed binaries, and if they come from the App Store they run in a sandbox. User gains significant security with this, and are completely unaware of it. There is no inconvenience.

While I agree with you about the long-term viability of passwords, I'll disagree with this statement. There is a loss of convenience with signed binaries from a store: the user can no longer install directly from the program vendor's website but must go through the walled garden of the store, and developers are held hostage to having to meet the store's policy or get their signing key revoked and/or their app 'de-stored' or worse. There is significant inconvenience to users when their app is removed from the store for whatever reason and they cannot get updates (or reinstall their app, for which they may have paid a fee) anymore because the app is no longer in the store (and that could be for arbitrary reasons, including political ones). This is, of course, the case to a more limited degree with CentOS and signed packages, since packages can be removed from repositories and installation of packages by default requires signed packages (but it's not as inconvenient, nor is it as secure, as the OS X model of only allowing signed binaries to run). For that comparison, repository = store.

What is the inconvenience of encrypting your device compared to the security? Zero vs a ton more secure (either when turned off and data is at rest or a remote kill that makes it very fast to effectively wipe all data)

Or a hackable remote kill that allows an attacker to wipe you device out from under you. Or now the inconvenience of losing access to the encrypted volume because you forgot the exact spelling of that ten word seventy-five character passphrase and you're locked out and no data recovery tool out there will get your files back.

Security and convenience are always at odds with each other; more secure = less convenient in some form or fashion; even if you have to dig for the loss of convenience there will be a loss of convenience somewhere for increased security.

On Jul 29, 2015, at 5:40 PM, Chris Murphy lists@colorremedies.com wrote:

On Wed, Jul 29, 2015 at 4:37 PM, Warren Young wyml@etr-usa.com wrote:

...

Security is *always* opposed to convenience.

False. OS X by default runs only signed binaries, and if they come from the App Store they run in a sandbox. User gains significant security with this, and are completely unaware of it. There is no inconvenience.

You must not use OS X regularly, else you’d know there is plenty of inconvenience in this policy. There’s a whole lot of good software that is both unsigned and not in the App Store. Examples:

a. Most open source software. Many of these projects (e.g. KiCad) can barely manage to serve community-provided unsigned binaries on OS X as it is. Signing apps and managing the App Store submission process is out of the question. The next version of OS X will block all the third-party app repositories (e.g. Homebrew) by default, in order to provide better security:

http://www.imore.com/os-x-el-capitan-faq

b. Most network monitoring software, because putting en0 into promiscuous mode violates the Gatekeeper rules. (Wireshark, etc.) Some App Store networking software (e.g. RubberNet) manages to get around this by offering a second app download from the author’s web page. You don’t call that inconvenient?

c. Low-level utilities, such as Karabiner and Scroll Reverser, since they also need to bypass the sandbox guidelines to do their job.

On top of all that, to bypass Gatekeeper, you need to right-click an app and disable Gatekeeper for it on the first launch. Another inconvenience.

I’m not saying Gatekeeper and such are bad, only that they are in fact exemplars of the rule: better security always causes greater inconvenience.

What is the inconvenience of encrypting your device compared to the security?

I can’t hook my iPad up to my PC and browse it as just another filesystem, as I can with any other digital camera or MP3 player. Apple must do this in order to prevent sideloading malicious apps.

Did you see my exchange with James Byrne? His bogus counter to my claim that iPads can’t be turned into botnet conscripts was to point (very indirectly) to a paper where some researchers found a way to jump through a whole bunch of hoops to bypass all the security Apple had placed in the path of app sideloading.

Android doesn’t bother with most of this, and what security there is is bypassable with a checkbox in the Settings app. Consequence: a whole lot more Android devices are security-compromised than Apple ones.

So, yet another example where greater security is paid for with greater inconvenience.

There’s more: Until recently, Android didn’t encrypt the whole device to anywhere near the same extent that iOS has for years. Why? Because it costs either CPU time (hence more battery) or die space for low-energy hardware encryption (hence increased device cost). That’s one of the reasons Apple devices cost more than Android ones. That’s not merely an inconvenience for some, it’s a complete barrier to entry.

Good security is never free.

I will not participate in security theatre

Really? You’re going to lay *that* card in this game?

When you stretch words and phrases beyond their original meaning, they lose shape and utility.

6-9 character password limits are *not* "security theatre”.

I'm guessing you're not a tester

I write software for a living. Testing is not my primary job, but I do a fair bit of it.

or much of a home user.

I use computers at home far more than is good for me. :)

My home passwords have passed the new libpwquality rules for *years*.

My iOS ones do, too, by the way, despite the increased difficulty of typing them. I put too much of my life on them to use 4-digit PINs.

There are many such people using OS X, Windows, and yes Fedora and likely CentOS, where environments and use case preclude compulsory compliance because the risk is managed in other ways.

The Fedora project leader already said in this thread, multiple times, that this new policy will not be compulsory. I’m not asking for that, either. I’m merely agreeing that “double Done” makes the current restrictions so easy to bypass that they’re basically nonexistent.

I don’t know what Fedora or Red Hat will be doing to allow bypass, but I do know that libpwquality is configurable:

http://linux.die.net/man/5/pwquality.conf

...

there should be *some* reasonable minima that can’t easily be bypassed.

This idea that opt in is not sufficient demonstrates how archaic and busted computer security is when you have to become coercive to everyone regardless of use case to make it safe.

No, it demonstrates that, left to their own devices, most people will hang their assets out in the wind for anyone to slap.

There are numerous laws and insurance restrictions that require locks and safety mechanisms on all sorts of things. How many of those locks would continue to be provided as a matter of course if those laws and provisions did not exist?

...

I don’t see why we can’t take some responsibility for this mess and try to build up some herd immunity.

Because there is no such thing when it comes to computers.

Pay more attention to history.

Once upon a time, we had the likes of Blaster, Code Red and Nimda, which continuously flooded the internet with traffic intended to find exploitable holes in Microsoft OSes. They kept finding new boxes so frequently that normal efforts consistent with contemporaneous practice entirely failed to stamp them out.

https://en.wikipedia.org/wiki/Code_Red_(computer_worm) https://en.wikipedia.org/wiki/Blaster_(computer_worm) https://en.wikipedia.org/wiki/Nimda

It got so bad that connecting a new Windows box to the internet without either a NAT router or a third-party software firewall would almost guarantee an infection within minutes:

http://blog.chron.com/techblog/2008/07/average-time-to-infection-4-minutes/

Then Windows XP SP2 came out, with Microsoft’s first enabled-by-default firewall, and these worms quickly died out. Windows acquired herd immunity to this whole class of attack.

Yes, herd immunity. There are still a few pre-SP2 XP boxes out there, but NAT routers and low infection rates mean the old 4-minuutes-to-infection rule no longer applies.

We didn’t get the immunity without a cost. I used to be able to “message” a remote Windows computer merely by knowing its IP, and I could browse its registry without jumping through hoops. Can’t do that any more.

Meanwhile over here in CentOS land, you still see SSH password guessers banging on every public IP that responds to port 22. Why? Because it still occasionally works. Increase the password strength minima, and this class of worm, too, will quickly die out.

Computers with strong passphrases still sometimes get pwned

The occasional failure of a prophylactic measure does not tell you that you should discontinue its use.

and at a much higher rate than vaccines not working.

I thought you threw out a 95% number for vaccine effectiveness above. You are saying that more than 5% of all computers with strong passphrases are currently infected with something? Prove it.

Anyone without vaccines in such proximity to illness would definitely get sick.

Not true. Some people have innate immunity, and others can fight off the infection.

This doesn’t demolish the analogy, though, it just shows that computers are even worse than humans at fighting off attacks. Unlike humans, computers either have a block already in place against the attack, or they do not.

The environment has changed, and the old architectures and methods aren't working the way they did. And somehow free open source software has got to do better than it has been with security, because proprietary systems are innovating more in this space right now, and aren't passing the buck onto the user with this burden in the form of stronger password requirements.

So your solution is to wait for unspecified innovations to come? All these problems will go away in the indefinite future, so we should do nothing now?

Tom Bishop wrote:

On Thu, Jul 30, 2015 at 1:20 PM, Warren Young wyml@etr-usa.com wrote:

...

On Jul 29, 2015, at 5:40 PM, Chris Murphy lists@colorremedies.com wrote:

...

On Wed, Jul 29, 2015 at 4:37 PM, Warren Young wyml@etr-usa.com

wrote:

...

...

Security is *always* opposed to convenience.

False. OS X by default runs only signed binaries, and if they come from the App Store they run in a sandbox. User gains significant security with this, and are completely unaware of it. There is no inconvenience.

You must not use OS X regularly, else you’d know there is plenty of inconvenience in this policy. There’s a whole lot of good software that is both unsigned and not in the App Store. Examples:

a. Most open source software. Many of these projects (e.g. KiCad) can barely manage to serve community-provided unsigned binaries on OS X as it is. Signing apps and managing the App Store submission process is out of the question. The next version of OS X will block all the third-party app epositories (e.g. Homebrew) by default, in order to provide better security:

http://www.imore.com/os-x-el-capitan-faq

b. Most network monitoring software, because putting en0 into promiscuous mode violates the Gatekeeper rules. (Wireshark, etc.)

Some App Store

...

networking software (e.g. RubberNet) manages to get around this by offering a second app download from the author’s web page. You don’t

call that

...

inconvenient?

c. Low-level utilities, such as Karabiner and Scroll Reverser, since they also need to bypass the sandbox guidelines to do their job.

On top of all that, to bypass Gatekeeper, you need to right-click an app and disable Gatekeeper for it on the first launch. Another inconvenience.

I’m not saying Gatekeeper and such are bad, only that they are in fact exemplars of the rule: better security always causes greater inconvenience.

...

What is the inconvenience of encrypting your device compared to the security?

I can’t hook my iPad up to my PC and browse it as just another filesystem, as I can with any other digital camera or MP3 player. Apple must do this in order to prevent sideloading malicious apps.

Did you see my exchange with James Byrne? His bogus counter to my claim that iPads

+Snip+

Can someone mod this thread, I'm sure everyone has an opinion about this I know I do and obviously so do other but I think the fedora mail list would be more suited to this discussion.

I think enough points and counter points have been said, lets move onto more relevant Centos Topics.

Seconded. All this appears, in the few I've glanced at for a while, seem to be Apple fan stuff.

mark

On 07/30/2015 12:35 PM, Chris Murphy wrote:

No fail2ban, no firewall rules, sshd by default, challengeresponseauth by default,

ChallengeResponseAuth is not on by default, on Red Hat derived systems. I'm pretty sure that was already clarified, much earlier in this thread.

and a 9 character (even random) passphrase, and that shit is going to get busted into. Against a targeted attack by a botnet, you need something stronger than a 9 character password, today. Let alone 6 years from now.

6 years from now, the maximum speed of guessing passwords against an ssh server will be exactly the same as it is today. The server imposes delays on failure and maximum connection numbers. With those mechanisms, the rate is constant.

Diceware puts the minimum for large botnet protection at 5 word passphrases. 6 word passphrases for protection against a government entity. Your idea of strong thus far is 9 characters which seems to be b.s. today and certainly laughable in 6 years when we do the autopsy on today's policy successes and failures.

I've read your references to diceware here and earlier in this thread, and I'm pretty sure you don't understand it. Their page makes the purpose clear: "Short passwords are OK for logging onto computer system that are programmed to detect multiple incorrect guesses and protect the stored passwords properly, but they are not safe for use with encryption systems."

Diceware is intended to help you generate passphrases that you will use to protect an encryption key, such that an offline attack against that passphrase is unfeasible.

You appear to be advocating for significantly longer passwords for authentication, but as diceware makes clear, online attacks are already mitigated by rate limits enforced by the server. Offline attacks, such as diceware is intended to thwart, are only possible if the attacker has your password file. In which case they already have root. In which case they don't really need to crack your passwords.

So, unless I misread you, can we let this thread die out?

On Jul 30, 2015, at 12:20, Warren Young wyml@etr-usa.com wrote:

Meanwhile over here in CentOS land, you still see SSH password guessers banging on every public IP that responds to port 22. Why? Because it still occasionally works. Increase the password strength minima, and this class of worm, too, will quickly die out.

If the Windows fix was firewall on by default, why isn’t that the appropriate “fix" for Linux distros? Why mess with the password strength or which daemons are running?

Seems like it adds the necessary step of “STOP: If you turn off this, you’d better know what you’re doing”, without messing around with default settings of packages and/or password library configuration files.

— Nate

Firewalled to the outside world most likely.

-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of John R Pierce Sent: Thursday, July 30, 2015 4:41 PM To: centos@centos.org Subject: Re: [CentOS] Fedora change that will probably affect RHEL

On 7/30/2015 2:23 PM, Nathan Duehr wrote:

...

...

On Jul 30, 2015, at 12:20, Warren Youngwyml@etr-usa.com wrote:

Meanwhile over here in CentOS land, you still see SSH password guessers banging on every public IP that responds to port 22. Why? Because it still occasionally works. Increase the password strength minima, and this class of worm, too, will quickly die out.

If the Windows fix was firewall on by default, why isn’t that the appropriate “fix" for Linux distros? Why mess with the password strength or which daemons are running?

Seems like it adds the necessary step of “STOP: If you turn off this, you’d better know what you’re doing”, without messing around with default settings of packages and/or password library configuration files.

if sshd is firewalled by default, why even run it?

For a couple of distros AFAICT, that IS the default -- with some sort of firewall, whether it be iptables or firewalld, installed and activated right out of the box.

As far as password bangers, well, I always find denyhosts to be an INVALUABLE tool and always make it a part of ANY Linux build that I set up.

-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Nathan Duehr Sent: Thursday, July 30, 2015 4:24 PM To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] Fedora change that will probably affect RHEL

On Jul 30, 2015, at 12:20, Warren Young wyml@etr-usa.com wrote:

Meanwhile over here in CentOS land, you still see SSH password guessers banging on every public IP that responds to port 22. Why? Because it still occasionally works. Increase the password strength minima, and this class of worm, too, will quickly die out.

If the Windows fix was firewall on by default, why isn’t that the appropriate “fix" for Linux distros? Why mess with the password strength or which daemons are running?

Seems like it adds the necessary step of “STOP: If you turn off this, you’d better know what you’re doing”, without messing around with default settings of packages and/or password library configuration files.

On Thu, Jul 30, 2015 at 9:54 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:

...

Now I use Google. They offer MFA opt in. And now I'm more secure than I was with the myopic ISP.

"More secure" only to the level one can trust google ;-)

Yes I know, but I put them in approximately the same ballpark as having to trust my proprietary CPU, and proprietary logic board's proprietary firmware.

On Thu, 2015-07-30 at 12:46 -0500, Valeri Galtsev wrote:

Google has always been in making profit on information [about us] they can collect. But in general you are right. Likelihood wise, I'll stick to my opinion ;-)

Hey, don't be greedy. Its our opinion too ;-)

On Jul 28, 2015, at 6:32 PM, Warren Young wyml@etr-usa.com wrote:

On Jul 28, 2015, at 4:37 PM, Nathan Duehr denverpilot@me.com wrote:

...

...

On Jul 28, 2015, at 11:27, Warren Young wyml@etr-usa.com wrote:

So no, your local password quality policy is not purely your own concern.

Other than DDoS which is a problem of engineering design of how the network operates (untrusted anything can talk to untrusted anything)

I’m not sure how you mean that comment.

If you’re saying that the Internet is badly designed and that we need to rip it up and replace it before we can address DDoSes, you’re trying to boil the ocean. We have real-world practical solutions available to us that do not require a complete redesign of the Internet. One of those is to tighten down CentOS boxes so they don’t get coopted into botnets.

If instead you’re saying that DDoSes are solvable with “just” a bit of engineering, then that’s wrong, too. It takes a really big, expensive slice of a CDN or similar to choke down a large DDoS attack. I do not accept that as a necessary cost of doing business. That’s like a 1665 Londoner insisting that city planning can only be done with close-packed wooden buildings.

I don’t believe that the Internet must go through the equivalent of the Great Fire of 1666 before we can put our critical tech onto a more survivable foundation.

You accepted that risk the day you put a public machine on it. He who has the most bandwidth, wins, in a DDoS. It’s the very nature of the network design. Anyone who can fill your pipe with garbage can take you offline until they stop. You can ask for help from the carriers and see how far you get, but the inherent risk was there from day one and you choose to play.

...

what “risk” is created to other people’s machines who have done appropriate security measures by a cracked machine owned by an idiot

Resource waste is enough by itself. How many billions of dollars goes into extra bandwidth, CDN fees, security personnel, security appliances, etc., all to solve a problem that is not necessary to the design of the Internet in the first place?

Back before the commercialization of the Internet, if your box was found to be attempting to DoS another system, you’d be cut off the Internet. No appeal, no mercy. It’s all /dev/null for you.

Now we have entrenched commercial interests that get paid more when you get DDoS’d. I’ll give you one guess what happens in such a world.

What happens? Folks have to think harder about connecting stuff to a worldwide untrusted, and generally unfiltered network? One word: “Duh."

...

easily handled in minutes, if not seconds, by fail2ban?

fail2ban isn’t in the stock package repo for CentOS 7, much less installed and configured default. Until it is, it’s off-topic for this thread.

Mind, I’m all for fail2ban. If Fedora/Red Hat want to start turning it on by default, too, that’s great.

Didn’t realize that. Brilliant move, removing it… (rolls eyes at RH)…

...

Equating this to “vaccination” is a huge stretch.

Why? If you are unvaccinated and catch some preventable communicable disease, you begin spreading it around, infecting others. This is exactly analogous to a box getting pwned, joining a botnet, and attempting to pwn other boxes.

When almost everyone is vaccinated, you get an effect called herd immunity, which means that even those few who cannot be vaccinated for some valid medical reason are highly unlikely to ever contract the disease because it cannot spread properly through the population.

It’s not a disease. It’s someone using their machine for them because they’re too dumb to use a decent password. Nothing at all happens to the people who used decent passwords other than that aforementioned DDoS problem, which is completely unrelated. You’re making it sound like the OS should be responsible for dumb people… problem with that is, the dumber you let them be, the dumber they stay. And without any harm to the “neighbor” who “pre-vaccinated” I guess, in your world, but simply typing in a decent password, what’s the point? Let them lose data, and they’ll learn.

...

It’s more like saying the guy who left his front door unlocked all day is a threat to the neighbor’s house.

That’s only true in a world where you have armed gangs running through the streets looking for free fortifications from which to attack neighboring houses. That is the analogous situation to the current botnet problem.

If that were our physical security situation today, then I would be advocating fortifying our physical dwellings, too.

Thankfully, that is not the case where I live.

The difference appears to be one of global society, rather than technology, but obviously we aren’t going to solve any of that here.

Global society hasn’t changed, and neither has the network in decades. Why should the OS change to make people dumber?

...

You can’t “catch the insecure”… hahaha… it’s not a virus.

Take an unvaccinated child on a long vacation to some 3rd world cesspit, then report back on how that worked out.

No one reading this list is likely to be “unvaccinated”, but they’ll surely be annoyed if they need to install an “unvaccinated” machine on a properly secured network. Leave security to the end-user. The Internet has always been a meritocracy and using a decent password isn’t exactly a high bar to jump. It’s really none of the OS’s business.

Nate

On Jul 29, 2015, at 6:19 PM, Nathan Duehr denverpilot@me.com wrote:

...

On Jul 28, 2015, at 6:32 PM, Warren Young wyml@etr-usa.com wrote:

Now we have entrenched commercial interests that get paid more when you get DDoS’d. I’ll give you one guess what happens in such a world.

What happens? Folks have to think harder about connecting stuff to a worldwide untrusted, and generally unfiltered network? One word: “Duh.”

No, what happens is that you call up your ISP to ask them for help blocking off the DDoS attack, and you either get blown off or transferred to their sales department to buy a “solution” to a problem they allow to exist because it brings in extra revenue.

Your ISP could block this kind of thing at its border. Your ISP could also use their alliances with fellow ISPs to block DDoSes at their source. They do neither.

...

fail2ban isn’t in the stock package repo for CentOS 7

Didn’t realize that. Brilliant move, removing it… (rolls eyes at RH)…

It wasn’t removed. fail2ban has *never* been in the stock CentOS package repos. It’s always been a third-party thing.

Fedora has it, but that’s not the same thing as saying “Red Hat removed it from RHEL.”

...

When almost everyone is vaccinated, you get an effect called herd immunity,

It’s not a disease. It’s someone using their machine for them because they’re too dumb to use a decent password.

What do you think biological parasites are, then, if not fauna using your body to sustain themselves because your body can’t destroy them fast enough?

Computer worms, viruses, and trojans are computer diseases.

You’re making it sound like the OS should be responsible for dumb people…

Well, I do generally take a libertarian stance on things, but there is a limit on fobbing everything off on personal responsibility. Society should be able to impose a certain level of sensible limits on some things.

CentOS is our society in this context. It is the group we choose to be a member of, which sets the ground rules and provides the resources we use. It is perfectly legitimate for us to decide it should support us better by default.

the dumber you let them be, the dumber they stay.

How’s that working out in your personal life? Is Uncle Bob a virus-fighting crusader these days, 20 years after the commercial Internet got started? Surely all of your relatives are fully trained up by now?

Let them lose data, and they’ll learn.

And yet, people continue to not do backups, and fail to test the backups they do make.

So, Apple came out with Time Machine, and Microsoft cloned it in Windows 8, calling it File History.

Are these bad features, because people should have known better already?

Global society hasn’t changed

Go read "The Better Angels of Our Nature”, by Stephen Pinker:

https://en.wikipedia.org/wiki/The_Better_Angels_of_Our_Nature

There’s plenty to argue with in his conclusions and data, but the book does at least neatly wrap up a huge serving of “the world is a whole lot different today than it once was.”

and neither has the network in decades.

Three decades ago, network security was nonexistent. There were X Window programs that would run an animation from my computer across my screen, then across your screen, and then across all the other screens in the computer lab. All with zero need to lower any security barriers. Then we had rlogin, rcp, and completely-insecure NFS.

Two decades ago, best security practice was deny-by-configuration. Turn off services you aren’t using, use tcpwrappers to block known bad actors, etc.

Then we moved to allow-by-default firewalls, and then to deny-by-default firewalls.

Now we’re moving toward encrypt-everything and 2FA apps in everyone’s pocket.

No change?!

Why should the OS change to make people dumber?

Current thinking is that human intelligence hasn’t increased — or decreased! — at all in many thousands of years.

What *has* changed is that the scope of individual expertise has continually shrunk.

I no longer have to know how to knap my own stone axes because I can buy a camp hatchet from Amazon to split the wood I buy at the convenience store on the way to the campground, which has paved roads, an enclosed privy, concrete pads for the picnic tables, and enclosed fire pits with cooking grates.

And we call all of that “primitive living” today!

This would be pure luxury to a Stone Age person, but Computer Age me probably couldn’t reproduce any of it on my own. I spend my life acquiring expertise in other things.

I should no longer have to do my own arithmetic to figure out what kind of password I should be using for my computers. The computer is perfectly capable of doing that arithmetic for me.

...

...

You can’t “catch the insecure”… hahaha… it’s not a virus.

Take an unvaccinated child on a long vacation to some 3rd world cesspit, then report back on how that worked out.

No one reading this list is likely to be “unvaccinated”

You completely missed the Disneyland measles outbreak story, didn’t you?

The Internet has always been a meritocracy

The Internet hasn’t been a meritocracy since 1993:

https://en.wikipedia.org/wiki/Eternal_September