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/
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.
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.
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?
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?
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.
Nice week to you.
Tobias
Am 27.06.2025 um 16:46 schrieb Nick Couchman:
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
o 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?
o 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.
o 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:
o Table gucamole_connection_credentials
(user_id,connection_id,encrypted_connection_info)
* Extend Properties (Connection/User)
o allow-save-connection-credentials: true/false - default =
true if global option is true.
o saved-connection-credentials-max-lifetime: 1d - if not set
global default is used.
* Extend Properties (guacamole.conf)
o allow-save-connection-credentials: false/true - global
activation of feature.
o 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
