With reference to https://redis.io/commands/auth
When Redis ACLs are used, the command should be given in an extended way:
AUTH
Additionally, it will be useful to have:
[1] userid lockout if # of failed logins have surpassed a configurable threshold and unlocked by a security administrator when needed [2] maintain password history in a "vault/wallet" [3] password policy to ensure that no simple dictionary passwords used to minimize unauthorized access and also have a configurable # of days change between password rotations for compliance reason
Thank you.
Comment From: itamarhaber
Hello @nadirdbit
Thanks for making these suggestions.
a prompt to enter the password which is not echoed back on the screen display
Masking the password when using the redis-cli in REPL mode is a good idea. With something like https://github.com/antirez/linenoise/pull/182 this can probably be implemented fairly easily.
[1] ...
ACLs already support enabling/disabling users and the ACL LOG can be used to identify suspicious actions ad-hoc. Automating the lockout process can be a nice feature to have.
[2] ...
I'm not sure that I fully understand the need for keeping the history - is that meant for ensuring only new passwords are used? If so then my next answer addresses this as well.
[3] ...
Enforcing one ore more password policies is, imo, outside the scope of Redis. Keep in mind that Redis' users are applications, so these don't suffer from typing/memorization and therefore passwords can (and should ) be totally random and long (i.e. use ACL GENPASS or similar for strong passwords).
For manageability and tracking purposes, I suggest that you split this issue into two: keep this one about masking the password, and a new one for the automatic lockout mechanism.
Comment From: nadirdbit
Hi Itamar/Team,
[2] Password history will ensure that no two passwords are nearly similar during configurable password rotation period - this will also discourage any password cracking attempts
[3] I agree with your comment but there is no check being currently implemented by Redis to ensure that password is strong - that would be validated by a password policy which should work together with any requisite existing corporate guidelines used [should be flexible to support majority of users and few configurable items listed below as an example]:
o Minimum password length o Mix of uppercase, lowercase, digit characters [at least one of each] o Usage of special symbols within password [at least one mandatory if applicable and allowable set in case any limitation]
I've discussed this together in a single enhancement request since they are all closely related to each other - please arrange to split this up internally via additional ones for manageability and tracking.
Thank you.
Nadir
On Wed, Aug 26, 2020 at 10:00 AM Itamar Haber notifications@github.com wrote:
Hello @nadirdbit https://github.com/nadirdbit
Thanks for making these suggestions.
a prompt to enter the password which is not echoed back on the screen display
Masking the password when using the redis-cli in REPL mode is a good idea. With something like antirez/linenoise#182 https://github.com/antirez/linenoise/pull/182 this can probably be implemented fairly easily.
[1] ... ACLs already support enabling/disabling users and the ACL LOG can be used to identify suspicious actions ad-hoc. Automating the lockout process can be a nice feature to have.
[2] ... I'm not sure that I fully understand the need for keeping the history - is that meant for ensuring only new passwords are used? If so then my next answer addresses this as well.
[3] ... Enforcing one ore more password policies is, imo, outside the scope of Redis. Keep in mind that Redis' users are applications, so these don't suffer from typing/memorization and therefore passwords can (and should ) be totally random and long (i.e. use ACL GENPASS https://redis.io/commands/acl-genpass or similar for strong passwords).
For manageability and tracking purposes, I suggest that you split this issue into two: keep this one about masking the password, and a new one for the automatic lockout mechanism.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/redis/redis/issues/7709#issuecomment-680935089, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP5GFC3TX7LAXXPRRODFC53SCUPRTANCNFSM4QLHDQGA .