@sebastian-roth said in How to disable "password viewing" in the web UI:
Would be interesting to hear what others think about this.
Couple thoughts…
You can create an Active Directory service account with pretty limited permissions, only allowing it to join systems to the domain, and use this for FOG. This is something everyone can begin doing right now. This reduces the blast-radius should the credentials that FOG uses became exposed or compromised.
In the great majority of enterprise I.T. systems I work in, you can retrieve a credential “ID” (like username or access key) but cannot retrieve the credential “secret” (like a password or secret key). FOG is unique in this area, because the FOG Client needs the complete credential. Though, users should be entirely prevented from retrieving this credential… more on this in points below.
Merely concealing the password with the UI, someone who already has access to the FOG server could still potentially use the API to get the password. So, concealing via the UI is just obfuscation and not real security. Concealing via the UI is likely fairly easy to do and would result in less bugs to work out, but this isn’t real security.
Best solution in my view is to store the password within the database using reversible encryption. The encryption key should be generated by the FOG Installer, and put into /opt/fog/.fogsettings. The API / web components would then use one of several ways to handle encrypting and decrypting using this key. A quick internet search reveals lots of options:
https://stackoverflow.com/questions/9262109/simplest-two-way-encryption-using-php
https://www.educba.com/php-encryption/
https://www.tonymarston.net/php-mysql/encryption.html
After implementing, the ability to retrieve the password in any form/nature should be secured… which leads into point 5 below.
The transport layer between the FOG Client and FOG Server is already encrypted, but should someone call the server endpoint to get the credentials, we don’t want the password to appear plain-text within the server response. I’ve not looked into how this currently works so I’m unsure in this area. But, I’d think the FOG Client would first prove it’s identity with
client-based authentication, and after this the FOG Server would provide the password to the FOG Client. Maybe it already works this way? No idea. I’m remembering
@Joe-Schmitt talking about this, and how he worked with
@Tom-Elliott to solve it… This was a long long time ago though, and my memory of it is super fuzzy.