accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ACCUMULO-4045) Proposal to improve the security of Accumulo's password-based logons
Date Thu, 29 Oct 2015 18:24:27 GMT

     [ https://issues.apache.org/jira/browse/ACCUMULO-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Christopher Tubbs updated ACCUMULO-4045:
----------------------------------------
    Description: 
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.

  was:
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:

1. Add a logon or "createSession" RPC method to effectively authenticate using a password
and create a session identifier for future use.
2. 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.
3. 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.
4. 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.


> 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)

Mime
View raw message