I agree that any password change (or attempted change) would be very important audit data that would need to be captured, I don’t think that auditors would necessarily need to know the reason for rejection for a validator? Maybe I’ve just worked within less strict auditing requirements though.
We probably need to ensure that any logging is distinct enough for auditing purposes (so a password policy violation isn’t confused with say a user lacking permission to perform the operation they attempted). I would note that for telling users about why their password changes were rejected, a message is sent back to them detailing why the password was rejected is part of this CEP. For example: InvalidRequest: Error from server: code=2200 [Invalid query] message="Guardrail password violated: Password was not set as it violated configured password strength policy. To resolve this error, the following has to be done: Password must be 8 or more characters in length. " Cheers, Jackson From: Derek Chen-Becker <de...@chen-becker.org> Date: Wednesday, 12 October 2022 at 7:07 am To: dev@cassandra.apache.org <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. Thanks Jeff, you put it more succinctly than I was able to. I think just having these logged out in the app log would be sufficient for audit purposes. Cheers, Derek On Tue, Oct 11, 2022 at 12:56 PM Jeff Jirsa <jji...@gmail.com<mailto:jji...@gmail.com>> wrote: I don't think logging which policy violation was triggered is that big of an ask? "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)" The success log makes it much easier for users subject to audit controls, and the failures make it much easier to tell users what's going on for those users who operate the database for other people. On Tue, Oct 11, 2022 at 11:48 AM Miklosovic, Stefan <stefan.mikloso...@netapp.com<mailto:stefan.mikloso...@netapp.com>> wrote: I am afraid this is way out of scope of this CEP. I think we would be the very first on the database scene to offer such low-level and fine-grained information. I am not persuaded that this is something we should be giving a lot of attention right now. We have "cassandra / cassandra" credentials combo as default, I would say that is more important to deal with right now than providing very detailed information about what kind of passwords people are using. Thank you very much for (not only your) insights. This is very important feedback and I am glad you participate in this thread. I will try to summarize where we are as it is easy to get lost in these emails. ________________________________________ From: Derek Chen-Becker <de...@chen-becker.org<mailto:de...@chen-becker.org>> Sent: Tuesday, October 11, 2022 18:59 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. Speaking with my operator hat on, I would want to know if there's a common pattern that my end users hit so that I can better educate them or provide tools (e.g. vaults) to help them manage the required complexity. Cheers, Derek On Tue, Oct 11, 2022 at 10:06 AM Miklosovic, Stefan <stefan.mikloso...@netapp.com<mailto:stefan.mikloso...@netapp.com><mailto:stefan.mikloso...@netapp.com<mailto:stefan.mikloso...@netapp.com>>> wrote: "but we should consider logging why it was rejected." Why? What is the use case? Why is it important for you to know what somebody tried to create a role with password "aaaaaaaaaa" (it will not be shown), just mentioning that they tried to create a password with a lot of repeating characters? What is the added value here? I need to double check if warnings are logged as well. I'll get back to you. ________________________________________ From: Derek Chen-Becker <de...@chen-becker.org<mailto:de...@chen-becker.org><mailto:de...@chen-becker.org<mailto:de...@chen-becker.org>>> Sent: Tuesday, October 11, 2022 17:47 To: 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 know we log that the password change attempt was made, but we should consider logging why it was rejected. As part of that, we may want to consider how we format that message to make it easy for an auditing system to parse. We should never log the actual password, or even a redacted version; apologies if it sounded like I was suggesting that. Cheers, Derek On Tue, Oct 11, 2022 at 9:36 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: I dont follow, sorry. What logs do you mean? What would you like to see? The auditing framework we already do have in place will log that somebody tried to create (or alter) a role with this and that password and it failed (password would be redacted). If you use "with generated password", that password will not be even shown in audit log. I am not completely sure if the warning is logged too if password is not valid (I do think that only CQL command itself is audit-logged). The configuration of validator is in cassandra.yaml. Folks can review that? I am sorry if I am missing something here, could you expand what you mean? To Josh: You are probably right but it is so easy to bypass that it is questionable why it is actually there. All it takes is to do "alter role myself with generated password" (literally), 5 times in a row and you can set the original one back. One positive fact is that such password, even same as the original one, would still have to be valid, but it just might be same as it was. ________________________________________ From: Derek Chen-Becker <de...@chen-becker.org<mailto:de...@chen-becker.org><mailto:de...@chen-becker.org<mailto:de...@chen-becker.org>><mailto:de...@chen-becker.org<mailto:de...@chen-becker.org><mailto:de...@chen-becker.org<mailto:de...@chen-becker.org>>>> Sent: Tuesday, October 11, 2022 17:14 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: 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. On top of what Josh said, a corresponding requirement here would be auditing. A password complexity and/or history policy is one piece of security posture, but is itself insufficient to be considered "secure". What kind of logs will this new policy checker emit that the folks responsible for security for a given cluster can parse, process, and report on? Cheers, Derek On Tue, Oct 11, 2022 at 9:07 AM Josh McKenzie <jmcken...@apache.org<mailto:jmcken...@apache.org><mailto:jmcken...@apache.org<mailto:jmcken...@apache.org>><mailto:jmcken...@apache.org<mailto:jmcken...@apache.org><mailto:jmcken...@apache.org<mailto:jmcken...@apache.org>>><mailto:jmcken...@apache.org<mailto:jmcken...@apache.org><mailto:jmcken...@apache.org<mailto:jmcken...@apache.org>><mailto:jmcken...@apache.org<mailto:jmcken...@apache.org><mailto:jmcken...@apache.org<mailto:jmcken...@apache.org>>>>> wrote: if we do that, we should also restrict the frequency how often a user can change the password. Lets think this through. If the depth of historical verification is 5 passwords, a user just has to regenerate a password 5 times in a row an he can use the same one I may be misunderstanding, but this strikes me as in the "we can only do so much to prevent people from doing stupid things" category. If someone's so hell-bent on circumventing their company's attempts at security they're probably much more at risk of running unidentified attachments or giving out credentials over the phone rather than finding clever ways to work around annoying password rotation rules on their db accounts right? On Mon, Oct 10, 2022, at 4:08 PM, Miklosovic, Stefan wrote: Hi Brad, your link about not enforcing regular password expiration for users is spot on. For these reasons I decided to not expand that CEP in that direction. Sure, technically possible, but practically questionable. I think that all these guides and recommendations should be looked at from the perspective of the system they are meant to be implemented in. Enforcing password to be changed in a database system is rather interesting take. After I briefly took a look, I do not think there is a database on the market which is enforcing this. On the other hand, for example, Neo4j forces you to change the password on the first login as the default one is "neo4j" for user "neo4j". This does make sense to implement for Cassandra as well. I do consider password "cassandra" for role "cassandra" very insecure and it is not forced by anybody to change it. However, it is quite interesting problem how to achieve that. Also, the reason I want to leave out historical verification of passwords in (at least the initial) implementation is that if we do that, we should also restrict the frequency how often a user can change the password. Lets think this through. If the depth of historical verification is 5 passwords, a user just has to regenerate a password 5 times in a row an he can use the same one. So implmenting this without restricting how often he can change his password does not make sense. We can indeed explore this further but I feel like the initial implementation should not deal with this for now. When it comes to section 5.1.1.2 of NIST document, as already mention at the bottom of the CEP, we used Appendix A of this (1) to model what the good password should be. Your link is way more descriptive though. Particularly interesting points are these: - Passwords obtained from previous breach corpuses. - Dictionary words. - Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’). - Context-specific words, such as the name of the service, the username, and derivatives thereof. I believe that points 1), 2) and 4) can be implemented easily as checking the password against a dictionary. The library we want to use is able to check the password against a dictionary. Dictionary check can be also implemented as a separate ticket which would just expand the functionality of DefaultPasswordValidator. I do not have a problem to include dictionary check into the first iteration as well. Repetitive or sequential characters are already covered in the POC implementation. The document you linked also contains this: Verifiers SHOULD offer guidance to the subscriber, such as a password-strength meter [Meters], to assist the user in choosing a strong memorized secret. This is particularly important following the rejection of a memorized secret on the above list as it discourages trivial modification of listed (and likely very weak) memorized secrets We are already doing this, quite intelligently, by telling a user what is wrong with his password that it can not be used (e.g. that it does not contain so and so number of specific characters). The "meter" is also there - we have three levels - OK password, password with a warning and failed password. We inform a user about the strength of his password retroactively - we do not tell him what the password should be before he tries to set one however I think that is acceptable when using Cassandra and cqlsh in console environment. (1) https://pages.nist.gov/800-63-3/sp800-63b.html#appA ________________________________________ From: Brad <bscho...@gmail.com<mailto:bscho...@gmail.com><mailto:bscho...@gmail.com<mailto:bscho...@gmail.com>><mailto:bscho...@gmail.com<mailto:bscho...@gmail.com><mailto:bscho...@gmail.com<mailto:bscho...@gmail.com>>><mailto:bscho...@gmail.com<mailto:bscho...@gmail.com><mailto:bscho...@gmail.com<mailto:bscho...@gmail.com>><mailto:bscho...@gmail.com<mailto:bscho...@gmail.com><mailto:bscho...@gmail.com<mailto:bscho...@gmail.com>>>>> Sent: Monday, October 10, 2022 17:43 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>>><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<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 would suggest reviewing the guidelines in sec in 5.1.1.2 of NIST Special Publication 800-63B<https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver> and the NCSC Password policy: updating your approach - NCSC.GOV.UK<http://NCSC.GOV.UK><http://NCSC.GOV.UK><http://NCSC.GOV.UK><http://NCSC.GOV.UK><https://www.ncsc.gov.uk/collection/passwords/updating-your-approach#PasswordGuidance:UpdatingYourApproach-Don'tenforceregularpasswordexpiry> Regards, Brad On Mon, Sep 19, 2022 at 7:27 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>>><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<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><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<mailto:stefan.mikloso...@netapp.com><mailto:stefan.mikloso...@netapp.com<mailto:stefan.mikloso...@netapp.com>>>>>> wrote: Hi list, together with my colleague Jackson Fleming we put together CEP-24 about password validation and password generation in Cassandra. https://cwiki.apache.org/confluence/x/QoueDQ We are looking forward to discuss this CEP with you in depth. The outcome of this thread would be to sort out any issues / concerns you have so we might eventually vote and implement that in upstream if our contribution is found to be useful. There is a reference implementation provided we would like to build our solution on top. Regards Stefan Miklosovic -- +---------------------------------------------------------------+ | Derek Chen-Becker | | GPG Key available at https://keybase.io/dchenbecker and | | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org | | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | +---------------------------------------------------------------+ -- +---------------------------------------------------------------+ | Derek Chen-Becker | | GPG Key available at https://keybase.io/dchenbecker and | | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org | | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | +---------------------------------------------------------------+ -- +---------------------------------------------------------------+ | Derek Chen-Becker | | GPG Key available at https://keybase.io/dchenbecker and | | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org | | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | +---------------------------------------------------------------+ -- +---------------------------------------------------------------+ | Derek Chen-Becker | | GPG Key available at https://keybase.io/dchenbecker and | | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org | | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | +---------------------------------------------------------------+
