guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Couchman <>
Subject Re: securing connection passwords
Date Fri, 17 Jul 2020 15:27:10 GMT
On Fri, Jul 17, 2020 at 11:09 AM Joachim Lindenberg <>

> >Guacamole need to know the password at connection time (in clear-text)
> True.
> > Even if the password is encrypted in the DB, it must be decryptable...
> False (in general)
> The user needs to enter the password anyway, thus it can be used to
> validate against salted/hashed/whatever version of password in database
> while also passing it in clear text to guacd (e.g. as password for RDP
> connection).
> You only need to have a decryptable version if you use some other
> authentication (e.g. certificates) and need the clear text password to
> establish the connection.
> Best Regards,
> Joachim
We need to be clear about which passwords we're talking about, here.  For
user accounts stored in the database so that users can log in to Guacamole,
the passwords are already AES256 encrypted and salted.  You can see this if
you look at the database.

For password for specific connections, they are stored in plain-text, and
they absolutely do need to be decrypt-able - these passwords will not
always match the user who is logging in, the user won't always know the
passwords for the connections, and they won't necessarily be entering them
directly when making a connection.  Thus, they do have to be stored in some
format which can be reversed into the plain-text password that can be sent
along to the remote connection.  Encrypting these within the database
itself does not make a lot of sense, unless you somehow tie that encryption
to something that only a user logging in has (the user password, a
certificate, etc.).  However, if you do that, you have to come up with a
way to manage that encryption over time - that is, if the user changes
their password, you have to be able to rotate that encryption to match the
new password.  Also, you run into issues if multiple users are going to be
sharing a connection, because the password then has to either be stored
with an encryption key that can be shared, or has to be stored multiple
times for each user...

...which brings us to the real solution, which is support for credential
vaults.  Mike has already started working on this - there's a pull request
out there to support the Azure Key Vault - and that should be able to
extend to other similar credential vaults in a way that allows these types
of services to be leveraged.  Whether it's an external server or
implementing some sort of internal credential storage, this, combined with
the Prompt support that is on the way, are really the ways to deal with
storing and accessing connection passwords, and not a sort of make-shift
solution that would store the passwords with completely reversible
encryption or hashing within the database.


View raw message