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?

Community
  • 1
Pimgd
  • 291
  • 1
  • 12
  • 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 08 '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 08 '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 08 '15 at 14:56
  • @zedman9991 the synchronization feature would not be available and the control app would probably demand that you log in to our platform that is offline. Its perfectly possible to control the cameras without being logged in to our platform, however. – Pimgd Jan 08 '15 at 15:06
  • You could have multiple access levels - an observer can only view, an admin can configure, for example. The online recording system would only need observer access, anything else, including programmes sweeps of the monitored area, would be configured by an admin logging in. This should be on top of all other methods of course. – Chris H Jan 08 '15 at 17:49
  • 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 08 '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 08 '15 at 19:33
  • @asteri I'm not sure I would be allowed to get a security expert on this. More likely, I would be pressured into accepting that "you can't make everything perfect". I don't know how to present my case strongly enough to be able to get someone with experience to take a look at a plan... – Pimgd Jan 09 '15 at 08:05
  • 1
    You talk about passwords everywhere. Why do you need to keep passwords? What forces you to keep passwords rather than some other token? – user Jan 09 '15 at 10:09
  • @MichaelKjörling The default password is there to restrict access to an unconfigured camera to support, and the person who has bought the camera (although we might slap a sticker with this code on the camera, changing it to "physical access") instead. The custom password is there to disable the default password, and to allow a user to authenticate/connect to the camera from a different device than the device used for configuring the camera. – Pimgd Jan 09 '15 at 10:18
  • @MichaelKjörling The reason we would store this custom password in our database would be to allow password synchronization - you would log in to our platform on your device, and the passwords would be synchronized, like some online password manager. We're now considering cutting the feature all together, or making it opt-in, or making it temporary (you push to sync on your device with passwords, the passwords are stored in our database, you connect with another device and receive the passwords from our database, we clear the passwords from the database). – Pimgd Jan 09 '15 at 10:21
  • @MichaelKjörling a secondary use for the passwords in the system would be to allow an online recording service (opt-in) to access the camera feeds and store these online, so that in the event of camera theft, a user can view what happened. If we remove the passwords from the database, we will likely come up with some sort of access token that the camera generates, and, with permission of the user, sends to the recording server. This access token could then only be used to view the stream (and then record it). – Pimgd Jan 09 '15 at 10:24
  • 1
    The question is kind of long, nice formatted but to long to read without knowing if it's worthwhile. Would be a nice move, if you could ad a TL;DR Part to help people to decide if they want to read the whole text. – jawo Jan 09 '15 at 11:38
  • @Sempie I have moved the latest edit to a separate question, since we went far beyond the topic of storing plaintext passwords. Is the question still too long? – Pimgd Jan 09 '15 at 11:40
  • You're not in a least bit worried that some robber or assassin can come up with a better plan using all the video streams to make his move? Maybe that only happens in video games like Watch_Dogs... – ADTC Jan 09 '15 at 13:13
  • @ADTC analyzing such large amounts of video data would take some serious computer power. We'd have just enough to process (read and write to disk) said video streams, they'd need enough power to both read AND analyze all the video data. Additionally, they'd need to copy or otherwise steal large quantities of data in a short period of time - I imagine that old footage is worth less and less as time passes, so you'd be looking at something that can process all these video streams... realtime. No, I'm not worried that some hacker will do that. – Pimgd Jan 09 '15 at 13:17
  • I'm actually not talking about automated computer analysis at all. Talking about human analysis where someone with an agenda could watch the video streams live or recorded to study the behavioral patterns of his targets or the environment of his choice and formulate an action plan to attack it. I think your security as a company will be at a huge stake if that ever happens because your passwords were in plain text and for anyone to grab. Consider revising your definition of sensitive data. Protect your customers :) – ADTC Jan 09 '15 at 13:27
  • @ADTC are you just speculating here, or do you know of an attack vector I haven't covered yet? – Pimgd Jan 09 '15 at 13:40
  • Seeing questions like this proves that I am right for not trusting websites with my data. Passwords are kept secret for a reason. Why on earth would you think it would ever be ok to store it as plain text? Passwords are reused (not by me, but most people). Also... Just because it's a camera doesn't mean people don't store sensitive information on its SD card. – jay_t55 Jan 09 '15 at 16:03
  • @jay_t55 Why on earth would I think it's ever okay? Because it's like a wifi password. Also because I'm running the implementational part of the project mostly solo. It's hard to remember everything. – Pimgd Jan 09 '15 at 16:15

6 Answers6

23

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.

Canadian Luke
  • 296
  • 3
  • 13
