7

I'm currently spitballing ideas for an Internet of Things device. It will be running Linux on a widely available development board, I'm not too concerned about physical security or the end user doing something bad to it however I'd like to secure it from botnets such as the mirai botnet.

For things such as the root user account, how should I secure it: should I use key based authentication or just a regular password? I want to be able to give end users access to the root user account upon request or provide it out of the box.

I don't want to have any extra user accounts or store any authentication details on my servers in case of a breach.

Adam
  • 73
  • 6

2 Answers2

3

Great question! Several things you should keep in mind.

1. Default passwords

This is really basic, and you've probably already thought of it, but let me reiterate: default or easy passwords are deadly. When I asked this question, I learned that the way the Mirai worm works is simply to attack via default usernames and passwords. Whatever you do, do not set up a default password on your IoT device.

2. Security risks with passwordless ssh (or other key based setups)

Basically, the only risk from setting up key based is if someone gets hold of your private key. Otherwise, passwordless ssh is actually more secure than typing in a password. From my perspective, there are several reasons for that:

  1. Passwords are easy to brute-force (botnets, like you suggested)
  2. Generally, key strokes aren't sent with extremely secure encryption, if any.
  3. Passwordless ssh is usually encrypted with either DSA or RSA, however you set it up. (Check this post on security.SE for details)

3. Security risks with password entry.

As I have mentioned above, passwords are relatively easy to brute force, as well as the unlikely though possible risk of password interception on route.

Do note, that if you do use passwordless ssh, you should definitely secure it with a passphrase.

Community
  • 1
anonymous2
  • 4,902
  • 3
  • 22
  • 49
3

Assuming you need to handle firmware updates (otherwise, you're insecure by default) then you will also need to sign the updates (and manage updates in a secure way). Otherwise, an attacker can simply present your device with a compromised update package. Clearly, if you do this, you make it impossible for the user to apply firmware updates in the same way, but you don't necessarily need to lock them out entirely (since they have physical access).

In addition, you'll need to provide a secure way of provisioning each device with a unique ssh key visible to the end user (but they could be contained on the device if you're accepting physical access means ownership).

Sean Houlihane
  • 10,524
  • 2
  • 26
  • 62