How about a more general (and encrypted!) solution: Add a password decryption class to the YAML. If it is not defined, that means the passwords are not encrypted, if it is defined, use it to decrypt the passwords.
That way, you need to steal both the YAML and the decryption class if you want to steal the passwords. On Wed, Apr 27, 2011 at 1:56 PM, Sasha Dolgy <sdo...@gmail.com> 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 ? > > -sd > > > > On Wed, Apr 27, 2011 at 5:09 AM, David Strauss <da...@davidstrauss.net> > wrote: > > > > If the passwords are encrypted, when and how would they be decrypted? >
