incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Strauss <da...@davidstrauss.net>
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
all.

Mime
View raw message