Hello all, I have been thinking about the issue a little.
Afai understand using a key vault implies a user (assuming we talk about user specific credentials rather than connection specific) has to deposit and then change his/her password in two locations consistently: the active directory (as RDP usually authenticates against that) plus the new key vault. It is not unlikely that a user will forget and lock out himself/herself., calling for additional support. Imho it is also questionable that the key vault worsens your security properties as it has reversable encryption compared to the active directory using one way functions. A better approach would be to leverage a “token to ticket” service that takes whatever authentication token, validates it, and then obtains a Kerberos ticket for RDP. Googling around I came across https://directory.apache.org/kerby/ which probably solves part of the scenario via “Supports Token Preauth mechanism to allow clients to request tickets using JWT tokens.". But I assume one would also have to modify FreeRDP to support a different authentication mechanism (e.g. pass in a service ticket). Best Regards, Joachim Von: Marcel Pruijn <[email protected]> Gesendet: Monday, 20 July 2020 07:40 An: [email protected] Betreff: Re: securing connection passwords Looking forward to the suggested solutions with the key vaults and prompt support. I hope these solutions will work with other extensions that support openid and saml Great work guys! Kind regards, Marcel Op vr 17 jul. 2020 om 20:45 schreef Joachim Lindenberg <[email protected] <mailto:[email protected]> >: 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 <[email protected] <mailto:[email protected]> > Gesendet: Friday, 17 July 2020 17:27 An: [email protected] <mailto:[email protected]> Betreff: Re: securing connection passwords On Fri, Jul 17, 2020 at 11:09 AM Joachim Lindenberg <[email protected] <mailto:[email protected]> > 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
