FAQ
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?id46771


--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

Search Discussions

  • Chris Murphy at Jul 25, 2015 at 5:16 pm

    On Sat, Jul 25, 2015 at 9:40 AM, Scott Robbins 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?id46771

    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




    --
    Chris Murphy
  • Scott Robbins at Jul 25, 2015 at 5:24 pm

    On Sat, Jul 25, 2015 at 11:16:18AM -0600, Chris Murphy wrote:
    On Sat, Jul 25, 2015 at 9:40 AM, Scott Robbins 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?id46771
    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.


    --
    Scott Robbins
    PGP keyID EB3467D6
    ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
    gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
  • Jake Shipton at Jul 25, 2015 at 6:45 pm

    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 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?id46771
    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
  • Gordon Messmer at Jul 25, 2015 at 10:00 pm

    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.
  • Johnny Hughes at Jul 26, 2015 at 1:13 pm

    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




    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 198 bytes
    Desc: OpenPGP digital signature
    URL: <http://lists.centos.org/pipermail/centos/attachments/20150726/0cff9d2d/attachment.sig>
  • Johnny Hughes at Jul 26, 2015 at 1:15 pm

    On 07/26/2015 08:13 AM, Johnny Hughes wrote:
    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.

    Gordon, just to make sure you (and others on the list) understand .. I
    have no issue with your specific post .. I probably should have replied
    to the OP's mail instead, but yours was the last I read on this thread.




    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 198 bytes
    Desc: OpenPGP digital signature
    URL: <http://lists.centos.org/pipermail/centos/attachments/20150726/b1f04601/attachment.sig>
  • Bob Marcan at Jul 26, 2015 at 12:22 am

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

    On Sat, Jul 25, 2015 at 9:40 AM, Scott Robbins 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?id46771
    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.
  • Warren Young at Jul 28, 2015 at 5:27 pm

    On Jul 25, 2015, at 6:22 PM, Bob Marcan wrote:
    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.?

    The new rules are nowhere near that stringent:


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

    Who thinks the password policy in my machines are my concern.

    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.


    In the previous thread on this topic, 6 months ago, I likened reasonable password strength minima to state-mandated vaccination. Previously-defeated diseases have started to reappear as the antivax movement has gained momentum. Polio came back in Pakistan, measles in California, and whooping cough in Australia, all within the last year or two.


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


    So no, your local password quality policy is not purely your own concern.
  • Chris Adams at Jul 28, 2015 at 7:06 pm

    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.


    --
    Chris Adams <linux@cmadams.net>
  • Johnny Hughes at Jul 28, 2015 at 7:20 pm

    On 07/28/2015 02: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.
    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.

    Well, you are welcome to your opinion and Warren is welcome to his.


    But in relationship to CentOS Linux, this discussion is completely
    irrelevant.


    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.


    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 198 bytes
    Desc: OpenPGP digital signature
    URL: <http://lists.centos.org/pipermail/centos/attachments/20150728/ec4d54b8/attachment.sig>
  • Matthew Miller at Jul 28, 2015 at 7:29 pm

    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.




    --
    Matthew Miller
    <mattdm@fedoraproject.org>
    Fedora Project Leader
  • Chris Murphy at Jul 28, 2015 at 8:46 pm

    On Tue, Jul 28, 2015 at 1: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.

    Botnets are terrible, it doesn't matter how many of them there are or
    on what platform. The reason why they exist is bad practices. So there
    needs to be better application of best practices, and best practices
    need to be easier and default and automatic whenever possible. That
    applies to all platforms. So I'm not opposed to changes in Fedora, and
    by extension eventually to CentOS and RHEL, but they have to be
    balanced out.


    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.



    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.

    Exactly. 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.


    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. But the iPad has no remote services
    enabled. And the Mac has SSH PKA required. So I'm not that concerned
    about their crappy login passwords. Their online services are another
    matter, those I've made very clear they will be strong or they don't
    get to play.




    --
    Chris Murphy
  • Gordon Messmer at Jul 28, 2015 at 9:04 pm

    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.
  • Chris Murphy at Jul 28, 2015 at 9:08 pm

    On Tue, Jul 28, 2015 at 3:04 PM, Gordon Messmer wrote:
    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.

    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.


    --
    Chris Murphy
  • Gordon Messmer at Jul 28, 2015 at 9:51 pm

    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.
  • Robert Wolfe at Jul 28, 2015 at 9:10 pm
    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at 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.


    Thank you,


    Robert Wolfe, Systems Administrator
    Malco Theatres, Inc.
    5851 Ridgeway Center Parkway
    Memphis, TN 38120
    Phone: 1-901-761-3480 EXT 135
    Fax: 1-901-681-2058
  • Chris Murphy at Jul 28, 2015 at 9:14 pm

    On Tue, Jul 28, 2015 at 3:10 PM, Robert Wolfe wrote:
    -----Original Message-----
    From: centos-bounces at centos.org [mailto:centos-bounces at 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.


    --
    Chris Murphy
  • John R Pierce at Jul 28, 2015 at 9:15 pm

    On 7/28/2015 1:46 PM, Chris Murphy wrote:
    Windows Server has power shell disabled by default. The functional
    equivalent, sshd, is typically enabled on Linux servers.

    to be pedantic about it, the equivalent of PowerShell is NOT sshd, its
    bash/ksh/csh/zsh/sh ... PowerShell does not by itself allow external
    connections, you'd need to configure a telnetd or sshd server to allow
    that (or remote desktop or vnc or ...).






    --
    john r pierce, recycling bits in santa cruz
  • Gordon Messmer at Jul 28, 2015 at 9:46 pm

    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.
  • Warren Young at Jul 28, 2015 at 11:46 pm

    On Jul 28, 2015, at 2:46 PM, Chris Murphy 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.
  • Chris Murphy at Jul 29, 2015 at 1:55 am

    On Tue, Jul 28, 2015 at 5:46 PM, Warren Young wrote:
    On Jul 28, 2015, at 2:46 PM, Chris Murphy 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
  • Warren Young at Jul 28, 2015 at 10:34 pm

    On Jul 28, 2015, at 1: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

    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.
  • Chris Murphy at Jul 28, 2015 at 11:17 pm

    On Tue, Jul 28, 2015 at 4:34 PM, Warren Young wrote:


    That?s only true if the majority of people will in fact override the default policy.

    The current behavior in Fedora and CentOS lets you click Done twice
    and bypass the weak password complaint.

    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), the minimum password quality
    would need to be at least initially onerous. Whereas if things are
    properly configured such that ssh is only used internally, all you
    have to worry about are internal attacks which are hopefully rather
    rare.




    --
    Chris Murphy
  • Warren Young at Jul 29, 2015 at 1:15 am

    On Jul 28, 2015, at 5:17 PM, Chris Murphy wrote:
    On Tue, Jul 28, 2015 at 4:34 PM, Warren Young 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.
  • Timothy Murphy at Jul 29, 2015 at 12:17 am

    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).


    Is anything known about the ratio of RHEL to CentOS machines?


    --
    Timothy Murphy
    gayleard /at/ eircom.net
    School of Mathematics, Trinity College, Dublin
  • Matthew Miller at Jul 29, 2015 at 12:25 am

    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.






    --
    Matthew Miller
    <mattdm@fedoraproject.org>
    Fedora Project Leader
  • Chris Murphy at Jul 29, 2015 at 2:01 am

    On Tue, Jul 28, 2015 at 6:17 PM, Timothy Murphy 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 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.




    --
    Chris Murphy
  • Johnny Hughes at Jul 29, 2015 at 2:31 am

    On 07/28/2015 09:01 PM, Chris Murphy wrote:
    On Tue, Jul 28, 2015 at 6:17 PM, Timothy Murphy 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.




    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 198 bytes
    Desc: OpenPGP digital signature
    URL: <http://lists.centos.org/pipermail/centos/attachments/20150728/d7a9eec5/attachment.sig>
  • Chris Murphy at Jul 28, 2015 at 8:27 pm

    On Tue, Jul 28, 2015 at 11:27 AM, Warren Young 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.






    --
    Chris Murphy
  • Warren Young at Jul 28, 2015 at 11:29 pm

    On Jul 28, 2015, at 2:27 PM, Chris Murphy wrote:
    On Tue, Jul 28, 2015 at 11:27 AM, Warren Young 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.


    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.

    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.


    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?

    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.


    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.

    I think we'll see either sshd disabled by default

    That wouldn?t break my heart, either.

    or PKA required by default

    The main problem with that is that you need some way to install the client computer?s public key into the authorized_keys file during initial setup. You don?t need password auth to be enabled to do that, but it would make things considerably more difficult.


    Meanwhile, *this* thread is about using 9+ character passwords that aren?t laughably easy to break, which is not difficult.

    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
  • Chris Murphy at Jul 29, 2015 at 1:05 am

    On Tue, Jul 28, 2015 at 5:29 PM, Warren Young wrote:
    On Jul 28, 2015, at 2:27 PM, Chris Murphy wrote:
    On Tue, Jul 28, 2015 at 11:27 AM, Warren Young 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.






    --
    Chris Murphy
  • Warren Young at Jul 29, 2015 at 1:48 am

    On Jul 28, 2015, at 7:05 PM, Chris Murphy wrote:
    no OS does this right now

    Chrome OS does, because your OS password is your Google password. Therefore, Chrome OS?s password quality minima are Google?s minima, which are similar to libpwquality?s defaults:


       http://passrequirements.com/passwordrequirements/google


    OS X and iOS offer the option of using your Apple ID as your OS login password, which has similar requirements to Google's:


       https://support.apple.com/en-us/HT201303


    Windows has also been doing this since Windows 8. Microsoft's rules are stronger than either Google?s or Apple?s:


       http://www.liveside.net/2012/07/23/microsoft-account-to-enforce-stricter-password-controls/


    Android, Apple, and Microsoft currently allow you to use non-Internet based authentication, but defaults matter.


    You?ll notice that this list is mobile-heavy. These rules exist because these passwords are subject to public pounding over the Internet?just like a great many CentOS boxes.

    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.

    We?ve had that at least since EL6 came out, about 5 years ago. (Probably before that in the Fedora line.)


    Apparently those in a position to decide these things see that this has not caused a sufficient shift in the quality of passwords used on Red Hattish boxes, evidenced by lack of a sharp drop in botnet members.

    I would never accept such a
    product that required such login rules.

    Yes, well, we?ll see what you?re using in another 2-ish years when CentOS 8 ships. Money, mouth, and all that.
  • Gordon Messmer at Jul 29, 2015 at 2:37 am

    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?
  • Nathan Duehr at Jul 28, 2015 at 10:37 pm

    On Jul 28, 2015, at 11:27, Warren Young wrote:
    On Jul 25, 2015, at 6:22 PM, Bob Marcan wrote:

    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.?
    The new rules are nowhere near that stringent:

    http://manpages.ubuntu.com/manpages/trusty/man8/pam_pwquality.8.html
    Who thinks the password policy in my machines are my concern.
    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.

    In the previous thread on this topic, 6 months ago, I likened reasonable password strength minima to state-mandated vaccination. Previously-defeated diseases have started to reappear as the antivax movement has gained momentum. Polio came back in Pakistan, measles in California, and whooping cough in Australia, all within the last year or two.

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

    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), what ?risk? is created to other people?s machines who have done appropriate security measures by a cracked machine owned by an idiot, that isn?t easily handled in minutes, if not seconds, by fail2ban?


    Equating this to ?vaccination? is a huge stretch. It?s more like saying the guy who left his front door unlocked all day is a threat to the neighbor?s house. Other than the perennial brokenness of a worldwide untrusted network piped straight into your home or business without an appropriate firewall and/or monitoring of said silly network, there?s almost zero risk at all to the ?house next door with a deadbolt and security bars?.


    You can?t ?catch the insecure?? hahaha? it?s not a virus.


    --
    Nate Duehr
    denverpilot at me.com
  • Warren Young at Jul 29, 2015 at 12:32 am

    On Jul 28, 2015, at 4:37 PM, Nathan Duehr wrote:
    On Jul 28, 2015, at 11:27, Warren Young 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.
  • Chris Murphy at Jul 29, 2015 at 2:50 am

    On Tue, Jul 28, 2015 at 6:32 PM, Warren Young wrote:
    On Jul 28, 2015, at 4:37 PM, Nathan Duehr 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.


    Malware itself is not a good analog to antigens. Vaccinations provide
    immunity to only certain kinds of antigens, and only specific ones at
    that. Challenge-Response, which is what a login password is, is about
    user authentication it is not at all meant or designed to provide
    immunity from malware. 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.


    So this push to depend on stronger passwords just exposes how "immune
    compromised" we are in these dark ages of computer security. There are
    overwhelmingly worse side effects of password dependency than
    immunization. The very fact SSH PKA by default is even on the table in
    some discussions demonstrates the level of crap passwords are at.


    Software patches, SELinux and AppArmor are closer analogs to certain
    aspects of human immunity, but even that is an imperfect comparison.


    And also, a large percent of malware doesn't even depend on brute
    force password attacks. There are all kinds of other ways to
    compromise computers, create botnets, that don't depend on passwords
    at all. So vaccinations have something like 95% efficacy, while
    passwords alone have nothing close to this effectiveness against
    malware.






    --
    Chris Murphy
  • Warren Young at Jul 28, 2015 at 5:12 pm

    On Jul 25, 2015, at 9:40 AM, Scott Robbins wrote:
    This might show up twice, I think I sent it from a bad address previously.
    If so, please accept my apologies.

    I?d rather have your apology for trying to raise a zombie:


       https://www.mail-archive.com/centos%40centos.org/msg108580.html


    We already had this argument. The terms haven?t changed, so why would the results be different?

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedJul 25, '15 at 3:40p
activeJul 29, '15 at 2:50a
posts38
users13
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase