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?
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: