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 ...
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"
Sorry for my bad English.
Comments are welcome :-)
Best regards,
Tobias
