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 07AE56BB7 for ; Tue, 19 Jul 2011 20:59:49 +0000 (UTC) Received: (qmail 95133 invoked by uid 500); 19 Jul 2011 20:59:46 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 95034 invoked by uid 500); 19 Jul 2011 20:59:46 -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 95024 invoked by uid 99); 19 Jul 2011 20:59:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Jul 2011 20:59:46 +0000 X-ASF-Spam-Status: No, hits=2.6 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,TRACKER_ID,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of cassandralabs@gmail.com designates 209.85.210.172 as permitted sender) Received: from [209.85.210.172] (HELO mail-iy0-f172.google.com) (209.85.210.172) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Jul 2011 20:59:39 +0000 Received: by iye7 with SMTP id 7so4825027iye.31 for ; Tue, 19 Jul 2011 13:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RgV77CbiipUkCZqtrk8oDFrMwseU0usmzp5Gn9fBVQE=; b=Ll0rfzGPt2SSBzEvJ3g+ZJpPhrssBSuflDWvZH7rh7ike5Y5Nv+d3A6Yd0ki/JYxBO 5D+LTsoTKrRtrKYfMzzHrFOdQ1Ixwi5N0GC+vgr5mJ7yQAFVZKwXjwtbfbQiXwjTE2J5 9DgkcphtPsj94sz5r3S36CwvyD/gtIViKN0WE= MIME-Version: 1.0 Received: by 10.231.39.74 with SMTP id f10mr7353015ibe.199.1311109158236; Tue, 19 Jul 2011 13:59:18 -0700 (PDT) Received: by 10.231.3.83 with HTTP; Tue, 19 Jul 2011 13:59:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Jul 2011 13:59:18 -0700 Message-ID: Subject: Re: Is anyone actually seriously using SimpleAuthenticator and SimpleAuthority? From: Sameer Farooqui To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=00032557542aa3732904a87263f6 X-Virus-Checked: Checked by ClamAV on apache.org --00032557542aa3732904a87263f6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We studied SimpleAuthority a few months back out of curiosity and took some notes on it to eventually use it in the future. Somebody getting started with this might find the following helpful... - - - - - - The following discusses ways to configure security best practices for a Cassandra cluster running on Amazon EC2. It explores different security components which should all be used together to ensure a safe environment. We tested some of these features using a small Cassandra 0.8.0beta1 cluster= , since they were not available in 0.7.4. If the read or write client exists outside of the cluster, as it did in our case on Elastic Beanstalk, then the read/write client needs a safe way to authenticate to the cluster. Without authentication, anyone with the IP address of the cluster could potentially read or write to it. *+++ AllowAllAuthority +++* By default, Cassandra allows any client on the network to connect to the cluster and read/write data, which is a security risk. The security mechanism is pluggable, so the default authentication method ( org.apache.cassandra.auth.AllowAllAuthority) can be swapped out for another= , or a custom one can be written. During our prototype phase, we replacedthis default setting with the (slightly) more secure SimpleAuthority mechanism described in the next section. *+++ SimpleAuthority +++* In order to force clients, like the Elastic Beanstalk Hector read client, t= o provide credentials, SimpleAuthority should be used. In the Cassandra config directory, two files must be edited to use SimpleAuthority: 1) Access.properties: uses a key/value pair to specify which users are allowed access to which keyspaces, specified in a comma separated list, for example: Keyspace1=3Djdoe,John Smith, user5 2) Passwd.properties: contains a list of the users above and specifies the password for them, for example: jdoe=3Dlookatmypass John\ Smith=3Db3tterp@ass user5=3Dpassword After the two above files have been edited, we told Cassandra the location of the access and password files using the bin/cassandra.in.sh script. The file locations can be passed to the JVM by pasting code like the following at the bottom of the script file: JVM_OPTS=3D" -Dpasswd.properties=3D/home/ubuntu/apache-cassandra-0.8.0-beta1/con= f/passwd.properties \ -Daccess.properties=3D/home/ubuntu/apache-cassandra-0.8.0-beta1/conf/access= .properties" Next, the value for the authenticator element in cassandra.yaml must be replaced from org.apache.cassandra.auth.AllowAllAuthority to org.apache.cassandra.auth.SimpleAuthority. Now, when the client code in Hector connects to the cluster it can authenticate using a map with the username and password: Map AccessMap =3D new HashMap(); AccessMap.put("username", "jdoe"); AccessMap.put("password", "nosql"); Keyspace keyspace =3D HFactory.createKeyspace("MDR", cluster, new AllOneConsistencyLevelPolicy(), FailoverPolicy.ON_FAIL_TRY_ALL_AVAILABLE, AccessMap); One of the problems we noticed with this method is that Hector sends the password as plaintext to the cluster. We would need to think of a more secure way to sending the password when deployed in production. *MD5 Encryption with SimpleAuthority* SimpleAuthority has two modes for specifying the password: plain text and MD5 encrypted. The above examples use plain text passwords. To improve security, MD5 is highly encouraged. Message-Digest algorithm is a one-way hash function that generates a 128-bit hash value from an input. We enabled MD5 in the cassandra.in.sh file by passing the passwd.mode switc= h to the JVM: JVM_OPTS=3D" \ -da \ //other stuff... -Dpasswd.mode=3DMD5" A variety of tools and libraries can be used to generate an MD5-encrypted version of the plain-text username and password as a one-way hash. Here=92s= a short Python program: $ python Python 2.6.5 ... >>> from hashlib import md5 >>> p =3D "havebadpass" >>> h =3D md5(p).hexdigest() >>> print h e1a31eee2136eb73e8e47f9e9d13ab0d The encrypted output from the program for the username should be updated in the passwd.properties file with the encrypted value on all nodes. *More Secure Alternatives to MD5 Encryption* Note that US-CERT of the U. S. Department of Homeland Security said MD5 "should be considered cryptographically broken and unsuitable for further use=94, and SHA-2 family of hash functions is recommended. So, MD5 should n= ot be considered absolutely secure, but it does add a layer of security. Cassandra 0.7.4 does not have support for other encryption hashes out of th= e box, but by implementing the iAuthenticator interface, a custom one can be written. Jonathan Ellis, the apache Cassandra chair, recommends bcrypt over MD5 for = a secure has function: http://codahale.com/how-to-safely-store-a-password/ Ted Zlatanov, the Cassandra developer who implemented the MD5 SimpleAuthenticator encryption said on the user-mailing list: =93I used MD5 when I proposed SimpleAuthenticator for two reasons: 1) SimpleAuthenticator is supposed to be a demo of the authentication interface. It can be used for testing and trivial setups, but I wouldn't use it in production. So it's meant to get you going easily, not to serve you long-term. 2) MD5 is built into Java. At the time, bcrypt and SHA-* were not. I used MD5 only so the passwords are not stored in the clear, not to provide production-level security. You should consider carefully the implications of storing passwords in a file on a database server, no matter how they are encrypted. It would be better to write a trivial AD/LDAP/etc. authenticator that fits your specifi= c needs and doesn't rely on a local file.=94 On Tue, Jul 19, 2011 at 1:21 PM, Jonathan Ellis wrote: > See: https://issues.apache.org/jira/browse/CASSANDRA-2922 > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com > --00032557542aa3732904a87263f6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

