Internally stored passwords

Hyper-Converged Database (HCD) uses HCD Authenticator to validate user identity against all supported authentication schemes: Internal and LDAP. The internal authentication scheme stores credentials for a role internally as a hashed password.

HCD uses the cassandra.yaml configuration settings to set up authentication schemes during initialization. Preconfigure the authenticator.parameters.enabled settings to true, toggling from the default of false. Ensure the authenticator.parameters.default_scheme is set to internal, which is the default. See Enable HCD authentication.

AdvancedAuthenticator is the default in the cassandra.yaml configuration file.

Each user account stored in HCD is a role with a login and password. The password is stored as a hash. See add database users.

For example, the following command shows how a password is stored for the default cassandra role:

SELECT * FROM system_auth.roles WHERE role = 'cassandra';

Result

 role      | can_login | is_superuser | member_of | salted_hash
-----------+-----------+--------------+-----------+--------------------------------------------------------------
 cassandra |      True |         True |      null | $2x$10$XXXXXxx2XxX6Xx532.8xX.xXxXxXxXX5xxxXXxOX3Xx1XxXX3xXX

The password hash uses a random salt to guarantee the password for each user is different. For example, if you create a user with a test2 role using the same password string as the cassandra role, they will have different salted hashes:

SELECT * FROM system_auth.roles;

Result

 role      | can_login | is_superuser | member_of | salted_hash
-----------+-----------+--------------+-----------+--------------------------------------------------------------
test2      |      True |        False |      null | $2z$10$zzZzZ2zZZZz49zZZZzzZZzz4O/Z8Z4zzzzzzZZZZZzZZZZ22zzzZz
 cassandra |      True |         True |      null | $2x$10$XXXXXxx2XxX6Xx532.8xX.xXxXxXxXX5xxxXXxOX3Xx1XxXX3xXX

Internally stored passwords

Was this helpful?

Give Feedback