[Security Issue] Pincode visible (plain) in API endpoint

[JustJoostNL]

I recently found a pretty big security issue in Ontime.

The /ontime/settings route returns information about the Ontime instance, but also returns the editor and operator pin codes in plain text.

This endpoint doesn't require any authentication, so is publicly accessible. That means anyone can "hack" into the Editor/Operator pages.

[cpvalente]

Hi @JustJoostNL thank you taking the time to fill in an issue report.

We used to have a disclaimer in the application about the security in Ontime. It was removed, and I will ensure it gets added to the new docs.

The burden of authentication should fall on the network access. Ontime is NOT safe to distribute in a public network.

The pincode is meant for a user that accidentally lands in these pages, as an effort to indicate that it is behind closed access

If we were to make Ontime secure, we would need to add authentication to all integrations. That would significantly impact our ability to use protocols like OSC or integrate with vMix and other hardware

Having said this, I am happy to consider suggestions to improve the application's security. But these should be considered in the scope of the application and the environment where it is meant to be used. There is no expectation that Ontime will be truly secure in a way that you should be able to deploy it to a public network

[JustJoostNL]

Hey,

Thanks for your reply.

I understand that Ontime is not meant to be deployed in public environments. But I do think that the pincode check should happen in a different way. For example, an endpoint called /check-code which returns success: true/false and based on that, it allows access or not.

[cpvalente]

Hi @JustJoostNL, I agree that this can be improved and your solution is better.

It is important for me to be vocal that Ontime is not secure, as much as we mask it to look like it. Unfortunately, at best, we can make it annoying for an ill-intended user to go past these pages.

Your suggestion is definitely better than the existing one, but how about:

• easy and quick: using some obfuscation technique, we can use a key to obfuscate the pins sent to the client. A user would still be able to see this but won't necessarily see the correlation with the pincode. This key could be hardcoded in the app, or generated at build time.
• cooler, more nerdy, not sure if better: using react server components for the authentication page. I fear this could be a little bit painful to setup for a single page and probably not worth. but it sounds fun

Would you be interested in proposing a PR for this against the v3 branch?

[JustJoostNL]

Hey @cpvalente, your suggestions for improving the security are on point. I personally like the react server components idea the most. Unfortunately, I currently do not have the time to work on a PR. If you decide to build this feature yourself, I am open for testing. Though I understand if you don't have that time as well.

[cpvalente]

We have implemented some simple obfuscation in the newest alpha release. There is no plan to work on this any further