I feel like this thread deserves an update. This CEP was put in a dormant state because there was one quite substantial flaw, that is that if a node is misconfigured in such a way that it would accept weaker passwords than other nodes in a cluster, it would not be safe. The security of such solution would be as safe as the weakiest configuration of a node from a cluster.
The correct answer to this problem was / is transactional guardrails. I was waiting for TCM to appear in trunk to implement this for year and a half and we are finally there (1) which I am very excited about. What transactional guardrails are doing is that each CQL mutation to a respective guardrails virtual table (which is mutable) will commit a transfromation into TCM log. That in turn means that this configuration is propagated to whole cluster and survives restarts etc. That also means that we are configuring any guardrail by one CQL statement for whole cluster in persistent manner which I would say is quite powerful and time / cost saving from techops / devops point of view, especially on a very large scale. You can do something like this UPDATE system_guardrails.flags SET value = false where name = 'simplestrategy'; and this will be commited into TCM, everything replayed on restart, same for whole cluster ... you got the idea. Hence, similarly, you can commit configuration for a password validator and it will be same across whole cluster as well. This solution received quite positive feedback and it was suggested that we should actually commit into TCM all configuration which is meant to be same for each node. I stopped with the introduction of more general "config in TCM" solution as there seems to be entities in this space which are trying to come up with that (that is the vibe I am getting) hence I am currently in kind of a limbo and half-way there. Let's see what happens next, I just want to highlight that the next course of action will most probably be the introduction of transactional configuration until this one can finally be integrated with that too. Currently, there is one missing configuration property to be transactional - default_keyspace_rf - because it is used by one of guardrails too. This leads to more general "config in TCM" case which we have not dealt with yet. Branch with transactional guardrails is in (2). (1) https://issues.apache.org/jira/browse/CASSANDRA-19593 (2) https://github.com/instaclustr/cassandra/tree/CEP-24-with-generator-tcm ________________________________________ From: Miklosovic, Stefan <stefan.mikloso...@netapp.com> Sent: Monday, December 19, 2022 14:24 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. One not-so-obvious consequence of the configuration of password validator - since it is based on guardrails - is that if there is a cluster of 50 nodes and we change a configuration (in runtime) in one node, it needs to be done for all remaining 49. We need to be sure that the configuration is same for all nodes because if we do not configure one node the way we want, all it takes to pass the (less secure) validation is to create passwords while being logged on that node. I think that something similar was done to memtables CEP and there was some additional discussion about that - the way how it is configured - it is in yaml and not in schema so it is only node-specific, right? (not saying it is wrong, I just noticed that there was additional discussion questioning that approach which was further clarified). However when it comes to security, I think it should be as robust as possible. I am not completely sure what to do here. It would be great to have some "distributed configuration" otherwise all I can do is to mimic this behavior by a table, similarly as system_auth.roles is done for passwords, for example. However, I feel like it should be more robust and I think that in the future there might be more cases when we need to have the configuration distributed like this. However, I am fine to proceed with my original plan when community thinks that the current approach is enough. ________________________________________ From: Claude Warren, Jr via dev <dev@cassandra.apache.org> Sent: Wednesday, October 19, 2022 10:58 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. 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<mailto: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<mailto: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<mailto:dev@cassandra.apache.org>> Sent: Thursday, October 13, 2022 14:43 To: 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. 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><mailto: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><mailto: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><mailto: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>><mailto: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>><mailto: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>><mailto: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.
