[
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:57 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 we generated for them (because ' would be valid
special char)
Then when they come to alter it, like this:
{code:java}
alter user myrole with password = 'abcde'fghsomeevenstrongerpassword' {code}
This would fail without them probably escaping it because it would evaluate it
as invalid query with some characters after the first closing '. 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? How are they going to type "\n" on CQLSH
console when hitting "enter" on the keyboard goes to send the shell command
over to Cassandra? Is not this just unnecessary can of worms we intend to open
for apparent no reason at all? All passwords we generate should be 1) type-able
on the console when prompted 2) put into cqlshrc and read from there.
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 enable people to be flexible about this. If we
ever come up with something completely on our 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 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 we generated for them (because ' would be valid
special char)
Then when they come to alter it, like this:
{code:java}
alter user myrole with password = 'abcde'fghsomeevenstrongerpassword' {code}
This would fail without them probably escaping it because it would evaluate it
as invalid query with some characters after the first closing '. 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? How are they going to type "\n" on CQLSH
console when hitting "enter" on the keyboar goes to send the shell command over
to Cassandra? Is not this just unnecessary can of worms we intend to open for
apparent no reason at all? All passwords we generate should be 1) type-able on
the console when prompted 2) put into cqlshrc and read from there.
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 enable people to be flexible about this. If we
ever come up with something completely on our 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
