incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Strauss <>
Subject Re: encryption_options & 0.8
Date Wed, 27 Apr 2011 18:41:08 GMT
On Wed, 2011-04-27 at 12:56 +0200, Sasha Dolgy wrote:
> "IBM WebSphere applies a hardcoded XOR. Each caracter is XOR'd with
> the caracter ‘_’, and the resulting string is encoded in base64. This
> is not cryptography, it is just enough encoding so that a casual
> glance at the file will not reveal the password."
> I'm sure there are many different options.  Key point here is the
> 'casual glance' reference.  In terms of adding additional overhead
> when a node starts up ... it shouldn't be that prohibitive.  when the
> cassandra.yaml is loaded in and the "encryption_properties", if
> keystore_password.clear or truststore_password.clear exists, rewrite
> these properties in the yaml to the encrypted values of the cleartext
> string, removing the ".clear" suffix and continue on as normal.  the
> default within cassandra should be looking at decrypting an encrypted
> value.  if the decrypted values are wrong, throw an error as you would
> normally ...
> Yes, all of this can be circumvented if the cassandra.yaml is set to
> read only for user and no one else, but really ... do i want anyone in
> our organization who may have access to restart a cassandra node, but
> may not be privileged to know what the keystore / truststore passwords
> are to easily find out by looking at the cassandra.yaml ?

As I suspected, you want the passwords "encrypted" but not in a way that
would hamper the ability for the nodes to independently start themselves
or require actual key management. (The reason I suspected this is
because you didn't seem willing to just not give Cassandra the keystore
and truststore passwords.) That, my friend, is no additional security at

View raw message