We studied SimpleAuthority a few months back out of curiosity and took = some notes on it to eventually use it in the future.

Somebody gettin= g started with this might find the following helpful...

- - - - - - =
The following discusses ways to configure security best practices for a Cas= sandra cluster running on Amazon EC2. It explores different security compon= ents which should all be used together to ensure a safe environment. We tes= ted some of these features using a small Cassandra 0.8.0beta1 cluster, sinc= e they were not available in 0.7.4.

If the read or write client exists outside of the cluster, as it did in= our case on Elastic Beanstalk, then the read/write client needs a safe way= to authenticate to the cluster. Without authentication, anyone with the IP= address of the cluster could potentially read or write to it.

+++ AllowAllAuthority +++

By default, Cassandra allows any client on the net= work to connect to the cluster and read/write data, which is a security risk. The security mechanism is pluggable, so the default authentication method (org= .apache.cassandra.auth.AllowAllAuthority) can be swapped out for another, or a custom one can be written= .

During our prototype phase, we replacedthis default setting with the (s= lightly) more secure SimpleAuthority mechanism described in the next sectio= n.

=A0
+++ SimpleAuthority +++

In order to force cl= ients, like the Elastic Beanstalk Hector read client, to provide credential= s, SimpleAuthority should be used.


In the Cassandra config directory, two files must be edited to use SimpleAuthority:

=A0

1)=A0=A0=A0 Access.properties: uses a key/value pair to specify which users are allowed access to which keyspaces= , specified in a comma separated list, for example:

=A0

Keyspace1=3Djdoe,John Smith, user5

=A0

2)=A0=A0=A0 Passwd.properties: contains a list of the users above and specifies the password for them, for example:=

jdoe=3Dlookatmypass

John\ Smith=3Db3tterp@ass

