I think we might be in violent agreement here. The point I was trying to make is that the rules for valid passwords are many and varied. I have worked at places where they wanted to know the time since the last password change, this was used to prevent the rapid change of password to get back to the original one (I think 5 was the example earlier). Anyway, the point was, identify the information necessary from the system to fulfill the rules we think of (so far this is the new password, a list of old passwords, and the time of the last password change) and call a validator plugin passing it the new password, list of passwords, date of last change, and an observer instance.
The validator implementation will verify the instance and report any issues to the observer and return true/false and potentially a user message. Any logging is attached to the observer, any reporting to grafana or similar reporting is attached to the observer. A simple implementation of the validator that performs series of configurable tests against the password would probably be sufficient for the validation A simple implementation of the observer that logs the messages Jeff suggested would probably be sufficient. Both would allow much more complex validation and/or reporting as necessary. On Thu, Oct 13, 2022 at 9:26 AM Miklosovic, Stefan < stefan.mikloso...@netapp.com> wrote: > 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. > > >
