Don't reject "weak" passwords during setup

  • From here: https://github.com/LibreELEC/LibreELEC.tv/issues/8727

    Describe the bug

    During setup of a new libreelec installation, I enabled remote ssh access. I was informed of the default password, and the setup recommended that I change it from the default. Fine, that's a great idea! Unfortunately the password that I wanted to use was too "weak", and was rejected. The other two passwords that I tried were also considered too weak, and were rejected. So I left the password as the default ("libreelec").


    Context

    What's weaker than a weak password? A default password. In trying to encourage a more secure libreelec installation, this actually makes security worse, as it incentivizes users to just use the default password.

    In setting a root password for libreelec, I don't have the convenience of a browser password manager, so I'm not going to use an autogenerated password. My plan was to set a commonly used home appliance password (since I'm behind a NAT, it's not a big deal), and then later on disable ssh password logins and install an ssh key.


    I think this person describes the issue fairly succinctly. You can keep the current behaviour but it would be nice if there was a workaround for those who require it.

  • Over time we received more abuse from people demanding we require stronger passwords than people demaning the ability to set weaker passwords. So the current status quo is intentional and we have no plan to change that. Just skip ahead to the point where you've installed an SSH key and disabled passwords and the entire issue is moot.

  • Understood, well I found a workaround.

    Log into the LibreELEC machine and type:

    cryptpw

    Then enter the password. It will output a crypt script.

    Then edit the Shadow password file and substitute what was generated.

    Code
    LibreELEC:/etc # vi /etc/shadow
    systemd-timesync:*:::::::
    systemd-network:*:::::::
    dbus:*:::::::
    root:[the password generated]::::::
    nobody:*:::::::
    system:*:::::::
    avahi:*:::::::
    LibreELEC:~ #


    Save it and then before you logout, try logging in again with SSH and the new password and it should work.

    Sorry you received any abuse, appreciate the work you do.

  • Over time we received more abuse from people demanding we require stronger passwords than people demaning the ability to set weaker passwords. So the current status quo is intentional and we have no plan to change that. Just skip ahead to the point where you've installed an SSH key and disabled passwords and the entire issue is moot.

    I understand your stance. The problem is when you reject a weak password, the user may keep the default which is not only weak but known to all.

  • "You can please some of the people all of the time, and you can please all of the people some of the time, but you can't please all of the people all of the time” .. /shrug

  • "You can please some of the people all of the time, and you can please all of the people some of the time, but you can't please all of the people all of the time” .. /shrug

    I don't understand why allowing weak password fit that. User who want strong password would still have the choice. The decision makes no sense to me, just to placate a few users who complain. More weak password users just need to make their opinion felt.

  • Yeah, people like me often use one password on different machines, just because it's easier to remember. If this is blacklisted by being "weak", then it's a frustrating UX. Users don't like censorship, no matter what they do (and how dumb it is :S).

    Maybe the best compromise is just to show a warning, and allowing the weak password afterwards.

  • Maybe the best compromise is just to show a warning, and allowing the weak password afterwards.

    That could be a good option, as the warning already present for the default password (if I remember correctly). At the other hand... how complicated is to set a "strong" password? Just to have enough characters, including numbers, symbols. And if somebody use the same password on different machines... that's his own and private decision.

    And something else about the default/weak passwords... These machines usually are connected to internet. In the case of the weak password, what's the chance to get it transformed in to a "zombi" machines? To be used it by others for something "bad"?

  • These machines usually are connected to internet

    That's not correct. Most machines are in a home LAN behind a NAT router so unless the user explicitly port-fortwards or configures a VPN which results in the device having a secondary (external) IP address they are not exposed. Only a tiny percentage of our active userbase have devices exposed. I periodically check shodan scan results and the number of exposed systems is small, stable, and has been slowly declining over time.

  • what's the chance to get it transformed in to a "zombi" machines? To be used it by others for something "bad"?

    I've also dropped a couple of LE devices with default passwords into deception/honeypot type environments where red-team staff and/or real attackers are active. Both gained access to the system(s) using password dictionary lists; the attackers were faster than the red-team staff who took some time to figure out what the device was (and thus guessed the password correctly first time) but the attackers using a dictionary list were noisier and easily detected. The red-team folks poked around, but perhaps knowing what the distro was didn't bother to do much. The real attackers dropped exploit tools into /tmp and then failed to do anything because the tools assume Debian or RHEL and fail because a) we're neither of those, b) most of the filesystem is read-only. The attackers spent a little time trying to tweak their scripts based on some wrong assumptions but quickly gave up and moved onto more-promising targets in the environment.

    Now, obscurity is not security, but unless someone explicitly writes exploit tools that work on LE, the default (and automated) tools that most attackers use don't work, and LE is niche enough that I doubt someone will make the effort to write ones that do: as the total number of exploitable devices (visible to any attacker with a shodan account) means the 'ROI' of the effort is poor. The possible exception is a nation-state actor who might take the time to develop unique tooling for a campaign. However if you're a person-of-interest for those folks, you're fcuked anyway, and the insecure LE box in your network is the least of your problems. So the real-world risk for the small number of users dumb enough to expose their box to the public internet; is someone deleting some/all of their Kodi config and/or whatever media files exist on /storage.

  • Most machines are in a home LAN behind a NAT router so unless the user explicitly port-fortwards or configures a VPN which results in the device having a secondary (external) IP address they are not exposed. Only a tiny percentage of our active userbase have devices exposed.

    That's true, and in case of the LE the risk is obviously small. But those people often like to use a "simple" password where the risk isn't low. It's really need so much "effort" to use a propper password? But I think already was consumed too many time and space for this "why isn't accepted a weak password" thing.