Storing plaintext passwords for cameras - Security concerns?

Question

This question has a follow-up question here: How to securely encrypt data with a public-private key encryption scheme, but also allow decryption if the private key is lost?

TL;DR:
Can I use plaintext passwords for a device which doesn't hold any sensitive data?
No, because password reuse.
Okay, can I use prehashed passwords for a device which doesn't hold any sensitive data?
No, because database administrators can still use the prehashed passwords to gain access.
Then what can I use?

---

As far as I'm aware, plaintext passwords are not secure.

Yet I don't see a way around using them.

I have two questions:

• In the following situation, is the use of plaintext passwords insecure?
• In the following situation, is the use of plaintext passwords unavoidable?

---

We're developing new cameras to be used for monitoring and security of private homes.

I'll skip their uses, but they're intended not just as security cameras against things like break-ins, but also for other domestic uses (like checking if your children are still in bed, and not wandering about in the evening).

The security plan is as such:

• Each camera has a (likely to be unique) default password. The password is generated per camera, but duplicates are possible.
• We store the default passwords in a database for support (both testing and "you lost your default password card, but do have a receipt of purchase, here's your default password").
• Each camera is reachable from anywhere in the world with minimum set-up.
• With the default password, one can access the camera and change the password.
• With a custom password, one can access the camera and view the stream of the camera.
• The default password is rejected if a custom password is set.
• The default password does not allow viewing of the camera stream.
• With physical access to the camera, it's possible to factory reset the camera. This clears the custom password and reinstates the default password.

So far, I personally do not see any security issues. Yes, we store plaintext passwords, but they do not allow access on configured cameras. They only allow access on cameras that are plugged in but not yet configured. It would take a mighty scanner to detect and take over a camera that was just plugged in, but not configured yet. Even if it was taken over, the customer could just factory reset the device and try again.

Now, for the next change...

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

To do this, we store the custom password in our database.

When one wishes to access their camera, they log in to our platform (this password we do not store plaintext). They can retrieve a list of cameras and plaintext passwords. They can then use these passwords to connect to the camera. The handling of the plaintext passwords happens automatically in an app, but with a rooted device, it should be easy to find out what data you're receiving.

• We store custom passwords in the database too.
• Custom passwords are retrieved after authenticating to the platform (via properly managed credentials).
• Custom passwords are stored per user; if two people add the same camera to their account with the same password, it will work. If one of them then changes the password on the camera, the other one will get a "enter password" dialog the next time they try to access the camera.

Storing these passwords plaintext, it suddenly becomes possible, in the event of a database breach, to access all configured cameras from anywhere. Is this a security risk? The worst one can do is format the SD card (and control the camera like any other PTZ camera). One could even start the update process, but all that would do is install updates from the update server(s). Unless you're nearby the camera to intercept traffic and alter the received firmware, the camera will just update to our latest version.

If an attacker has physical access to the device, it doesn't matter what security we have; they could factory reset, set up their own password, then update from SD card. Result is a camera that can do anything it damn well pleases.

I'm willing to allow a successful (unrecoverable takeover; e.g. bricking of the camera) hack attempt only by physical access. This because we cannot make the cameras resistant to weaponry - if someone can destroy a camera with good use of a hammer, protecting against physical attack vectors is a moot point.

---

• In the described situation, is the use of plaintext passwords insecure?
• In the described situation, is the use of plaintext passwords unavoidable?

---

EDIT: A suggestion that has been to made is to make custom passwords hashed. This removes a risk that in the event of a database breach, people would be suffering access breaches via password reuse.

@Victor pointed out that the current security plan allows employees to access the cameras. Removal of the password synchronization feature allows us to remove the password from the database, removing the security risk.

However, we wish to make an online video storage service to allow video playback in event of camera theft. This requires a camera password of sorts. Passing this password and storing it in a database opens the situation back up for employees using the passwords in the database to access customer cameras.

A new plan I'm thinking of involves having the customer using the app to, via a local connection with the camera, generate an access token that allows, from anywhere, but only with a specific account (of which only the company knows the password), access to the video feed only. This allows such an online video storage service. However, it also allows use of this access token and the special account to, once again, access the camera feed. And we're back at a security risk. I don't know how to solve this...

---

EDIT: By combining all of your suggestions (many thanks), I was able to draft a new security plan. To prevent moving the goal posts, I have created a new question for this:

How to securely encrypt data with a public-private key encryption scheme, but also allow decryption if the private key is lost?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

Storing default passwords in cleartext

Is it insecure? Yes.

Is it avoidable? No. You need a way to provide the user with his password.

It it manageable? Yes: disallow remote access with a default password set. At this point, you might as well revert to using a standardised default password. It would save you a lot of hassle and customer service work. Note that your solution offers more security in case your local access uses wireless technology. With default passwords roaming attacks are a possibility.

Storing custom passwords in cleartext

Is it insecure? Yes, very.

Is it avoidable? Not with your constraints.

Is it manageable? Yes. Use multi-factor authentication.

One option I see is to pair your password with an authentication token. You could create a simple local app that would require physical proximity to register it to the camera by using bluetooth, WiFi, physically pressing a button on the camera or something similar. Once registered you'd pair the token with the custom password to allow global access. You can integrate the token with your mobile app of course (stored client-side).

Alternative

Instead of storing custom passwords centrally on your servers, consider storing them at the client side instead. Users only have to configure their app once by logging onto their cameras (or the camera node if a central system/camera contains all installed/other cameras). Presumably other authentication mechanics or tokens can be used after the first login to avoid saving the password. The downside here is that you wouldn't be able to access the cameras from public access points without knowing their passwords. Using a central node only requires a single password so mitigates this somewhat.

Answer 5

If you want to prevent your own employees from accessing the camera or saved streams without customer's permission, you'll need to encrypt the video stream before the stream is sent out to your server for remote storage on your server. The stream should be encrypted with a session key, the session key is then encrypted again, once for each of the customer's public keys. Now, the server cannot decrypt the stream but anyone who has the private key matching any of these encrypted session keys will be able to decrypt the session key and therefore decrypt the stream. Your servers only stores encrypted stream and the encrypted session keys, which are by themselves useless without a matching private key.

To allow your employee limited access to a section of the stream, the client at customer's device or the camera at the customer's permission will need to download the employee's public key, and reencrypt the session keys for the sections of video he want to share using the employee's public key. The camera should change the session key regularly (about every minute or so) as the granularity that the customer can share their video is based on how often the session key changes (to share with a finer granularity would require reencrypting the stream itself, which is undesirable).

To terminate permission on a live stream, the camera only have to change the session key and notify all live clients that are still permitted to view the stream of their new encrypted session key. Note that once a section of a stream is shared with a person, that section of the stream will decodable by that person forever. However, the person won't be able to decrypt any past or future part of the stream.

As for the initial setup, I think it's reasonable to require that the initial setup of the camera must be from a physical access. You could use NFC or Bluetooth or you can install a screen on the device to facilitate key exchange between the camera and the client device.

Encrypting the stream before sending it out also solves the insecure local network problem.

Answer 6

Definitely change your password from the default password, but plaintext passwords can definitely be viewed. As others have mentioned, you should definitely hash the passwords.

Even if you change your password, your camera might be remotely accessed by a bot. Many hackers are reaching security cameras and pooling them together as part of the Mirai botnet. That’s a serious use case to consider.

Users can scan if their IP (including the cameras) and network is infected with the Mirai botnet: https://www.incapsula.com/mirai-scanner.html

But don’t assume that even though they aren’t intended for security uses that they won’t be targeted. In fact, they might be taken over and the customer isn’t even aware and won’t know to do a factory reset.