incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sameer Farooqui <>
Subject Re: Is anyone actually seriously using SimpleAuthenticator and SimpleAuthority?
Date Tue, 19 Jul 2011 20:59:18 GMT
We studied SimpleAuthority a few months back out of curiosity and took some
notes on it to eventually use it in the future.

Somebody getting started with this might find the following helpful...

- - - - - -
The following discusses ways to configure security best practices for a
Cassandra cluster running on Amazon EC2. It explores different security
components which should all be used together to ensure a safe environment.
We tested some of these features using a small Cassandra 0.8.0beta1 cluster,
since they were not available in 0.7.4.

If the read or write client exists outside of the cluster, as it did in our
case on Elastic Beanstalk, then the read/write client needs a safe way to
authenticate to the cluster. Without authentication, anyone with the IP
address of the cluster could potentially read or write to it.

*+++ AllowAllAuthority +++*

By default, Cassandra allows any client on the network to connect to the
cluster and read/write data, which is a security risk. The security
mechanism is pluggable, so the default authentication method (
org.apache.cassandra.auth.AllowAllAuthority) can be swapped out for another,
or a custom one can be written.

During our prototype phase, we replacedthis default setting with the
(slightly) more secure SimpleAuthority mechanism described in the next

*+++ SimpleAuthority +++*

In order to force clients, like the Elastic Beanstalk Hector read client, to
provide credentials, SimpleAuthority should be used.

In the Cassandra config directory, two files must be edited to use

1) uses a key/value pair to specify which users are
allowed access to which keyspaces, specified in a comma separated list, for

Keyspace1=jdoe,John Smith, user5

2) contains a list of the users above and specifies
the password for them, for example:


John\ Smith=b3tterp@ass


After the two above files have been edited, we told Cassandra the location
of the access and password files using the bin/ script. The
file locations can be passed to the JVM by pasting code like the following
at the bottom of the script file:


Next, the value for the authenticator element in cassandra.yaml must be
replaced from org.apache.cassandra.auth.AllowAllAuthority to

Now, when the client code in Hector connects to the cluster it can
authenticate using a map with the username and password:

Map AccessMap = new HashMap();

AccessMap.put("username", "jdoe");

AccessMap.put("password", "nosql");

Keyspace keyspace = HFactory.createKeyspace("MDR", cluster, new


FailoverPolicy.ON_FAIL_TRY_ALL_AVAILABLE, AccessMap);

One of the problems we noticed with this method is that Hector sends the
password as plaintext to the cluster. We would need to think of a more
secure way to sending the password when deployed in production.

*MD5 Encryption with SimpleAuthority*

SimpleAuthority has two modes for specifying the password: plain text and
MD5 encrypted. The above examples use plain text passwords. To improve
security, MD5 is highly encouraged. Message-Digest algorithm is a one-way
hash function that generates a 128-bit hash value from an input.

We enabled MD5 in the file by passing the passwd.mode switch
to the JVM:


        -da \

//other stuff...


A variety of tools and libraries can be used to generate an MD5-encrypted
version of the plain-text username and password as a one-way hash. Here’s a
short Python program:

$ python

Python 2.6.5 ...

>>> from hashlib import md5

>>> p = "havebadpass"

>>> h = md5(p).hexdigest()

>>> print h


The encrypted output from the program for the username should be updated in
the file with the encrypted value on all nodes.

*More Secure Alternatives to MD5 Encryption*

Note that US-CERT of the U. S. Department of Homeland Security said MD5
"should be considered cryptographically broken and unsuitable for further
use”, and SHA-2 family of hash functions is recommended. So, MD5 should not
be considered absolutely secure, but it does add a layer of security.

Cassandra 0.7.4 does not have support for other encryption hashes out of the
box, but by implementing the iAuthenticator interface, a custom one can be

Jonathan Ellis, the apache Cassandra chair, recommends bcrypt over MD5 for a
secure has function:

Ted Zlatanov, the Cassandra developer who implemented the MD5
SimpleAuthenticator encryption said on the user-mailing list:

“I used MD5 when I proposed SimpleAuthenticator for two reasons:

1) SimpleAuthenticator is supposed to be a demo of the authentication
interface.  It can be used for testing and trivial setups, but I wouldn't
use it in production.  So it's meant to get you going easily, not to serve
you long-term.

2) MD5 is built into Java.  At the time, bcrypt and SHA-* were not.  I used
MD5 only so the passwords are not stored in the clear, not to provide
production-level security.

You should consider carefully the implications of storing passwords in a
file on a database server, no matter how they are encrypted.  It would be
better to write a trivial AD/LDAP/etc. authenticator that fits your specific
needs and doesn't rely on a local file.”

On Tue, Jul 19, 2011 at 1:21 PM, Jonathan Ellis <> wrote:

> See:
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support

View raw message