You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pr@cassandra.apache.org by GitBox <gi...@apache.org> on 2022/05/25 04:41:48 UTC

[GitHub] [cassandra-website] dtopdontstop opened a new pull request, #133: CASSANDRA-17657 May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password Hashing"

dtopdontstop opened a new pull request, #133:
URL: https://github.com/apache/cassandra-website/pull/133

   patch by Berenguer Blasi, Diogenese Topper; reviewed by Berenguer Blasi for CASSANDRA-17657
   
   Co-authored by: Berenguer Blasi
   Co-authored by: Diogenese Topper <di...@constantia.io>


-- 
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

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

Posted by GitBox <gi...@apache.org>.
ErickRamirezAU merged PR #133:
URL: https://github.com/apache/cassandra-website/pull/133


-- 
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

[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"

Posted by GitBox <gi...@apache.org>.
ErickRamirezAU commented on code in PR #133:
URL: https://github.com/apache/cassandra-website/pull/133#discussion_r881454117


##########
site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.adoc:
##########
@@ -0,0 +1,77 @@
+= 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 ‘$2a$10$F5pRau9mKg5abP.DsuPQl.8rQpEoNm3OV91mKjb9vdKPUPejIPq/u’;
+```
+
+As you can see we’re building the CQL with the hashed value of the password directly, i.e., this enables our applications to store the hash instead of the plain-text password. Also, any intermediate or third-party systems, additional logging or storing will deal with the hashes so the risk of accidental plain-text passwords leak is removed.
+
+The same applies to ALTER statements.
+
+Plain option:
+
+```
+ALTER ROLE role1
+    WITH PASSWORD = '%s'
+```
+
+New hashed option:
+
+```
+ALTER ROLE role1
+    WITH HASHED PASSWORD = '%s'
+```
+
+```

Review Comment:
   ```suggestion
   ```



##########
site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.adoc:
##########
@@ -0,0 +1,77 @@
+= 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 ‘$2a$10$F5pRau9mKg5abP.DsuPQl.8rQpEoNm3OV91mKjb9vdKPUPejIPq/u’;
+```
+
+As you can see we’re building the CQL with the hashed value of the password directly, i.e., this enables our applications to store the hash instead of the plain-text password. Also, any intermediate or third-party systems, additional logging or storing will deal with the hashes so the risk of accidental plain-text passwords leak is removed.
+
+The same applies to ALTER statements.
+
+Plain option:
+
+```
+ALTER ROLE role1
+    WITH PASSWORD = '%s'
+```
+
+New hashed option:
+
+```
+ALTER ROLE role1
+    WITH HASHED PASSWORD = '%s'
+```
+

Review Comment:
   ```suggestion
   ```



-- 
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

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

Posted by GitBox <gi...@apache.org>.
bereng commented on code in PR #133:
URL: https://github.com/apache/cassandra-website/pull/133#discussion_r881232602


##########
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:
   Please notice this should be:
   
   ``CREATE ROLE role1 WITH LOGIN = true AND HASHED PASSWORD ‘$2a$10$F5pRau9mKg5abP.DsuPQl.8rQpEoNm3OV91mKjb9vdKPUPejIPq/u’;``
   
   There is an extra `An`, I don't know where it came from, before the hash itself that needs to be removed.



-- 
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

[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"

Posted by 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

[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"

Posted by GitBox <gi...@apache.org>.
ErickRamirezAU commented on code in PR #133:
URL: https://github.com/apache/cassandra-website/pull/133#discussion_r881431009


##########
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

Review Comment:
   Fix date format:
   
   ```suggestion
   :page-post-date: May 26, 2022
   ```



##########
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:
+
+```

Review Comment:
   ```suggestion
   ```



##########
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

Review Comment:
   ```suggestion
   $ tools/bin/hash_password -p mySecret
   ```



##########
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:

Review Comment:
   ```suggestion
   Let’s look at some examples of how we’d use the tool.
   ```



##########
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';

Review Comment:
   ``````suggestion
   
   ```
   CREATE ROLE role1
       WITH LOGIN = true
       AND PASSWORD = 'mySecret';
   ```
   
   ``````



##########
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:

Review Comment:
   ``````suggestion
   New hashed option:
   
   ```
   ``````



##########
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’;
+```
+
+As you can see we’re building the CQL with the hashed value of the password directly, i.e., this enables our applications to store the hash instead of the plain-text password. Also, any intermediate or third-party systems, additional logging or storing will deal with the hashes so the risk of accidental plain-text passwords leak is removed.
+
+The same applies to ALTER statements:
+
+```

Review Comment:
   ```suggestion
   ```



##########
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’;
+```
+
+As you can see we’re building the CQL with the hashed value of the password directly, i.e., this enables our applications to store the hash instead of the plain-text password. Also, any intermediate or third-party systems, additional logging or storing will deal with the hashes so the risk of accidental plain-text passwords leak is removed.
+
+The same applies to ALTER statements:
+
+```
+Plain option:
+ALTER ROLE role1 with PASSWORD = '%s'
+New hashed option:
+ALTER ROLE role1 with HASHED PASSWORD = '%s'

Review Comment:
   ``````suggestion
   
   ```
   ALTER ROLE role1
       WITH HASHED PASSWORD = '%s'
   ```
   
   ``````



##########
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’;
+```
+
+As you can see we’re building the CQL with the hashed value of the password directly, i.e., this enables our applications to store the hash instead of the plain-text password. Also, any intermediate or third-party systems, additional logging or storing will deal with the hashes so the risk of accidental plain-text passwords leak is removed.
+
+The same applies to ALTER statements:

Review Comment:
   ```suggestion
   The same applies to ALTER statements.
   ```



##########
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’;
+```
+
+As you can see we’re building the CQL with the hashed value of the password directly, i.e., this enables our applications to store the hash instead of the plain-text password. Also, any intermediate or third-party systems, additional logging or storing will deal with the hashes so the risk of accidental plain-text passwords leak is removed.
+
+The same applies to ALTER statements:
+
+```
+Plain option:
+ALTER ROLE role1 with PASSWORD = '%s'

Review Comment:
   ``````suggestion
   
   ```
   ALTER ROLE role1
       WITH PASSWORD = '%s'
   ```
   
   ``````



-- 
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

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

Posted by GitBox <gi...@apache.org>.
bereng commented on code in PR #133:
URL: https://github.com/apache/cassandra-website/pull/133#discussion_r881232602


##########
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:
   Please notice this should be:
   
   ``CREATE ROLE role1 WITH LOGIN = true AND HASHED PASSWORD '$2a$10$F5pRau9mKg5abP.DsuPQl.8rQpEoNm3OV91mKjb9vdKPUPejIPq/u';``
   
   There is an extra `An`, I don't know where it came from, before the hash itself that needs to be removed.



-- 
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

[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"

Posted by 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