On Mon, Jun 30, 2025 at 7:27 AM Tobias Feller | OPC <[email protected]> wrote:
> Hi Nick, > > Thanks for your reply! > > Because of. > > > *This has already been put in as a feature request: > https://issues.apache.org/jira/browse/GUACAMOLE-1428 > <https://issues.apache.org/jira/browse/GUACAMOLE-1428>* > and the effort for such a change. > > I think GUACAMOLE-1428 this is something different. Because here (you are > right) it goes to the direction "global credential vault". My main concern > is only to encrypt the passwords and save it encrypted for the > user+connection in the the db. > The issue of encrypting passwords as stored in the DB has come up quite a bit. My general feeling on this is that the passwords would have to be stored in the database in a reversible mode, where it can be read by the application, and if a user can get to the point of administering connections, they can probably get to the point of uncovering the encryption keys used to store the passwords. So, this really just becomes "Security by Obscurity" and provides little real benefit. The other option - and one you mention below - would be to use the user's Guacamole credentials - or something else that the user has - to encrypt the stored credentials, but then you run into a couple of more issues: * It's still reversible/attackable, if you get the user's credentials. And, if you're just using JDBC for authentication (no external system), then the keys to all of those encrypted passwords are really right there in the database. * Many organizations enforce password rotation (which is a completely separate debate), and you'd have to have a way to update the encryption as soon as the user's password changes. If this is done completely in Guacamole then you can do that when the user changes their password, but an external authentication system (LDAP) would require something else (please enter your previous password...). The various key vaults that I mentioned before are much more sophisticated pieces of software capable of handling a lot of these concerns, and it's why I believe that the effort should go into beefing up support for those rather than writing all of that capability into Guacamole. > > If my guess is right (because of the existence of "${GUAC_PASSWORD}" as > token) the password is already in the tomcat/servlet-memory. So it should > be easy to add a new table with the enrypted info. > > In the simplest form it would be enough to have a property for the > connection "can save password". After that each user have to option to save > it after he checked the "Save for future use" checkbox in the Password > request dialog on connection startup. > > Because the encryption relies on the guacamole login-user, login-passwort > and connection_id (maybe in case of external auth on something other > trusted non-detectable data) only the same user can decrypt it after login > for the connection. The webapp itself can do on next connection by himself > if all the encryption key input is there for the webapp-user-session. > What happens when the user's password changes? > I also don't see why it should than be limited for the > guacamole-user-session because as long as the "key-input" not changes (for > example user - password). The plain text-password for the connection is > still decryptable. If the decryption fails, connenction fails -> clear the > record user+connection_id in the table and - we are at that point that were > we are today -> no fixed password in connection -> the user see the > (username/)password request. Than it is up to the user where he can get the > (new/current) connection password. Also a nice simple benefit in my opinion > for a group of support-users that use the same connection. > > The team-password vault in our case (vaultwarden) decide if he have access > to the the connection password and so also to establish the connection. > > Maybe i start to try myself on the source-code in my free time. Are there > any infos how to setup a dev environment for guacamole, for a java newbie > ;-) - eclipse? > If you are so inclined, feel free to - as I mentioned before, that's the great thing about open source projects :-). As far as how to set up a new dev environment - it kind of depends on how complicated you want to go. For a simple setup, Eclipse or NetBeans (another ASF project!) is fine. You'll also need a Java JDK of some sort, Apache Maven to build the project, and then Tomcat to run it. Lately I've been playing with K8s (Openshift/OKD, actually), and working on getting Eclipse Che (with VSCode Web) set up, there, along with Jenkins to perform automated builds, Gitlab for source code management (including mirroring Github), and the Openshift Container Registry to running containers. It's a lot more complicated to get going, but hopefully it'll streamline some of the "code-build-test" loop for me. > Is it possible to do it via an extension? > - Add the checkbox in the password - request-dialog before connect - i > think so a far as i read the ( > https://guacamole.apache.org/doc/gug/guacamole-ext.html) > - Add a new option to the connection-edit-page and save it to > "guacamole_connection_parameter" > - Is it possible create a new table > "gucamole_connection_saved_credentials"? > - Is it possible to extend the process between connection - start - > "click" and the the decisions from where the password / connection data is > requested and ca they be manipulated? > I _think_ most of it is possible, although modifying *how* things get stored in the database might require modifying the guacamole-auth-jdbc module directly - that is, if your goal is to somehow eliminate the storing of plaintext data in the password field, you're going to have to either find a way to translate it out dynamically, or you're going to have to change how the module is stored. And, yes, you could create a new table; however, if you do this you either have to modify the JDBC module to look at that table, or your extension has to do all of the JDBC plumbing to access that the database, table, etc. > Maybe a "token-get-event" would be a good addition in the extension > concept? So if "${GUAC_PASSWORD}" is requested the callback get the actual > token-value + connection_id + user_id and then it can override the token > data / connection-properties. In this case the connection password will be > overridden with the decrypted password from > gucamole_connection_saved_credentials. > Perhaps so - I'll be very interested to see what you come up with. Feel free to post back as you progress or if you have any questions - apologies for the LONG delay in replying to this. -Nick >
