The only difference I see is that I see observability (observer) as being a way to retrieve (or be notified about) data used within a process. Logging on the other hand, is a preservation of a state discovered in an observable object. Observability can drive logging but it can also drive aggregate statistics in grafana, and things like that.
My reading of the CEP-3 is that it is intended to provide system-wide soft and hard limits, it is not an observability framework. It makes sense for the validator to implement CEP-3 but I think that an observability interface is required as well. On Thu, Oct 13, 2022 at 12:36 PM Miklosovic, Stefan < stefan.mikloso...@netapp.com> wrote: > Hi Claude, > > all you say makes sense to me. I do not see any discrepancies. It will be > logged as discussed already. > > The complexity of password validation is partly covered by the library we > want to use (Passay). It will inform you in a very detailed manner when it > comes to what violations of a policy there are. We are not going to invent > a wheel here, fortunately. > > Terminology you used - "observer" - is Guardrail itself (CEP-3). It will > be the one doing reporting e.g by logging and returning warnings / errors, > if any, back to user who executed that query. > > The approach we took indeed can also be extended in such a way that it > would be possible to know what was the last time a password was changed for > some user. This is the direct consequence of us having a table of previous > password for checking that a user is not reusing them. There is a timestamp > column specified here (1) if you check the schema of that table closely so > to answer "when was the password changed lastly" is rather easy to know - > "select created from system_auth.previous passwords where role = 'stefan' > limit 1" > > To your requirements: > A simple implementation of the validator that performs series of > configurable tests against the password would probably be sufficient for > the validation > > Sure, this is configurable, by either implementing a custom validator if > you find the default one insufficient or configuring the default one > accordingly. > > "A simple implementation of the observer that logs the messages Jeff > suggested would probably be sufficient." > > Yes, no problem with logging from Guardrail directly. > > (1) > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-24%3A+Password+validation+and+generation#CEP24:Passwordvalidationandgeneration-Validationofanewpasswordagainstpreviouspasswords > > Regards > > ________________________________________ > From: Claude Warren, Jr <claude.war...@aiven.io> > Sent: Thursday, October 13, 2022 12:50 > To: Miklosovic, Stefan > Cc: dev@cassandra.apache.org > Subject: Re: [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 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<mailto: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<mailto: > dev@cassandra.apache.org>> > Sent: Thursday, October 13, 2022 9:44 > To: dev@cassandra.apache.org<mailto: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. > > >
