Storing plaintext passwords for cameras - Security concerns?

It's a long question but I think your main point is this:

We wish to simplify the accessing of the cameras over multiple devices (tablet, phone, PC?).

First have a look how SSH keys work. That would work for you mostly as it is.

At first the customers public key is added into his camera during the initial configuration. He can authenticate himself using his private key that is stored on his device. Every of his devices (PC, Tablet, Mobile, ...) has its own key.

If he likes to access his camera from a new device, he starts a request from this device with the public key from his device. Goes back to his first device and grant the request by adding the public key into the camera. From now both clients can access. You can revoke access by removing a key. Also you can store access levels with the key.

You can store all public keys on your server.

If you server gets hacked, only public keys can be stolen. All the cameras are still secure.

If a customer gets hacked, he revokes his public key on your server, performs a factory reset on his cameras and adds his new key.

You should at least hash the passwords.

Use a secure hash function, e.g. SHA-256 to hash a password and store it like this.

When generating a new password, you can send the user the new password, but hash it and store the hashed version in the camera/database.

When checking if password is correct, hash the password that has been input and compare it to the correct password's hashed value.

This is important, as if anyone were to ever manage to access the passwords, they could go and try to reuse these passwords on online accounts belonging to the owner of the camera/account and with the amount of password reuse going on, likely succeed.

What I would consider a proper design is one in which the services you host and the hardware you sell are not too tied to each other. The customers should be able to use those two products separately if they so choose, and I for one wouldn't buy a piece of hardware that I would no longer be able to use if the company which sold it went out of business (or decided to no longer support the product).

Additionally it will be very difficult for you to verify if a particular person has legitimate access to use a specific camera. So how will you decide whether you are going to tell somebody what the default password is for their particular camera?

Instead I would take the approach that if you have physical access to the camera, then you can also reset the password.

You may want an audit trail. What I would consider the most important part of the audit trail for a security camera is that before you can get close enough to the camera to touch it, a picture of you has already been captured and send to a remote location.

Additionally I would suggest that resetting the password is also going to replace some key on the camera with a new random key such that any servers the camera communicate with can know that the password has been reset.

The greatest danger of default passwords is if people leave the default password on the device and unauthorized users can access it across the internet. To avoid this risk, I suggest these two approaches:

• After resetting to the default password, you cannot do anything else with the device until you have chosen your own password for the device.
• The default password can only be used when communicating with the device using a link-local address.

I recommend using IPv6 for that initial step for a few different reasons:

• It is the most future-proof protocol to be using.
• All devices actually have a link-local address (this is not the case for IPv4).
• The link-local address can be based on the MAC address and that way remain static even if the network is reconfigured. You can print that IPv6 address on the camera.
• Modern OS in the default configuration can use IPv6 link-local addresses without needing a router, DHCP server, or other equipment to be present on the link.

I can think of two different approaches to what you need to do when you have physical access to the camera in order to enable the default password. Either you need to push a button (usually this is installed such that you need to use the tip of a pen to reach it), or you need to use a separate management network interface, which is not connected in normal operation. For additional security against casual access you can locate that button or port such that the camera has to be detached from the wall in order to access it.

Those are the approaches I can come up with to avoid problems related to unauthorized use of the default password. Having a separate default password per device is probably a bad idea for support reasons. Besides customers should not have to rely on you in order to keep using the hardware which they have bought.

I can see a few follow up questions that may be interesting to ask in relation to your question and my answer:

• How could a service be designed to manage access to multiple independent security cameras without needing each camera to see the plaintext password of each user?
• How could a service be designed to collect video streams from security cameras such that recordings of an incident are not lost due to sabotage or theft of equipment?

I don't know if those questions have already been asked on this site, otherwise you might want to ask them as well.