Password sent in plain text over the internet from mobile?

[akramer]

I am testing out Sighthound, it seems to do a some things wonderfully and a few things really badly.

There seemed to be no way to specify HTTP vs HTTPS in the mobile client, and there was no way to generate a cert or pin a CA in the app, and so I figured it might be plaintext.

I just ran a packet capture and verified that passwords are sent in plaintext using HTTP Basic authentication. There does not appear to be any way to use the mobile client without exposing your password to everyone who can see your packets between you and your server.

Here's a screenshot of wireshark displaying one of the HTTP requests. My (testing, obviously) username and password are visible unencrypted, just base64 encoded, in the Authorization: header.



Are there plans to fix this?

[ryan]

Hi akramer,

As you can see from the remote access dialog, the links provided are http. The remote access dialog also explicitly states that Basic auth is used. There is no attempt to obscure this, a packet scan isn't necessary to find this out.

This is no different for users who would normally forward their IP cameras out of their network. I don't know of any cameras which are https enabled by default.

There are any number of scenarios someone might use remote access for which require any number of different options and configurations. Some of those are not addressed by the current implementation, but many are. Again, there is no attempt to hide the current behavior, in fact the app explicitly calls it out.

We would certainly like to add other options to accommodate other usage scenarios in the future. These are decidedly non-trivial, and must be addressed one by one. HTTPS for example, requires a certificate as you note. This certificate must be securely signed and protected for it to be trustworthy, which means it *cannot* be distributed with the application, so we cannot pre-package a cert. If we did, it could trivially be extracted, exploited, and subsequently revoked. Could we make a “fake” self-signed cert to include? Yes, but browsers would warn (or block) you about the unknown authority unless you subsequently added the certificate to each browser and device you access from. It would be possible to leave this as an option for users to do, as a few cameras are beginning to do, but the process is highly technical and full of hiccups (getting on to all devices, having the apps recognize this as a legitimate certificate, etc..) and would not be suitable for the majority of our users.

The more traditional use of certificates and why we think of https when we think of web traffic is that the server hosting the website is typically singular (not every users machine) with only the owning company having access to the cert. This would be possible for the mobile apps, with the caveat that *all* of your traffic would be flowing through a Sighthound server, which is something many of our users would be opposed to on principal, they only want their video on their machine(s).

Another option, not much worth mentioning, would be rolling our own security layer, but you should probably be generally skeptical when anyone claims to do something like that.

Hopefully that helps clarify why the application behaves as it does now. Remote access is a very young part of Sighthound Video. It may not be optimal for everyone in the current incarnation - you might need https, others might require alternate layouts, someone else might need rule manipulation - but it certainly has not stopped evolving. We have an extensive list of features we would like to add, spanning every spectrum - functionality, optimizations, access methods, etc...

Best,
- ryan

[akramer]

The setup screen for remote access only says "Basic auth is used". That doesn't mean it's unencrypted - basic authentication is perfectly okay if used over SSL. There's nothing indicating to a technical (or non-technical!) user that by checking the "Open a port on my router" box and using the provided app, something nearly impossible to use securely is going on.

Not only can anyone between you and your server passively sniff your credentials and view your cameras, they can also turn the cameras off!

You've got to make this more clear to users, both in the mobile apps and in the setup screen for Sighthound. I understand that it would make the feature much less popular, but it *SHOULD* be less popular given the current implementation.

I also understand that what I'm talking about is technically difficult, and the options you presented are not wrong. I think you'd be able to get away with a simpler implementation if you wanted, though. I don't care if I'm using HTTP when connecting over my local network, I only want to use HTTPS with mobile clients connecting remotely. The mobile client could scan a QR code displayed by the server software to pin the self-signed certificate, or just show a fingerprint upon first connection and ask the user to verify that it's correct. This would only need to be done once and then things would be secure and simple from then on out.

Or at least let me stick a reverse proxy in the way if I want, and terminate SSL connections there. The mobile app has no capability to support SSL at all. Right now there is NO secure way to use the mobile app besides running a VPN client on my phone and connecting directly to my local network.

[ryan]

Hi,

I feared my post was growing longer than anyone would read, so there are indeed a number of possibilities I left out. Pre-packaging a self signed SSL cert *for mobile apps only* is something that we've talked about adding into an upcoming release. One challenge there comes from the complication that remote access from browsers would then need to go into a variety of modes between disabled, enabled but restricted to http, enabled with both, enabled with https and detailed instructions on how to configure your respective browser to ignore cert warnings, ... I don't list those to imply that they are incredibly difficult to implement (though they are non-trivial to educate on), but instead that this more addresses one or a few specific use cases and requires a higher level of technical expertise, rather than being all inclusive and easy to use. In spite of that, as I noted before, we aren't at all opposed to doing so and are actively investigating all such options.

The above may make its way in to an upcoming release. Highly technical options for configuration and encryption, including adding custom self signed certs for all aspects will be a requirement for an enterprise version of the app. Our immediately impending update to the current version also lays the groundwork for us to investigate and implement a number of other approaches not mentioned in this message.

To answer your original question as to whether there were updates planned in this area, the answer is "yes indeed, many". I'm sorry if this feature or Sighthound Video as a whole don't meet your needs at this time. We have big plans and are hard at work on them.