Thank you for all the critical feedback on security in this thread. Maru used to ship with sshd disabled [0] but it was enabled because of all the requests I was getting from users who wanted to run the system headless without needing an HDMI display and BT keyboard/mouse around to set sshd up. I assumed that users would change the default password after the initial login, but as many of you have pointed out, hope is not a strategy when it comes to security. I've opened up an issue [1] to fix this.
Please feel free to open up issues (or, even better, PRs!) at any time if you have further suggestions for improvement. It's thanks to feedback like this that Maru continues to move onwards and upwards.
[0]: https://github.com/maruos/maruos/issues/22#issuecomment-2296... [1]: https://github.com/maruos/maruos/issues/76
It is very easy to accidentally add egregious security vulnerabilities to products if you don't know what you're doing. In fact, accruing small security issues (like this SSH password problem) is the default state of the world.
As a user, I pay the cost when products I use have bad security. If I get hacked via your product, it might be embarrassing for you, but its my device and my data that gets compromised. And because of that, I expect most small companies will not care about their product's security as much as I do as a consumer.
Of course, once a company grows large enough they'll hire a person or a team to look into their software security. At that point they'll fix all the obvious security issues. The database will gain a password. The root AWS account will stop being shared out amongst employees. Work laptops will have full disk encryption turned on to protect against theft, etc.
But until then, as a customer, I should be really nervous. How can you tell the secure products apart from the insecure ones? Well, one of the most obvious signs is that secure products will have already fixed the obvious mistakes. Things like connecting to backend services using unencrypted HTTP. Things like a backdoor-by-default SSH password published on the website.
That is why we (security wonks) make a big deal out of small security problems when they're obvious. They're a sign that nobody has even taken a look at the security situation, and for every obvious problem there's probably 10 more that aren't obvious. This issue might get fixed, but thats why your reply doesn't make me less nervous.
---
And thats a shame, because your project seems super cool and I really want you to succeed! This has come across much more negative than I intended, and I'm more frustrated at the startup industry over this than I am frustrated with you or what you're doing. Hopefully you can get a security review done at some point to make sure there aren't any other simple problems that need to be dealt with. I'm looking forward to seeing where it goes.
"Now it's very simple.If you want to enable SSH, all you need to do is to put a file called ssh in the /boot/ directory.Thats all. And don't forget to change the password"
So how about 'touch sdcard/boot/ssh' to enable ssh ?
and sure, you can blame it on the people using the software, but that doesn't stop a bunch of ssh servers with default credentials being open to the network.
My definition of super polished includes 'renders without javascript enabled'.
sshd won't let you login with an empty password by default.
To be fair, I had a Pi2 and used it to watch videos but it died and my tablet or my TV+USB key are more convenient to use now. I guess some people would use a Chromecast instead.
A basic and egregious security blunder is more than a bit of a red flag.
and makes me wonder if it is the tip of the iceberg.
If you already see that the tip sticking out has a mine on it, the tons of iceberg only give you the difference in the degree of egregiously bad.
The way I see it, this is a "toy" (for the time being). The "2013 devices" makes me thing that this is a "toy" for people like "us" that have a Nexus rotting away somewhere and "it would be cool to fool around on your 30-inch screen and nothing more!
It would be better if they would up-front say "this is not secure", "this is a demo", "this is a toy", "this is not the OS you're looking for".
Imaginary CEO-CTO dialog:
CEO: hey! I just read that we can throw away the PCs and replace them with some old phones that we can buy for $50 on ebay! START!!!
CTO: but.. let me explain.. I quit!!
I'm writing this on a 2013 Nexus, thank you very much! A year ago it stopped booting and I tried searching for a newer, comparable tablet to replace it: no such device exists. I ordered a replacement main board and couldn't be happier. Until someone makes a new 7-inch tablet with a full HD display, it will continue to not rot in my hands for a few more years.
This isn't just "unhardened", this is a lack of basic security, and after Mirai, nobody should be doing this shit.
As a gadget enthusiast, I loved tinkering with it. But it is simply not practical for daily use (yet). I think it could end up being a nice FOSS alternative to Microsoft's Continuum project, especially if the developer can get it working on a newer device.
Bolting on security later seldom works well.
So many other options: not enabling sshd per default, ask for a password, display a random password on the phone, allow uploading a public key... possibilities are endless.
The fact passwords are on by default for sshd on most distributions is crazy.
1. User tries to SSH to rpi over LAN from their laptop.
2. rpi SSH server sends back a request for a torrent of the 1999 smash hit "The Matrix"
3. laptop sends torrent "The Matrix" iso.
4. If the average latency dips below a threshold value, don't connect.
5. If it's done in five minutes, connect.
6. set rpi's SSH server to key-based authentication for strong keypair that was generated on user's laptop.
7. Done.