- ActionTiles Forum
- Security
-
Questions & Discussions
Embedded Video credentials blocked by Chrome: What's the risk to not using a username/password?
So after tooling around for a while trying to figure out why my Media Tiles (Wyze Cams) no longer worked and eventually discovered that I could get it to work by logging in directly to the URL via browser then it would work in Action Tiles in that same browser but not being able to do it in the Action Tiles app because you can't just enter a URL directly into it and getting 95% of the way through opening a support ticket and then finding this handy Knowledge Based article https://support.actiontiles.com/knowledge-bases/8/articles/5508-media-tile-broken-due-to-url-with-userpasswordaddress-embedded-credentials explaining that Chrome, Android Webview (including Fully and ActionTiles android apps), and most Firefox browsers are now blocking embedded credentials. I get it, not ActionTiles fault, nothing they can do about it. Moving on...
Simple fix.... remove the login credentials from my web server on TinyCam Pro.... Problem solved right away.
However, now I'm a little worried....what risk am I exposing myself too? I'm a programmer by trade, but I'm not all that privy on internet security. My my understanding is that the Tiny Cam web server that's running on my Kindle is on my local network and traffic to it is blocked in my routers firewall. With out setting up port forwarding and explicitly allowing a connection from the outside world into my LAN, I really shouldn't have any concerns. Is that correct? I have no intention on opening up ports on my router as I have no need for remote access into Tiny Cam, I can just view the cameras in my Wyze app. So am I safe?
Thanks
Customer support service by UserEcho
Great discussion topic, Michael!
The good news is that for tinyCam Monitor Pro MJPEG/JPEG server, you can still use "embedded" credentials because it accepts them as parameters. This is also possible with older model Foscams (etc.). These commands are actually standard for the "Axis" firmware and are documented here: https://support.actiontiles.com/communities/12/topics/3441-tinycam-pro-android-app-web-server-stream-rtsp-and-wyze-cam-to-actiontiles#comment-16626
Without https (SSL), there is still some risk here that these can be read by a network sniffer. That is not too likely within your local network, but if you have set up Port Forwarding or an insecure VPN, then you might be using this path at a hotspot or from your office, etc.. And these credentials are saved in the ActionTiles database and are (inevitably) shared in plain text if you Share the Panel to a Buddy.
So besides sophisticated network sniffing (where having credentials in the URL isn't much protection and, if you use the same username and password as you do for any critical websites like your banking (!!!), is a big no-no)... what is the risk of have no username and password at all? That is currently the method required for access to Blue Iris since it doesn't allow parameters - only the blocked user:password@address option.
If you are only using ActionTiles on your home LAN - on the same LAN as your camera or transcoding server (tinyCam, Blue Iris, VLC, motionEye, ...), then the risk is minimal because your LAN traffic should never get outside your home. Hey - but it's wireless! That's why WiFi is encrypted with a strong password (current methods WiFi encryption is considered secure).
There's only risk if a device permitted on your LAN (a PC, smartphone, camera, smart hub) is sniffing your network. It could do that if it is inherently bad or if it has a virus or bot, or if it intentionally opening a portal to bad guys. Some of those can and are prevented with firewall and anti-malware / anti-virus on your devices and/or router. Now those bad guys can access your transcoder with no further login required. They can use that to spy on you, or possibly inject a robot into your camera(s).
The extra safe method is to use a separate LAN just for the tablet and transcoding server: A "VLAN" (virtual LAN). This is an overly paranoid technique for most households (IMHO) that isolates traffic between a specified set of devices. A rogue smartphone ... e.g., a guest who is using your WiFi, can't access the devices on the VLAN (the tablet and transcoder) or inject a virus into that VLAN, smart hub, important work PC, etc..
That's just a general dump - there are much better explanations available in many internet articles, of course.