Add option to disable access via private URL. - Password Protect - Authentication

[TNThieding]

Please consider adding an option to disable access to a screen via private URL (i.e., the user would have to log in with credentials every time he/she wants to view a screen). I don't feel comfortable using integrations that show private data (e.g., calendars or to-do items) if it's exposed to the internet via a URL that someone might get ahold of.

[dmradford]

I second this. A security feature should exist which restricts access to a screen. If this feature were enabled, only logged in users and registered devices should have access to the screen.

Public, unauthenticated access to calendars is a significant security issue that should be addressed.

[cocarrig]

Hi Team,

Looking for some feedback on this request. The UUID security layer is protecting DAKboard screen via obfuscation and is passed via registration or link process to the devices. As the original requester has indicated, in the event that the URL is leaked in communication or other means it could be made available to an unauthorized party.

As it stands, most display devices used for DAKboard do not have dedicated input devices connected to them to complete login page forms on startup, and storing these credentials at rest on the physical device is not recommended.

We are looking to find if we have many users that have an input means (keyboard + mouse/ VNC) for their display device and would make use of an authentication step (account login credentials or other set password by user), or if instead would prefer to have the ability to revoke the private URL on demand and regenerate it for a device or screen when they have shared the URL.

[TNThieding]

For what it's worth, I use a Raspberry Pi setup with VNC enabled.

[cocarrig]

Thanks @TNThieding,

Based on the feedback I will be discussing internally the approach of a user set password from the 'Settings & Defaults' screen page that is optional for users to set.

[cocarrig]

At the moment we are interested in making this a future enhancement in DAKboard but do not have any timelines associated with this request yet at this time. We will be converting this request in the meantime to a Discussion for the purpose of gathering more understanding interest there is in the client base to gauge priority.

[dmradford]

FWIW, I think the most flexible / ideal implementation of this would be 2 fold:

Step 1: Ability to disable public the URL entirely and require a fully authenticated login for access.
This option allows users with input / VNC capabilities to access their boards while restricting unauthenticated public access.

Step 2: Registered devices (Dakboard hardware / dakboard image on Raspberry Pi) should not require a login since they are already uniquely identified and authorized / linked to the users' account. This link (or trust) could be used to authorize those devices without any user input.

When combining step 1 with step 2, a dashboard can have public URL disabled and the registered devices could still access it without any user input. My dakboard runs on a raspberry pi which does not have VNC enabled so this combination approach would be the least impactful for users with similar configurations.

[cocarrig]

Hi Team,

Being considered now is a user selectable password that can be added to any screen URL from the Settings & Defaults page below the private URL section. This would be an optional for users and give them the power to set length and complexity of the password for their specific use case.

Option 2 shared from @dmradford is a very good suggestion, but with high LOE is at now a future consideration at this point. We will capture this suggestion and further design details into a discussion case after the authentication mechanism is completed.

[captaindarth]

I concur with @dmradford regarding the ideal path forward.

Also, understood that folks might not have a connected keyboard to their Dakboard device. However, could the Raspberry Pi webUI have the ability to pass credentials back to Dakboard cloud for authorization purposes? The Pi would not need to store the credentials, but could simply utilize a saved session?

(It should be noted that Security through obscurity is not a valid security approach.)

[Amoeba00]

Just started using this and while I have an internal machine displaying the calendar - the lack of any option for security is concerning. It's a nice feature to just have a URL that can display the custom calendar with all the bells and whistles - but not being able to secure it at all is worrisome.

[davenasinraven]

I would like to add options for -

1. White list of approved MAC addresses of player device
2. Lan IP range for preapproved devices - helpful for all devices inside a lan or vlan.

[rodkvan]

This should be urgently addressed.

A few methods have been discussed above. The "easiest" would seem to be the suggestion from @cocarrig to implement a password where the user can dictate length and complexity and rotate it.

But agree with @captaindarth that "security through obscurity" is not good enough when calendar and other integrations are in play.

[MohnJadden]

Nthing the password complexity part, or even better, some form of MFA requirement - Duo, Authy, MS Authenticator, etc.

[cocarrig]

This has been released today, and the feature is explained in the following support article:
https://dakboard.freshdesk.com/support/solutions/articles/35000233523-screen-security-password-protected-screens

[Amoeba00]

This is fantastic! Thank you very much! Have a wonderful holiday season!

[iviikel1]

Although this is a helpful solution it just creates a new issue which renders the solution unusable in my large organization and wouldn't pass any of our cloud security assessments. It's a great product but unfortunately the lack of ability to limit access to the "public" URL without being prompted for manual intervention would never work for the 1000+ displays which wouldn't have input devices.

I guess I don't understand what would be so difficult to add an additional bypass to this password requirement from devices registered to the account or providing an IP whitelist where we could add trusted location public IPs.

The other glaring issue is the lack of MFA options for the console access other than using a Google account

[cocarrig]

@iviikel1,

Sorry to hear this doesnt work for your application. We are focusing our solutions on home end users quite heavily and do not at this time. An approach that involves an automatic means of authentication is something we would like to implement in the future but is not yet on our roadmap.