Hi Claude, you said: "I don't know the govt spec. but there is a US govt security level where you are not allowed to inform the user why the login failed."
I do not think this is the case. Nobody is going to inform a user with existing role in the db why he failed to log in, when it comes to this CEP (is not it actually already in place? CQLSH says your username / password combo is invalid on login already) This CEP has nothing to do with it. What we have in mind, I think, it is more about informing him about the details when the password he tries to set (upon role creation) or change (via role alteration), is not valid, based on the policy. I reckon that what Jeff simply wants to see is a log if such change was successful or not. Lets repeat here what Jeff would like to see: "Password changed for user X, complying with policies (reuse, complexity, entropy)" "ERROR: Password rejected due to policy violation (reuse)" "ERROR: Password rejected due to policy violation (complexity)" "ERROR: Password rejected due to policy violation (entropy)" This is a generalized version of what we already have in place in CEP, we have there information like: Password must be 10 or more characters in length. Password must contain 2 or more uppercase characters. Password matches 3 of 4 character rules, but 4 are required. Password matches one of 5 previous passwords. Password must be 12 or more characters in length Now, I have to admit that the information we provide above, in contrast of what Jeff mentioned, is quite verbose. It is questionable whether we should be so specific or whether more generalized version is enough. Maybe two versions of the logs would be the most appropriate - ours (more detailed) would be returned to a user in cqlsh as a warning / error after unsuccessful query execution but the messages Jeff mentioned would be written in system logs via slf4j. So we would be detailed for a user but general for auditing purposes. Do you think this makes sense to you all? I think this is want you said, more or less, in your middle paragraph, just formulated differently. I agree with Jackson with the password meter e-mail. After all, if somebody really wants that to happen, since our solution is pluggable, people can implement their own password-meter-based solution if they find it necessary. To fail a password when it is reused (or found among previous n). I am on the edge here. I understand what Josh is telling, that we can go just so far when it comes to prevent people from doing wrong things, maybe increasing the password history to 20 last passwords would be enough. Anyway, I plan to make this historical password verification optional so it might be turned on / off on demand. Finally, when it comes to password dictionaries. This might be included in the CEP but I would keep it out for the very first implementation and it can be finished afterwards in some other commit. I do not find it absolutely necessary to do it right now. Regards, Stefan ________________________________________ From: Claude Warren, Jr via dev <dev@cassandra.apache.org> Sent: Thursday, October 13, 2022 9:44 To: dev@cassandra.apache.org Subject: Fwd: [Discuss] CEP-24 Password validation and generation NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. I managed not to send this to the mailaing list... I don't know the govt spec. but there is a US govt security level where you are not allowed to inform the user why the login failed. It seems to me that there are 2 intertwined components being discussed. 1) A component to perform a user password change capability 2) A plugable validation component. 3) A pluggable observability component. Without a validation component all passwords are valid and provides user messages for failures. Validation receives the new password and some list of old passwords as arguments. Validation returns a structure comprising the success/failure, the user message, internal result, internal result message. The observability implementations could log the results, send counts to Grafana, etc. If there is no observer then no results are presented. Alternatively the validation could accept the observability component as an argument and pass the internal result and internal result message directly to the observability component.
