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.
signature.asc
Description: This is a digitally signed message part
