In other words, we are not going to, for example, reject a user from logging in when his password is weak because it was already created before we had a chance to prevent that from happening. It is not a goal to impose any restrictions on already existing passwords which were created before this CEP is introduced.
Provide a way for Cassandra to generate a password which would pass the subsequent validation for use by the user. To not be able to reuse same passwords which were previously set (up to some number of them, configurable), even they are otherwise valid. To be able to implement a custom password validator with its own policy, whatever it might be, and provide a modular/pluggable mechanism to do so. Emit a warning (and proceed) or just reject "create role" and "alter role" statements when provided password does not meet certain security level, based on user configuration of Cassandra. Implement a reference implementation of a password validator which adheres to a recommended password strength policy, to be used for Cassandra users out of the box. Introduce a way how to enforce password strength upon role creation or role alteration. This CEP is for users and operators of a cluster as well as for security departments and security officers. We believe that all these problems are solvable and they are unnecessary and the complexity of these problems might be greatly reduced or completely bypassed. This might be quite tedious task to do - to make Cassandra happy - hence it would be beneficial if Cassandra had a way to generate passwords which would pass its self-imposed security policy so users / operators do not need to do that on their own. Secondly, if Cassandra asks for passwords to be of a certain form, it is up to a user to come up with such password. 
However, upon changing a password, it should not be possible to reuse them - each new password for a user should be unique from the recent ones in order to not "recycle" them.
Last but not least, it is a good practice to change passwords every now and then to prevent unauthorised access when credentials are leaked unknowingly. More to it, once a password is set, even though it might follow some security guidelines upon its creation, it might be changed afterwards to a password which is less secure by "alter role" statements.
While passwords for users might be generated as part of company processes and they should adhere to organisational password complexity policies, it does not mean that it is enforced from Cassandra itself.
MotivationĪt the time of writing this CEP, Cassandra lacks a mechanism how to prevent a user from creating a password which does not follow a certain security policy. Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
0 kommentar(er)
