Hi Nick, right – we need to differentiate between passwords for user authentication (and potentially pass-thru) and passwords part of connection configuration. Passwords in connection configuration must be decryptable, but as the key is also some configuration you can argue whether the encryption adds security.
But why are user passwords encrypted rather than using a one-way-function? Actually I am not affected at all as I am using my own extension with zero persistence. Best Regards, Joachim Von: Nick Couchman <vn...@apache.org> Gesendet: Friday, 17 July 2020 17:27 An: user@guacamole.apache.org Betreff: Re: securing connection passwords On Fri, Jul 17, 2020 at 11:09 AM Joachim Lindenberg <joac...@lindenberg.one <mailto:joac...@lindenberg.one> > wrote: >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. -Nick