user5=3Dpassword

=A0

After the two above files have been edited= , we told Cassandra the location of the access and password files using the bin/cassandra.in.sh script. The file= locations can be passed to the JVM by pasting code like the following at the bottom of the script file:

=A0

JVM_OPTS=3D"

=A0=A0=A0=A0=A0=A0=A0 -Dpasswd.properties=3D/home/ubuntu/apache-cassandra-0.8.0-beta1/conf= /passwd.properties \

=A0=A0=A0 =A0=A0=A0=A0-Dac= cess.properties=3D/home/ubuntu/apache-cassandra-0.8.0-beta1/conf/access.pro= perties"

=A0

Next, the value for the authentica= tor element in cassandra.yaml must be replaced from org.apache.cassandra.auth.Allow= AllAuthority to org.ap= ache.cassandra.auth.SimpleAuthority.

=A0

Now, when the client code in Hector connects to the cluster it can authenticate using= a map with the username and password:

=A0

Map AccessMap =3D new HashMap();

AccessMap.put("username", "jdoe");

AccessMap.put("password", "nosql");

=A0

Keyspace keyspace =3D HFactory.createKeyspace("MDR", cluster, new

AllOneConsistencyLevelPolicy(),

FailoverPolicy.ON_FAIL_TRY_ALL_AVAILABLE, AccessMap);

=A0

One of the problems we noticed with this method is that Hector sends the password = as plaintext to the cluster. We would need to think of a more secure way to sending the password when deployed in production.

=A0

MD5 Encryption with SimpleAuthorit= y

SimpleAuthority has two modes for specifyi= ng the password: plain text and MD5 encrypted. The above examples use plain text passwords. To improve security, MD5 is highly encouraged. Message-Digest algorithm is a one-way hash function that generates a 128-bit hash value fr= om an input.

=A0

We enabled MD5 in the cassandra.in.sh= file by passing the passwd.mode switch to the JVM:

=A0

JVM_OPTS=3D" \

=A0=A0=A0=A0=A0=A0=A0 -da= \

//other stuff...

=A0=A0=A0=A0=A0=A0=A0 -Dp= asswd.mode=3DMD5"

=A0

A variety of tools and libraries can be us= ed to generate an MD5-encrypted version of the plain-text username and passwor= d as a one-way hash. Here=92s a short Python program:

=A0

$ python

Python 2.6.5 ...

>>> from hashlib import md5

>>> p =3D "havebadpass"

>>> h =3D md5(p).hexdigest()

>>> print h

e1a31eee2136eb73e8e47f9e9d13ab0d

=A0

The encrypted output from the program for = the username should be updated in the passwd.properties file with the encrypted value on a= ll nodes.

=A0

M= ore Secure Alternatives to MD5 Encryption

Note that US-CERT of the U. S. Department = of Homeland Security said MD5 "should be considered cryptographically bro= ken and unsuitable for further use=94, and SHA-2 family of hash functions is recommended. So, MD5 should not be considered absolutely secure, but it doe= s add a layer of security.

=A0

Cassandra 0.7.4 does not have support for = other encryption hashes out of the box, but by implementing the iAuthenticator interface, a custom one can be written.

=A0

Jonathan Ellis, the apache Cassandra chair= , recommends bcrypt over MD5 for a secure has function:

http://codahale.com/how-to-safely-store-a-password/

=A0

T= ed Zlatanov, the Cassandra developer who implemented the MD5 SimpleAuthenticator encrypt= ion said on the user-mailing list:

<= span class=3D"apple-style-span">=A0

<= span class=3D"apple-style-span">=93I used MD5 when I proposed SimpleAuthenticator for tw= o reasons:

1) SimpleAuthenticator is supposed to be a= demo of the authentication interface. =A0It can be used for testing and trivial setups, but I wouldn't use it in production. =A0So it's meant to ge= t you going easily, not to serve you long-term.

2) MD5 is built into Java. =A0At the time, bcrypt and SHA-* were not. =A0I used MD5 only so the passwords are not stored in the clear, not to provide production-level security.

You should consider carefully the implicat= ions of storing passwords in a file on a database server, no matter how they are encrypted. =A0It would be better to write a trivial AD/LDAP/etc. authenticator that fits your specific needs and doesn't rely on a local= file.=94



On Tue, Jul 19, 2011 at 1:21 PM, Jonatha= n Ellis <jbellis@= gmail.com> wrote:
See: https://issues.apache.org/jira/browse/CASSANDRA-2922

--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.c= om

--00032557542aa3732904a87263f6--