[
https://issues.apache.org/jira/browse/GUACAMOLE-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17693684#comment-17693684
]
Matteo Kloiber commented on GUACAMOLE-1743:
-------------------------------------------
Hey thanks for your thoughts and taking the time to write such a thorough
response.
Regarding 1)
I don’t see a benefit regarding that approach because, for a home setup, using
LDAP or a database, might be pretty overkill. I’m the only user and I’m not
adding many services, so there is no need to have a database when a config file
suffices.
2)
I already have that, but I still don’t like the idea of having a password in
essential plaintext (for passwords, hash tables are too advanced already so
that any unsalted hashing algorithm is insecure by design). It will also be
present in backups, etc. I also don’t plan to use a unique password as one
reason to use guacamole is to access my PC from trusted PCs that might not have
my password manager installed. (I’m not using my master password or my email
password but I still use that password for a few other things).
I’d like to give implementing it a crack, the source code seems to be quite
straight forward. Could you give me input on which “format” you prefer?
Extending the XML parser to have a field for salt, key length, and
interactions, or encoding this information inside the password. Encoding it
inside the password might be more advantageous as adding different algorithms
might be easier in the future but using a dedicated Schema makes it self
documenting.
> Add support for more secure hasing alogirthms in user-mapping.xml
> -----------------------------------------------------------------
>
> Key: GUACAMOLE-1743
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1743
> Project: Guacamole
> Issue Type: Improvement
> Reporter: Matteo Kloiber
> Priority: Trivial
>
> Currently only SHA-256 and md5 is supported in user-mapping.xml. Both
> algorithms are very vulnerable to hash table attacks as no salt or similiar
> mechanics are used.
>
> This is a problem for home lab settups as this method is not much better than
> leaving leaking the plaintext password in a configuration file.
> I was thinking that using a hashing algorithms such as Argon2 or pbkdf2.
> Although I believe argo2 is better, pbkdf2 might be preferable as it's
> already in the standard library. Another problem is that both algorithms need
> more parameter than just the hash, such as the salt and the number of
> iterations. So an encoding for the password parameter might be easier than
> creating more parameter just for this algorithm.
>
> For example, with the password test, one might encode it like this:
> <authorize username="matt3o12"
> password="128:1000:HCgQ/crR+Ed3m5zAzcEk7w==:pzozvnzyXuz40RjCTbHv1A=="
> encoding="PBKDF2WithHmacSHA256">
>
> The encoding is dkLen:iterations:salt:password
>
> What are your thoughts about this? How should the additional parameters be
> encoded? Part of the password or maybe with additional XML parameters.
> I think having good password hashing is really important, especially for home
> lab setups, where other login algorithms are overkill.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
