[GitHub] [cassandra-website] ErickRamirezAU commented on a diff in pull request #133: CASSANDRA-17657 May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password Hashing"

[GitBox <gi...@apache.org>]

ErickRamirezAU commented on code in PR #133:
URL: https://github.com/apache/cassandra-website/pull/133#discussion_r881427192


##########
site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.adoc:
##########
@@ -0,0 +1,59 @@
+= Apache Cassandra 4.1 Features: Client-side Password Hashing
+:page-layout: single-post
+:page-role: blog-post
+:page-post-date: May, 26 2022
+:page-post-author: Berenguer Blasi
+:description: Client-side password hashing in Apache Cassandra 4.1
+:keywords:
+
+:!figure-caption:
+
+.Image credit: https://unsplash.com/@janbaborak[Jan Baborák on Unsplash^]
+image::blog/apache-cassandra-4.1-features-client-side-password-hashing-unsplash-jan-baborak.jpg[Client-side password hashing]
+
+Apache Cassandra, just like any other database, needs users to connect. This means using a login and a password which up until recently would be provided as plain text.
+
+This has the potential to create security concerns as, for instance, audit logging could store the credentials in plain text. This problem also applied to any other system in Cassandra that might log data, bearing in mind that Apache Cassandra is an open source project and, therefore, it does not control all possible forks and implementations and what and how data is logged.
+
+The solution was to sanitize any logging for sensitive information, and this has been addressed recently. But that still left the door open to some corner cases where the detection or removal of such sensitive information could fail. There are also specific use cases, services and applications that might need to store a user’s credentials and up until 4.1, they would be storing that in plain text as well.
+
+To strengthen security, we wanted to avoid the use of plain-text credentials altogether, so https://issues.apache.org/jira/browse/CASSANDRA-17334[CASSANDRA-17334^] and the release of Apache Cassandra 4.1 will add the option to use client-side password hashes.
+
+=== New Hash Password Tool
+
+This feature introduces a new tool called `tools/bin/hash_password`. Here is an example:
+
+```
+tools/bin/hash_password -p mySecret
+$2a$10$F5pRau9mKg5abP.DsuPQl.8rQpEoNm3OV91mKjb9vdKPUPejIPq/u
+```
+
+The tool is quite self-explanatory. It takes your plain-text secret and provides a https://www.mindrot.org/projects/jBCrypt/[jBCrypt^] hash that can be used in the DDL commands, e.g., to create or alter users/roles. For the moment only a Java version is available.
+
+=== Example Usage of Hash_Password
+
+Let’s look at some examples of how we’d use the tool:
+
+```
+Plain option:
+CREATE ROLE role1 WITH LOGIN = true AND PASSWORD = 'mySecret';
+New hashed option:
+CREATE ROLE role1 WITH LOGIN = true AND HASHED PASSWORD An‘$2a$10$F5pRau9mKg5abP.DsuPQl.8rQpEoNm3OV91mKjb9vdKPUPejIPq/u’;

Review Comment:
   @bereng does this look OK?
   
   ```suggestion
   CREATE ROLE role1 WITH LOGIN = true AND HASHED PASSWORD ‘$2a$10$F5pRau9mKg5abP.DsuPQl.8rQpEoNm3OV91mKjb9vdKPUPejIPq/u’;
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: pr-unsubscribe@cassandra.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: pr-unsubscribe@cassandra.apache.org
For additional commands, e-mail: pr-help@cassandra.apache.org