Just to clarify, I have no objections to the current plan. On Thu, Oct 13, 2022 at 2:56 PM Claude Warren, Jr <claude.war...@aiven.io> wrote:
> I am not familiar with the Diagnostics framework but it sounds like it > would satisfy the need. Thanks for pointing it out. I will dive into it > to get an understanding of how it works. > > On Thu, Oct 13, 2022 at 1:52 PM Miklosovic, Stefan < > stefan.mikloso...@netapp.com> wrote: > >> Hi Claude, >> >> we may also integrate with Diagnostics framework Cassandra already ships. >> I would say this better suits to your requirements for observability. I am >> not sure to what degree you are familiar with Diagnostics though. To give >> you a better picture, events are fired and external observers (in the >> framework called "subscribers") would be notified about the internal >> accordingly. As of now, observers / subscribers are meant to integrate with >> JMX through which these events flow. >> >> Do you think Diagnostics events would satisfy your needs? >> >> Regards >> >> ________________________________________ >> From: Claude Warren, Jr via dev <dev@cassandra.apache.org> >> Sent: Thursday, October 13, 2022 14:43 >> To: 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. >> >> >> >> 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<mailto: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<mailto: >> claude.war...@aiven.io>> >> Sent: Thursday, October 13, 2022 12:50 >> To: Miklosovic, Stefan >> Cc: dev@cassandra.apache.org<mailto: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><mailto: >> 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><mailto: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><mailto: >> 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. >> >> >>
