[
https://issues.apache.org/jira/browse/ACCUMULO-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14992142#comment-14992142
]
Christopher Tubbs commented on ACCUMULO-4045:
---------------------------------------------
I failed to point this out before, but one thing to note about step 4 in the
JIRA description is that this enables an altered client to authenticate as a
user with only a copy of the user's hashed password, without their actual
(pre-hashed) password. This results in a trade-off between security over the
wire, and security of credentials in the event of a compromise of ZooKeeper (or
wherever the hashed passwords are stored).
The idea of hashing the hashed password was just a suggested naive approach.
Perhaps there's a better implementation, though... I can do a bit of research
on that.
> Proposal to improve the security of Accumulo's password-based logons
> --------------------------------------------------------------------
>
> Key: ACCUMULO-4045
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4045
> Project: Accumulo
> Issue Type: Improvement
> Reporter: Christopher Tubbs
>
> There are some things we can do to improve the password-based authentication
> to Accumulo without adding much overhead or introducing new APIs or RPCs.
> Of course, strong authentication using SASL or TLS is preferred, but those
> may not be feasible for all users, and as long as we continue to support
> using Accumulo without requiring these protocols, we should also consider
> ways to improve the simple password authentication mechanism.
> So, with that in mind, I suggest:
> # Add a logon or "createSession" RPC method to effectively authenticate using
> a password and create a session identifier for future use.
> # A flag on Connector to use a session, could be added, and Connector could
> be made AutoCloseable, or another API could be added to clean up sessions.
> Sessions could also be made expirable.
> # When a session is created, the session information is stored in ZooKeeper,
> and used to authenticate a user in lieu of a password on future RPC requests.
> The RPC data will be able to distinguish whether it is of the session type or
> regular password type, for compatibility. But, mostly session data would work
> just like passwords do today, with a simple compare/check.
> # To create a session, the server (any server which can currently do
> authentication) receives a logon/createSession request, and responds with the
> user's salt, hash method, and a nonce. The client hashes the password using
> the salt and hash method, to reproduce the hashed version which the server
> already has. It then hashes again with the nonce and sends the result back to
> the server. The server then compares this result with the result of its own
> hashing of its stored value with the same nonce it sent to the client. If it
> matches, a session is created, stored in ZooKeeper and returned.
> Now, this is certainly not a perfect solution, but it could be a way we can
> provide some significant additional protection for password-based
> authentication without any of the additional security/authentication
> mechanisms enabled for Accumulo, and with low overhead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
