On Fri, Jun 27, 2025 at 4:22 AM Tobias Feller | OPC <tfel...@opc.de> wrote:
> Hi guacamole developer, > > I have some idea in my mind for a long time that i am willing to share for > discussion. > > Problem/Security concern: > > - Storing the connection-passwords in the database in cleartext > > Situation: > > - We support many hundred servers via our support team. > - The end users connect via a 1to1 User/Connection-relation with > assigned connection-password to a secured remote environment that is fine, > no security concern for us. > - But the support team connect to the admin session with username <> > connection-user, so there are two options - Assign admin password in > connection (bad feelings about this) - no password, so that the support > user must search for the server password in password manager, copy and > paste it into the pre-connection dialog, click connect. But that's annoying > for the supporter each time they connect to the servers. > > Idea: > > - Extend the pre-connection-dialog with a "Save for future connection" > checkbox ... > > This has already been put in as a feature request: https://issues.apache.org/jira/browse/GUACAMOLE-1428 > > - > > Changes/Implementation suggestions: > > - Encryption / Save process of credentials/password after input in > pre-connection-dialog > - Encrypt Username/Password with Login-User Password -- some ideas to > discuss... > - Maybe here is a problem because you don't want the > user-password info stored in memory for each user after login - but > wait > isn't there "${GUAC_PASSWORD}" - parameter token - so it already > must be in memory... > - Alternative? Generate a session key (like OAuth2 - > Access/Refresh-Token System) and encrypt with that? Last session-key > must > be stored to update the encrypted credentials with new session-key > after > each user-login (decrypt with last session key/encrypt with new) > - Or User must input his User-Password again to save the > credentials on activate the save checkbox. In my option the best > option in > case of security, and also known on different system when changing > settings, but than we have the problem with decryption for reuse > again. > And in case of User-Password change the credentials must be > saved again for each connection. > - Use some local secure browser cookie for the > encryption/decryption. So the security for the decryption is in the > user-browser. But than we need to support multiple > > gucamole_connection_credentials(user_id,connection_id,browser_cookie_id) to > support not only one browser/device for the "Save for future use" > - I think this is the way to go? Or are there any other > ideas, that are safe in case that the "db / system" is > compromised to not > expose the critical connection-user/password list? This also adds > a > security layer. Because the key is also browser dependent. But we > must be > aware of a shared DB that is used by multiple guacamole - systems > / HA - > Loadbalancer - Standby - via different domains/urls. > - In case of OpenID/Saml - guacamole can maybe also use the > IdP-given AccesToken for the encryption? > - After connection the info (json: > > encrypted_connection_info[connection_username,connection_password,last_used_timestamp,saved_timestamp]) > is stored in new "gucamole_connection_credentials" - > encrypted_credentials > should then also contain the lifetime for the store. > - In case of a reconnect try with saved credentials the info from > gucamole_connection_credentials is checked and decrypted. if decryption > is > ok and credentials are still valid > > "timestamp_diff(now-saved_timestamp)<saved-connection-credentials-max-lifetime" > the connection is done without the password request. > > > - Extend DB: > - Table gucamole_connection_credentials > (user_id,connection_id,encrypted_connection_info) > - Extend Properties (Connection/User) > - allow-save-connection-credentials: true/false - default = true if > global option is true. > - saved-connection-credentials-max-lifetime: 1d - if not set global > default is used. > - Extend Properties (guacamole.conf) > - allow-save-connection-credentials: false/true - global activation > of feature. > - saved-connection-credentials-max-lifetime: 7d > > Hopefully you understand my idea and see the security improvement to > remove the cleartext credentials for the use case and our admin connections > from the DB. > Of course we can also outsource the connection password security to some > backend system (ldap, guacamole-vault, Retrieving secrets from a vault) - > but that adds a new complexity and administration-layer that is in my > option not really needed and also a big "todo" for migration hundreds of > connections. I think my idea also works without other > external-auth-systems, that can provide "connection-details" > I have many, many thoughts about this, many of which have been discussed in the past, but clearly you've thought through a possible solution quite a bit. I think the gist of my feedback comes down to this: Why re-invent the wheel? I realize that setting up a Vault application can require some amount of administrative overhead, but it doesn't have to - there are good options out there that are pretty easy to administer, that already integrate with other authentication systems (AD/LDAP, SAML, OpenID), that have well-documented APIs for interfacing with them, and that have already gone to the trouble of implementing secure credential storage and retrieval. I would rather put the development effort in Guacamole into expanding which Vaults are supported (HashiCorp Vault, 1Password, etc.) than try to rewrite all of the functionality contained in those systems. The only thing I think would be valuable, in keeping with the Jira issue above, is some sort of in-memory-only credential vault extension that allows the user to enter credentials once - maybe at login, maybe at the first connection - and have those credentials be re-used throughout the life of their session. Beyond that, I think the effort - both development-wise and administratively - is better spent integrating with the existing vaults. > Sorry for my bad English. > > Comments are welcome :-) > And I'm happy to have further discussion on this - above is my perspective and by no means the final word :-). The wonderful thing about Open Source projects like Guacamole is that whoever has time, skill, and the desire to write code can work on it and implement whatever they want to. -Nick
