[
https://issues.apache.org/jira/browse/CASSANDRA-17457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860753#comment-17860753
]
Stefan Miklosovic edited comment on CASSANDRA-17457 at 6/28/24 8:41 AM:
------------------------------------------------------------------------
[~djoshi]
1) licence question: https://issues.apache.org/jira/browse/LEGAL-677
2) That is just not true
{code:java}
cassandra@cqlsh> alter role stefan10 with password = 'kK&Iw[p90Amnľščťžýáíôú'
AND login = true;
(0 rows)
cassandra@cqlsh> exit
✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-17457 L|✚ 1⚑ 109]
10:26 $ ./bin/cqlsh -u stefan10 -p 'kK&Iw[p90Amnľščťžýáíôú';
Warning: Using a password on the command line interface can be insecure.
Recommendation: use the credentials file to securely provide the password.
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
Use HELP for help.
stefan10@cqlsh>
{code}
Notice the characters I used: ľ š č ť ž ý á í ô ú - they are all from my native
language - Slovak language. It is clearly not limited to English only.
3) I think this is just a matter of opinion and to have some counter-argument -
we actually voted on this already. The way how it is configured was part of the
CEP and I do not see why we should change it in post-binding-votes times. More
to it, the way it is implemented is pluggable. If somebody is not satisfied
then they are very welcome to code up their own validator whatever they like.
That was also one of the very goals.
To be pristine clear, I think that your suggestion to specify own special
characters is rather valid, but at the same time, I think we should prevent
people from doing something which would go against their interest. For example,
if we allow a special character to be ' (simple quote), then imagine that they
have this password: abcde'fgh
Then when they come to alter it, like this:
{code:java}
alter user myrole with password = 'abcde'fgh' {code}
This would fail without them probably escaping it. That is just unnecessary
hassle.
This also holds for e.g. whitespace characters. Passay considers these
characters to be whitespaced-like we are forbidding for now:
{code:java}
protected static final char[] CHARS = new char[]{'\t', '\n', '\u000b', '\f',
'\r', ' '};
{code}
I do not know who "sane" would start to support tabs or new lines or \f or \r
in their password. If they are supposed to be valid, how are these people going
to put them into places like cqlshrc? Is not this just unnecessary can of worms
we intend to open for apparent no reason at all?
So all in all, 1) is in pending to be answered, I think 2 is not relevant and 3
is subjective. I would not change only if you absolutely insist on that.
Nice thing about Passay is that it contains a lot of rules people might choose
from if they feel like what we offer is not enough. I think it is also
important to realize that we all people to be flexible about this. If we ever
come up with something completely own we will never match it in its
capabilities.
was (Author: smiklosovic):
[~djoshi]
1) licence question: https://issues.apache.org/jira/browse/LEGAL-677
2) That is just not true
{code:java}
cassandra@cqlsh> alter role stefan10 with password = 'kK&Iw[p90Amnľščťžýáíôú'
AND login = true;
(0 rows)
cassandra@cqlsh> exit
✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-17457 L|✚ 1⚑ 109]
10:26 $ ./bin/cqlsh -u stefan10 -p 'kK&Iw[p90Amnľščťžýáíôú';
Warning: Using a password on the command line interface can be insecure.
Recommendation: use the credentials file to securely provide the password.
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5]
Use HELP for help.
stefan10@cqlsh>
{code}
Notice the characters I used: ľ š č ť ž ý á í ô ú - they are all from my native
language - Slovak language. It is clearly not limited to English only.
3) I think this is just a matter of opinion and to have some counter-argument -
we actually voted on this already. The way how it is configured was part of the
CEP and I do not see why we should change it in post-binding-votes times. More
to it, the way it is implemented is pluggable. If somebody is not satisfied
then they are very welcome to code up their own validator whatever they like.
That was also one of the very goals - to have something usable but if people
want to include their national characters they are welcome to try to support
that too.
To be pristine clear, I think that your suggestion to specify own special
characters is rather valid, but at the same time, I think we should prevent
people from doing something which would go against their interest. For example,
if we allow a special character to be ' (simple quote), then imagine that they
have this password: abcde'fgh
Then when they come to alter it, like this:
{code:java}
alter user myrole with password = 'abcde'fgh' {code}
This would fail without them probably escaping it. That is just unnecessary
hassle.
This also holds for e.g. whitespace characters. Passay considers these
characters to be whitespaced-like we are forbidding for now:
{code:java}
protected static final char[] CHARS = new char[]{'\t', '\n', '\u000b', '\f',
'\r', ' '};
{code}
I do not know who "sane" would start to support tabs or new lines or \f or \r
in their password. If they are supposed to be valid, how are these people going
to put them into places like cqlshrc? Is not this just unnecessary can of worms
we intend to open for apparent no reason at all?
So all in all, 1) is in pending to be answered, I think 2 is not relevant and 3
is subjective. I would not change only if you absolutely insist on that.
Nice thing about Passay is that it contains a lot of rules people might choose
from if they feel like what we offer is not enough. I think it is also
important to realize that we all people to be flexible about this. If we ever
come up with something completely own we will never match it in its
capabilities.
> CEP-24 - Password validation/generation
> ---------------------------------------
>
> Key: CASSANDRA-17457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17457
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
> Reporter: Berenguer Blasi
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 5.x
>
>
> Implement CEP-24 as per
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=228494146
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
