You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Default root passwords are a horribly bad security practice that leads to things like the Mirai botnet and a long history of similar malware that take advantage of default passwords (or no password on the root account at all!) on millions of internet-connected devices to perform devastating Distributed Denial of Services (DDoS) attacks. A survey by Jerry Gamblin found that Nearly 20% of the 1000 Most Popular Docker Containers Have No Root Password, which is just compounded by an OS that has a default root password. Unfortunately, there are too many examples of this poor practice in use -- all for the sake of having something so simple anyone can do it -- and not enough examples of how to do things more securely.
There is a better way that I would like to propose for you to consider. Arguably, this is easier than the kind of ssid: "YourSSID", password: "YourSecretPreSharedKey type of manual-editing-required examples in the sample directory (which, if you accidentally commit and push the edited values is yet another Bad Practice(TM) that leads to secrets leakage.)
I have a tool I wrote to make it really easy to pre-configure something like HypriotOS (or any other RaspberryPi OS distribution - hint, hint, Raspbian!). It is called python_secrets. We recently spoke about the problem and this program at Toorcon XX. In that talk, I demonstrated how to use psec -- using HypriotOS and flash for the use case, no less! -- with this asciicast. The steps in the goSecure prototype repository are documented here.
Before I start spending a lot of time trying to update the blog and flash repos in order to make a pull request, I'd like to get your input on whether you would like to work with me on integrating psec into the flash process to get a more secure result without much extra effort for users?
The text was updated successfully, but these errors were encountered:
I finally had time to watch your Toorcon talk, thanks Katherine and you for your work you do to raise the awareness of this problem. Keep up the good work!
I remember when we introduced cloud-init I suggested to remove the default user at all, but as a team we decided against it to give users more convenience.
Yes, we failed at "secure by default", but at least we have no users at all in the Linux partition. Only the boot partition has the user-data file that can be replace before the first boot.
If no user would be installed, more people could struggle (maybe Windows users that cannot use flash and use tools like Etcher) and would open GitHub issues that the card does not work, they cannot login etc.
To reduce our effort in our spare time it was a consideration to leave that one default user in the user-data file.
But users that know how to handle it can replace it before putting the SD card into the RPi for the first time. That were our ideas and the reason why we have the current constellation.
I'm not fully convinced if we should couple psec with flash, I fear this increases the installation requirements (have the right version Python, ...).
It is an excellent idea to avoid default passwords, but I find it difficult
The challenge is the templating, replacing variables in the user-data file.
For me I solved it by putting the whole user-data file into pass password manager which is a command line tool. I once ran pass insert flash-wifi-yml and from time to time pass edit flash-wifi-yml. The user-data contains my own user, my SSH pub keys, my WiFi settings.
Then I have a small wrapper around flash tool, called flash-wifi.sh:
It takes the secret user-data file for the flash tool and removes it again from /tmp. Maybe not the best solution, but for my projects it's a good enough approach. I skipped the templating / variable expansion problem by completely replacing the user-data file with all my secrets.
With that flash-wifi.sh script I can use other parameters like --hostname/ -n to set the hostname on the fly. So that's convenient for me, but I haven't added pass into flash as well as it's my opinionated way to do it.
I would like to hear your suggestions how we could integrate psec (or other tools) to flash and/or our SD card images.
Default root passwords are a horribly bad security practice that leads to things like the Mirai botnet and a long history of similar malware that take advantage of default passwords (or no password on the
root
account at all!) on millions of internet-connected devices to perform devastating Distributed Denial of Services (DDoS) attacks. A survey by Jerry Gamblin found that Nearly 20% of the 1000 Most Popular Docker Containers Have No Root Password, which is just compounded by an OS that has a defaultroot
password. Unfortunately, there are too many examples of this poor practice in use -- all for the sake of having something so simple anyone can do it -- and not enough examples of how to do things more securely.There is a better way that I would like to propose for you to consider. Arguably, this is easier than the kind of
ssid: "YourSSID"
,password: "YourSecretPreSharedKey
type of manual-editing-required examples in the sample directory (which, if you accidentally commit and push the edited values is yet another Bad Practice(TM) that leads to secrets leakage.)I have a tool I wrote to make it really easy to pre-configure something like HypriotOS (or any other RaspberryPi OS distribution - hint, hint, Raspbian!). It is called python_secrets. We recently spoke about the problem and this program at Toorcon XX. In that talk, I demonstrated how to use
psec
-- using HypriotOS andflash
for the use case, no less! -- with this asciicast. The steps in the goSecure prototype repository are documented here.Before I start spending a lot of time trying to update the blog and flash repos in order to make a pull request, I'd like to get your input on whether you would like to work with me on integrating
psec
into theflash
process to get a more secure result without much extra effort for users?The text was updated successfully, but these errors were encountered: