Make authentication enabled by default

[Palakis]

Issue type

Feature

Description

Encourage better security practices by default in the plugin:

• Turn the "Enable authentication" option into "Disable authentication" and make it unchecked by default
• Prompt for setting a password on first run (after the plugin is installed or when settings are reset)

[gaulinsoft]

I like the idea of having an approve/deny popup #54 if an unknown client connects (as long as there is a way to disable this feature) as this seems to accommodate most situations with the least amount of hassle. This is the same way an Android phone works when you first connect it to your computer, and makes the most sense rather than requiring an arbitrary password most people do not want. Better yet why not just use a different port for local vs remote connections? I guess a potential issue would be JavaScript clients in web browsers trying to access locally but doesn't CORS already solve this problem? That way you can have an unsecure localhost port that any local program can access without hassle (unless the user disables unrestricted local access via some checkbox) and then an option for a remote access port which requires also providing a password to enable. That way you get the best of both worlds, simple quick default unrestricted local access, but to access remotely you have to enable the remote port manually and are now at a point in terms of user interface design that makes sense for them to be providing their password since they willing chose to go into their tools menu.

I think the practice of showing a popup requiring the user to provide a password on first load is bad interface design. Nobody wants to be forced to create a password if it isn't necessary. If you're this worried about security (then you should have done something years ago) just show the tools popup on first load rather than a popup requiring a password with an unchecked disable authentication box. I mean there's a reason you need this annoying popup, because you can't require a password without asking for one. But that's the flaw in your logic, you can't force security enabled by default since it would require a password that doesn't exist. Point being stop forcing security on your users and let them make the decision when they see the tools popup on first load. Keep the checkbox "enable authentication" just like every other application in the world that focuses primarily on local network connections.

Otherwise what myself (and probably other people) are most likely going to do is just include the 4.8 binaries automatically with our application instead of redirecting users here to get the latest version. Because when it comes to end-users, people are lazy and want to do the least amount of work possible. That means these people want to install my application and the websocket plugin by simply dragging and dropping the files, and then everything just works. And guess what? This makes complete sense for a 100% local set of processes. So unless these people plan on accessing their firewall and opening the required port, there's no reason for this excessive security (as long as you can restrict things such as web browsers).

Again think of the target market that actually uses the software we create. These are normal everyday people most of whom don't know the first thing about technology. It is our job to keep things as simple as possible for them and I can assure you no live streamer wants to deal with putting a password into their OBS just so some third-party application can access it, nor do they want to have to manually disable this feature either. So either show a popup for an unknown client on first connect like Android phones do or just show the tools popup on first load without changing the checkbox itself, and stop trying to go down a design path that will ultimately just force people to manually distribute and utilize older versions of your plugin.

[notr1ch]

I don't think you fully understand the threat that web browsers pose. Browsers run on the local machine, and provide a JS API to allow websocket connections. They can connect to any port, so trying to hide it with a different port does not help. Websocket connections are also not constrained by the same-origin policy. Normally a websocket server is required to check the Origin to verify the source of a request, but with obs-websocket how do you determine what is a valid origin? You have connections both from browsers and 3rd party utilities, changing that behavior would likely break all existing implementations.

In the current state, any web page on the internet has unrestricted access to your OBS via obs-websocket. Not only could a malicious page cause a data leak / loss, but for example adding a source with an internet hosted UNC path could be used to steal Windows credentials. It may not even be outside of the realm of possibility to achieve remote code execution as OBS was not designed to defend against untrusted API calls.

[tt2468]

stop trying to go down a design path that will ultimately just force people to manually distribute and utilize older versions of your plugin.

Seems a bit dramatic that asking for a password on first load would cause so much trouble that people would want to start developing their own versions of obs-websocket. I don't see a reason why there couldn't be a button on the popup that allows users to acknowledge the inherent security concerns of not having a password, and have passwords disabled. Something like how Chrome has you click a button to confirm that you are connecting to an ssl site that has a self-signed cert.