Open rymnc opened 1 year ago
Taken from a PR, tracking it here just in case. iirc I have never seen a keystore with requirements on the password. Not saying no, just fyi
unsure if we can do that. is the keystore taken from some spec (eg EIP)? if so, if the EIP does not enforce any password strength, then we can enforce it on top.
eg, not the one we are using but https://eips.ethereum.org/EIPS/eip-2335
The password is a string of arbitrary unicode characters. The password is first converted to its NFKD representation, then the control codes (specified below) are stripped from the password and finally it is UTF-8 encoded.
there are no requirements beyond that
We need to enforce password strength so that the user does not misconfigure it
the state of the art is to show to the user that a password is weak rather than enforcing it - enforcing has poor practical outcomes with humans (ie post-it on screen)
We need to enforce password strength so that the user does not misconfigure it
the state of the art is to show to the user that a password is weak rather than enforcing it - enforcing has poor practical outcomes with humans (ie post-it on screen)
@Ivansete-status is this okay?
We need to enforce password strength so that the user does not misconfigure it
the state of the art is to show to the user that a password is weak rather than enforcing it - enforcing has poor practical outcomes with humans (ie post-it on screen)
@Ivansete-status is this okay?
Thanks for pinging me @rymnc ! Super interesting comments !
I have a quite strong opinion that we should enforce a minimum strength. Having a weak password sounds equivalent to not having a password at all, but of course, I might be missing technical details. I think is important to show that we care about security.
I see two possible options, either of them are good to me:
Set a weaker constraint: The --rln-relay-cred-password flag accepts a password that has - at least 8 characters, alphanumeric, at least 1 special character, at least 1 number
Not set a constraint at all in the code but merely add a recommendation in the parameter's description, so the user will decide the level of security he/she wants to adopt.
Where these keystores are stored? What are the use cases or purposes of such keystores?
Cheers
@alrevuelta @jm-clius should this be part of https://github.com/waku-org/pm/issues/70 ?
This is a useful improvement, but not critical to closing https://github.com/waku-org/pm/issues/70 or launch TWN. Should we track such issues separately?
Background
The rln_keystore_generator tool accepts a credential password.
Details
We need to enforce password strength so that the user does not misconfigure it
Acceptance criteria
--rln-relay-cred-password
flag accepts a password that has - atleast 10 characters, alphanumeric, atleast 1 special character, atleast 1 number