Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7EE682954 for ; Wed, 27 Apr 2011 11:21:04 +0000 (UTC) Received: (qmail 80901 invoked by uid 500); 27 Apr 2011 11:21:02 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 80872 invoked by uid 500); 27 Apr 2011 11:21:02 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 80864 invoked by uid 99); 27 Apr 2011 11:21:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Apr 2011 11:21:02 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.215.172] (HELO mail-ey0-f172.google.com) (209.85.215.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Apr 2011 11:20:53 +0000 Received: by eye13 with SMTP id 13so593413eye.31 for ; Wed, 27 Apr 2011 04:20:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.126.73 with SMTP id a49mr894901eei.178.1303903232529; Wed, 27 Apr 2011 04:20:32 -0700 (PDT) Sender: david@daotown.com Received: by 10.14.37.79 with HTTP; Wed, 27 Apr 2011 04:20:32 -0700 (PDT) X-Originating-IP: [62.90.201.82] In-Reply-To: References: <1303873785.10067.42.camel@titan> Date: Wed, 27 Apr 2011 14:20:32 +0300 X-Google-Sender-Auth: 6jcgNS90ug_jvXWszIzr53ZOoyE Message-ID: Subject: Re: encryption_options & 0.8 From: David Boxenhorn To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=e0cb4e6ffac3ff15a304a1e4a0d9 X-Virus-Checked: Checked by ClamAV on apache.org --e0cb4e6ffac3ff15a304a1e4a0d9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable How about a more general (and encrypted!) solution: Add a password decryption class to the YAML. If it is not defined, that means the password= s 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 wrote: > "IBM WebSphere applies a hardcoded XOR. Each caracter is XOR'd with > the caracter =91_=92, 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 > wrote: > > > > If the passwords are encrypted, when and how would they be decrypted? > --e0cb4e6ffac3ff15a304a1e4a0d9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
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 passw= ords.

That way, you need to steal both the YAML and the decryption class if y= ou want to steal the passwords.

On Wed, = Apr 27, 2011 at 1:56 PM, Sasha Dolgy <sdolgy@gmail.com> wrote:
"IBM WebSphe= re applies a hardcoded XOR. Each caracter is XOR'd with
the caracter =91_=92, 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. =A0Key point here is the
'casual glance' reference. =A0In terms of adding additional overhea= d
when a node starts up ... it shouldn't be that prohibitive. =A0when 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. = =A0the
default within cassandra should be looking at decrypting an encrypted
value. =A0if 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 <david@davidstrauss.net> wrote:
>
> If the passwords are encrypted= , when and how would they be decrypted?

--e0cb4e6ffac3ff15a304a1e4a0d9--