10

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?

  • 8
    So when I buy your system of cameras I also need to ensure you stay in business and remain live on the internet? If you fail to maintain your database or it gets zapped by nature or human my suite of cameras are no longer functional? – zedman9991 Jan 8 '15 at 14:23
  • 1
    @zedman9991: What exactly leads you to this conclusion? If I have understood correctly, the customer has a camera with a default password, and the default password printed onto the camera. As long as he does not lose the default password, he can log into his camera, and set a custom password, without help from the support hotline and without internet access. – Alexander Jan 8 '15 at 14:47
  • 1
    @Alexander your assumption may be correct but why not let the OP answer? The query comes from the step where multiple devices are provided simplified access and the design dependencies related to that feature. – zedman9991 Jan 8 '15 at 14:56
  • 8
    You should really hire a security expert instead of trying to outsource the effort on the Internet. I mean, you're lucky that StackExchange tends to have a solid, knowledgeable user base, but... – asteri Jan 8 '15 at 18:51
  • 4
    Require the user to press a hardware button to put the camera into "setup mode", and only then allow the password change via web interface. That way the password only needs to be on the device, and you can dispense with the default password altogether. Once a password is set the camera will begin to function. The camera should connect to your servers to get a "remote control" password, only if instructed to do so by the customer using the web interface. – Ben Jan 8 '15 at 19:33
22

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.

  • What happens if the device used for the initial configuration is lost (phone drop, screen cracked, phone tossed?) – Pimgd Jan 8 '15 at 15:19
  • @Pimgd With this set up, any authenticated device would be able to add/revoke keys for each camera. So if one device is lost, use a different device to revoke its key. – Ajedi32 Jan 8 '15 at 15:24
  • 2
    Same as if you device is hacked. Revoke key, factory reset camera, add new key. You can store on the server how has access to what camera, so after the reset you can offer add back the old public keys (if they are not revoked too). – PiTheNumber Jan 8 '15 at 15:25
  • 3
    @Ajedi32 You can store access levels with the keys in the camera. So the user can add administrators or view only devices. – PiTheNumber Jan 8 '15 at 15:27
  • 1
    You can't add your key because there is no such list. Nor does the camera add a key from the server by itself. Only the owner with a valid key can tell the camera to add a key. Depending on implementation, you might be able to trick the camera owner to add your key but you can't automate this. But you are half right. If the public keys are stored on the server, the customer might not be able to verify what key he is adding... – PiTheNumber Jan 9 '15 at 11:12
8

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.

  • Okay, the passwords are now hashed. How do I sync passwords between multiple devices? ... Hang on, you mean that the passwords are all prehashed throughout the whole system, except the point where the user enters the password for the first time? That's... an option...? We'd still store the default passwords in plain text, but the custom passwords could be prehashed. We're still open to a rainbow table attack after a database breach... but that's less vulnerable than a breach where we have plaintext passwords. – Pimgd Jan 8 '15 at 11:44
  • Yes, the case I am talking of is only really an issue with custom passwords, as the defaults do not compromise the actual user's security. – Michal Paszkiewicz Jan 8 '15 at 11:49
  • 21
    There is a HUGE security risk. You and the rest of the company can already access people's security cameras. They are all compromised out of the box. – Victor Jan 8 '15 at 13:54
  • 1
    @Lilienthal all it solved was that the issue of password reuse was no longer a danger. – Pimgd Jan 8 '15 at 14:37
  • 1
    @ComFreek the current plan is using HMAC SHA-something with a unique salt per camera, if we're gonna store passwords. This does not remove the whole "employees can access all camera's" problem, though. – Pimgd Jan 8 '15 at 20:09
6

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.

  • >Separation of hardware and platform< already implemented. >allow resetting of password via physical access< already implemented. >default password does not allow use of device except to set a custom password< already implemented. We already use local connections... – Pimgd Jan 9 '15 at 7:55
  • The separate default password per device is to delay attackers; with one universal default password, it only takes an online manual lookup for obtaining the password, which kind of defeats the purpose of having a default password in the first place (might as well require no authentication on an unconfigured device). – Pimgd Jan 9 '15 at 8:00
  • I like your ideas, but we've thought of these things already. They don't solve any of the problems we're facing right now (employee access, finding a way to allow a device under our control to access the camera only with customer permission). – Pimgd Jan 9 '15 at 8:02
  • @Pimgd You are right in saying that a well known default password is no more secure than no authentication. So you might as well skip that step and say that somebody making use of their physical access to the camera gets direct access to a page where they can change the password. The important points then are that the server collecting the images will know that this happened, and that an image of the person doing it is stored before they get close enough to change the password. – kasperd Jan 9 '15 at 8:41
  • The whole idea of default password/custom password that password change is only possible with the default password if no custom password is set. Allowing password changes without providing the current password means that a person's local network becomes the weakest link... which is harmful in areas where multiple apartments share a wifi network (like flats). – Pimgd Jan 9 '15 at 8:51
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.

  • How do you propose synchronizing custom passwords between a tablet and a phone belonging to the same user, if not via our service? – Pimgd Jan 8 '15 at 14:31
  • @Pimgd Hency why it's an alternative. If you want to synchronize passwords you need to store them centrally, which is a security risk. It seems safer to let your service function only as a public access point for the cameras so users still authenticate directly with the cameras. – Lilienthal Jan 8 '15 at 14:39
  • After some thinking, I've managed to come up with synchronizing the passwords via local network. You're left with manual entry if you have work and home devices, but atleast some sync is possible. I'm still left with a streaming server that has to be able to access the camera if the customer allows us to do so... – Pimgd Jan 8 '15 at 14:46
  • @Pimgd Can your streaming server not simply pass the password provided by the user to the camera instead of storing it permanently? – Lilienthal Jan 8 '15 at 15:24
  • In the event of a connection failure, or maintenance, or other things that require a stream restart, a user would have to resupply their password. – Pimgd Jan 8 '15 at 15:28
2

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.

  • This seems like something that could work, if the camera has the processing power to encrypt the stream it sends out. – Pimgd Jan 9 '15 at 9:38
  • @Pimgd: yes the drawback of this approach is processing power. However, the session key could use a symmetric encryption, which is much less resource hungry than asymmetric encryption. The camera should only need to use asymmetric encryption for encrypting the session key itself, and the session key itself is a symmetric key. Also, if you have control over the hardware, some modern embedded CPU feature hardware-accelerated crypto engine with decent throughout, e.g. ARM. – Lie Ryan Jan 9 '15 at 9:58
  • I will try to see if I can use this. One thing that worries me is that a customer cannot decrypt streams on a device that wasn't authenticated to the camera prior to the creation of the stream. This means that if burglary happens, and the camera + one's mobile device is stolen, the video footage cannot be retrieved. I don't want to know the PR explosion that would result from such a situation. – Pimgd Jan 9 '15 at 10:08
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.