core: services: wifi: add support for WPA-Enterprise #1823
Labels
core
Issue related to BlueOS-core
enhancement
New feature or request
security
triage
Needs triage from developers
ui
User Interface feature
Current behaviour
There is currently only support for WPA-Personal connections (with an SSID and an optional password), which means WPA-Enterprise networks (which also require an "identity"/username) cannot be connected to, which is annoying for users who only have access to such a network, and also prevents using more secure wifi connections.
Raised in this forum post.
Expected or desired behaviour
If it's somehow possible to detect the network type then it would be nice to just include a username field in addition to the existing password one, and then auto-fill the relevant network parameters. Assuming that's not possible, the most intuitive interface I can think of would be having an "advanced settings" dropdown that provides access to things like the username, key management, etc.
From a quick look online I believe the password should be hashable by the process described here, but I'm not certain about that. If the password is not hashable for this connection approach then we should either disallow using a password for such a connection (i.e. only allow them for unsecured networks), or at minimum provide a warning to the user, because enterprise networks often use single sign-on structures whereby a person's username and password is shared across various services, including things like wifi access, email access, and intranet access. This is particularly relevant because a person logging in to an enterprise account is likely not using a personal vehicle, in which case other members of their team / faculty may get access to their login credentials when using the vehicle later.
Ideally we would also be able to re-prompt for credentials at some (user-specified?) frequency, but I'm not sure how hard that would be to set up or enforce. Perhaps it could be achieved by some settings that BlueOS checks on startup and triggers a wipe of any enterprise credentials if the timeout has passed, or alternatively it could just wipe those credentials whenever it starts up (and potentially also as part of the normal container shutdown process?), to enforce a minimum of one enterprise login per BlueOS restart.
It's worth noting that enterprise organisations may not want Raspberry Pis connected to their networks without some explicit approval, and even with a hashed password it's not super secure - a more recommended approach for tethered connections would be to pass internet through the tether, which we can potentially even suggest as an alternative when someone opens the advanced wifi connection settings, as something of an "are you sure?".
Prerequisites
The text was updated successfully, but these errors were encountered: