Client-side password hashing
Image credit: Jan Baborák on Unsplash

Apache Cassandra, just like any other database, needs users to connect. This means using a login and a password which up until recently would be provided as plain text.

This has the potential to create security concerns as, for instance, audit logging could store the credentials in plain text. This problem also applied to any other system in Cassandra that might log data, bearing in mind that Apache Cassandra is an open source project and, therefore, it does not control all possible forks and implementations and what and how data is logged.

The solution was to sanitize any logging for sensitive information, and this has been addressed recently. But that still left the door open to some corner cases where the detection or removal of such sensitive information could fail. There are also specific use cases, services and applications that might need to store a user’s credentials and up until 4.1, they would be storing that in plain text as well.

To strengthen security, we wanted to avoid the use of plain-text credentials altogether, so CASSANDRA-17334 and the release of Apache Cassandra 4.1 will add the option to use client-side password hashes.

New Hash Password Tool

This feature introduces a new tool called tools/bin/hash_password. Here is an example:

$ tools/bin/hash_password -p mySecret
$2a$10$F5pRau9mKg5abP.DsuPQl.8rQpEoNm3OV91mKjb9vdKPUPejIPq/u

The tool is quite self-explanatory. It takes your plain-text secret and provides a jBCrypt hash that can be used in the DDL commands, e.g., to create or alter users/roles. For the moment only a Java version is available.

Example Usage of Hash_Password

Let’s look at some examples of how we’d use the tool.

Plain option:

CREATE ROLE role1
    WITH LOGIN = true
    AND PASSWORD = 'mySecret';

New hashed option:

CREATE ROLE role1
    WITH LOGIN = true
    AND HASHED PASSWORD ‘$2a$10$F5pRau9mKg5abP.DsuPQl.8rQpEoNm3OV91mKjb9vdKPUPejIPq/u’;

As you can see we’re building the CQL with the hashed value of the password directly, i.e., this enables our applications to store the hash instead of the plain-text password. Also, any intermediate or third-party systems, additional logging or storing will deal with the hashes so the risk of accidental plain-text passwords leak is removed.

The same applies to ALTER statements.

Plain option:

ALTER ROLE role1
    WITH PASSWORD = '%s'

New hashed option:

ALTER ROLE role1
    WITH HASHED PASSWORD = '%s'

Backward Compatibility

This feature is backward compatible so it will also work for CREATE/ALTER USER statements. On occasions where the built-in password obfuscation fails when logging data, this feature will only reveal the hash instead of the plain-text password.

Stay tuned for upcoming further security enhancements, such as CASSANDRA-17501.