PiTheNumber
  • 5,394
  • 4
  • 19
  • 36
  • What happens if the device used for the initial configuration is lost (phone drop, screen cracked, phone tossed?) – Pimgd Jan 08 '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 08 '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 08 '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 08 '15 at 15:27
  • Hmm... like this, it would also be possible to add a streaming server as a "device", with the customers approval. – Pimgd Jan 08 '15 at 15:33
  • Why would I want to store the public keys on my server? How would that allow granting access to other devices? – Pimgd Jan 08 '15 at 15:35
  • You need to get the public key from a new device to your current device and from there to the camera. If you store the key on the server you don't need to move it around, the camera can get it directly from the server. Sure, you don't need to store the public keys on the server but it adds some comfort and I don't see a security reason not to do it. – PiTheNumber Jan 08 '15 at 15:52
  • I'm still confused. How does storing the public keys on the server prevent employee access? Sure, I can't use one of the public keys (since I can't read the response, lacking the private key). But what's stopping me from adding my own public key in the list, after which the camera adds it to its own list? Additionally, if no authenticated devices are left, the camera must be factory-reset. I'm not sure that's a problem, though. Most likely not, but it's something to keep in mind. – Pimgd Jan 09 '15 at 10:36
  • 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 09 '15 at 11:12
  • I see! This solves my problems in full - that which it doesn't solve is probably out of scope for this question. I will ask a new question for that, I think. – Pimgd Jan 09 '15 at 11:19
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.

Michal Paszkiewicz
  • 191
  • 1
  • 4
  • 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 08 '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 08 '15 at 11:49
  • Each camera has an unique number that it knows internally. By using that as the salt, we're also no longer open to a rainbow table. We've also made it possible like this to preserve the possibility of not using the platform if it's offline and falling back on local communication with the camera instead; the client can hash the password on its own and our platform is only needed to allow the webplatform to access the camera. – Pimgd Jan 08 '15 at 12:48
  • Thanks for the idea of having the whole system use hashed passwords! Both questions are now answered; the current use of plaintext is somewhat insecure, but avoidable. In the new system, there's still usage of plaintext passwords (the defualt passwords), which is unavoidable, but they're not a security risk. – Pimgd Jan 08 '15 at 12:56
  • 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 08 '15 at 13:54
  • As I see it, you are still storing plaintext custom passwords, they just happen to be the hashed versions of the password the user entered to prevent a compromised database from impacting other services. Hashing a string doesn't magically make it secure. In this case, the resulting hash is used as the password to authenticate (a client logging in locally would have his input hashed twice) and is very much plaintext. – Lilienthal Jan 08 '15 at 13:57
  • @Lilienthal but it requires creating a custom client to access the device. ... that, or ... providing the app with a custom tailored server response... on a local network... with a different DNS server... okay that can be done. But when you're in like that, the customer can perform a factory reset and enter a new password, and the problem is "fixed" again. The access level gained is not root level access. – Pimgd Jan 08 '15 at 14:20
  • @Victor Very good point. How do you suggest fixing this? We can remove the sync password option, but I'm not a huge fan of removing that functionality... plus, we intend to add a 24/7 cloud recording service where we will save your camera stream online so that in the event where your camera is stolen, you can still obtain the video material (people don't like setting up their own all-day-long downloaders, they're lazy). – Pimgd Jan 08 '15 at 14:27
  • @Pimgd I don't see how Michal's suggestion solves the problem of authenticating from the server to the camera. Your central system needs a cleartext password to login to the camera, unless you want to use an alternative authentication mechanic, which might be an option. (Public/private keypairs or certificates to recognise the master server? But then you'd be able to control all your cameras regardless of passwords) – Lilienthal Jan 08 '15 at 14:33
  • 1
    @Lilienthal all it solved was that the issue of password reuse was no longer a danger. – Pimgd Jan 08 '15 at 14:37
  • I'd rather use bcrypt or some other strong password hash algorithm which takes a salt into account. – ComFreek Jan 08 '15 at 20:04
  • 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 08 '15 at 20:09
  • @Pimgd, sorry, I know it wasn't a very constructive comment, and people are lazy and like to have the lazy functionality rather than the good security. I have no idea how to fix it. Fix people, I mean :( – Victor Jan 09 '15 at 10:06
  • @Victor You were brave enough to poke a big hole in my plan; I'd have happily gone with the idea that "if the passwords are encrypted on the database, it's secure". I didn't even consider protecting the system from its administrators. – Pimgd Jan 09 '15 at 10:14
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.

kasperd
  • 5,402
  • 1
  • 19
  • 38
  • >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 09 '15 at 07: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 09 '15 at 08: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 09 '15 at 08: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 09 '15 at 08: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 09 '15 at 08:51
  • @Pimgd That's why it must require physical access to activate that feature. The most secure (but probably not the cheapest) would be to have two Ethernet ports where one is used under normal operation and the other is only used to reset the password. As long as the one for changing the password is connected the camera refuse to perform any operation other than changing the password. That way users won't forget that they left this port connected. – kasperd Jan 09 '15 at 09:22
  • That idea is not feasible for our situation. – Pimgd Jan 09 '15 at 09:27
  • In the end, I ended up asking a separate question for the collecting video streams service part. Thanks for giving me the idea to split my question, rather than continuously moving the goal. – Pimgd Jan 09 '15 at 11:49
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.

Lilienthal
  • 437
  • 4
  • 15
  • 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 08 '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 08 '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 08 '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 08 '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 08 '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.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • This seems like something that could work, if the camera has the processing power to encrypt the stream it sends out. – Pimgd Jan 09 '15 at 09: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 09 '15 at 09: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 09 '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.

White Hat
  • 39
  • 2