[ 
https://issues.apache.org/jira/browse/GUACAMOLE-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532771#comment-17532771
 ] 

Nick Couchman commented on GUACAMOLE-1599:
------------------------------------------

There are two pieces of the answer to this:
1) As you stated, access to this data requires access to the database, and the 
database should be protected as something that contains sensitive data.
2) Any method of hashing/encryption of that data would require that the key for 
decryption be kept somewhere on the server where Guacamole is installed. If 
someone gets access to the database, presumably they also have access to the 
server running Guacamole Client, and would be able to retrieve the key for 
decryption. This makes the value-add for encrypting that data within the 
database pretty low.

> Storage of TOTP secrets unhashed
> --------------------------------
>
>                 Key: GUACAMOLE-1599
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-1599
>             Project: Guacamole
>          Issue Type: Bug
>          Components: guacamole-auth-totp
>    Affects Versions: 1.3.0
>         Environment: Ubuntu 20.04
>            Reporter: Andy Franks
>            Priority: Minor
>
> Hi
> Successfully campaigned for the use of guacamole in the large public sector 
> organisation I work at. A security-conscious colleague has noticed that 
> apparently the TOTP codes for users are stored in the 
> guacamole_user_attribute table in plain text - and presumably could be 
> trivially copied to a TOTP utility and the codes generated.
> I pointed out that the user security part is salted and hashed, and you'd 
> need both to log in, but the colleague is not appeased.
> Perhaps not a bug as such but possibly a spanner in the works of keeping the 
> adoption of the software, which would be a big shame. Is there an official 
> explanation (e.g. that it's simply not required as you'd need to get into the 
> database first, the security is implicit there etc)? Or is it a future 
> planned change?
> Thank you



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Reply via email to