How to disable "password viewing" in the web UI

[george1421]

@rogalskij I can say based on HTML, in theory it can be done. From a HTML/CSS perspective the programmers can just defined the field as password and the browser will encode the password so it can’t be viewed. If we can point to the fields that need to be protected we can submit a feature request. I don’t use that feature in FOG so I don’t know what fields need to be protected other than what you’ve mentioned.

[rogalskij]

@george1421 Thank you for the information George. The fields that I see it affects where you can actually view the password in plane text are as follows:

storage node general > Management Password
Hosts >pick a host > Active Directory > Domain Password
Fog Configuration > Fog Settings > Fog Storage Nodes > STORAGENODE MYSQLPASS
Fog Configuration > Fog Settings > Proxy Settings > Proxy Password
Fog Configuration > Fog Settings >TFTP Server > TFTP FTP Password

Could be others that I am missing, but these are where users of the GUI on my server can see the password in plain text. The ability to toggle this feature on or off would be great. Probably requiring an admin password to change the toggle. Thank you very much!

[Sebastian Roth]

@rogalskij We started to take care of this back in late 2019 (relevant github commit). So for AD password: It can’t be seen because it’s replaced by a row of * characters in the web UI.

I am not sure why we did not extend this to all the other password fields. I am open to discuss adding this to all the other password fields as well. Not sure if other users like it the way it is.

Hosts >pick a host > Active Directory > Domain Password

This one is fixed, just checked on a test installation. Please let us know if it’s not the case for you! Then I am pretty sure you’re not using FOG 1.5.9.

The ability to toggle this feature on or off would be great. Probably requiring an admin password to change the toggle.

There is no real concept of roles in FOG. So any FOG web UI is more or less an admin.

[george1421]

@sebastian-roth said in How to disable "password viewing" in the web UI:

There is no real concept of roles in FOG. So any FOG web UI is more or less an admin.

Could we do something like this? https://www.csestack.org/hide-show-password-eye-icon-html-javascript/ where the field would always be protected but the FOG admin could click on the eye to display the password?

FOG already uses font awesome library. But I might have a simplistic view of the problem because I don’t know the code.

[rogalskij]

@sebastian-roth On my 1.5.9 server you can absolutely see the AD password. It is blanked on the setting itself, but if you go into a host and click the “join domain” you can see that password in plain text no issue. Is this a bug on my system perhaps?

[Sebastian Roth]

@rogalskij said:

On my 1.5.9 server you can absolutely see the AD password. It is blanked on the setting itself, but if you go into a host and click the “join domain” you can see that password in plain text no issue.

Well that’s a different story. Good you are pointing this out because I didn’t see the forest for the trees. If you click the checkbox Join Domain after deploy it fill pull the global AD settings (FOG Configuration -> FOG Setttings -> …) and apply those to this host. You are right, someone can find the password this way. We shall fix that soon (reopened #337).

@george1421 Not sure I get what you mean. We already have the password hidden and a button next to the field to show it in clear text. You are still using FOG 1.5.7 in your productive environment, right?

[george1421]

@sebastian-roth said in How to disable "password viewing" in the web UI:

Not sure I get what you mean

I’m not totally sure either… I should have looked at the code and not guessed. Its good the OP was able to point to the screen with the visible password.

[rogalskij]

@george1421 and @Sebastian-Roth I really appreciate everyone taking a look into this so it could possibly be fixed in a later release. We use FOG every day at our College so I tend to come across different quirks time to time. So appreciative of the product and the support provided by the community, devs, and users. Thanks and take care!

-Josh-

[Sebastian Roth]

@rogalskij The issue where you could grab the AD password by clicking Join Domain after deploy is fixed in the latest dev-branch and will be in the next release.

I am not sure about all the other password fields. Don’t want to mess with this to easily as people might be used to it. Would be interesting to hear what others think about this.

[Wayne Workman]

@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…

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.