There seems to be a conflicting guideline related to PIN content policy regards the PIN content policy that starts with -.
In the doc/policies/user.rst, we explain that:
-cn (substraction) test1234 would be a valid OTP PIN, but test12$$ and testABCS would not be valid OTP PINs. The later since it does not contain digits, the first ( test12$$ ) since it does contain a special character ($), which it should not.
and
+cn (grouping)
combines the two required groups. I.e. the OTP PIN should contain characters from the sum of the two groups. test1234 , test12$$ , test and 1234 would all be valid OTP PINs.
However, currently in the code, PrivacyIDEA seems to interpret the - differently:
The policy to check a PIN can contain of “c”, “n” and “s”.
“cn” means, that the PIN should contain a character and a number.
“+cn” means, that the PIN should contain elements from the group of characters and numbers
“-ns” means, that the PIN must not contain numbers or special characters
And therefore, we are lacking of a way to force a PIN content to only have certain type of characters like proposing in the old users.rst doc. For example, use case where the user needs to be only allowed to set PIN that contains digits only.
I am not sure if I am missing something? And is it possible to add support for the use case similar to the old - proposal?
In know that the pin policy is a bit mixed up. I was not aware of the difference between the docs and implementation in regards to the “-”.
In theory “-cos” should work… but…
Interesting that you need to force users to use a weak pin
I think the most straightforward approach would be to add the possibliity to add a list of allowed characters. Or a PIN checking mechanism.
@quynh, can you please tell in which version you saw the different behaviour, so that we can check how and why this changed? Thanks!
The - and the + support was not implemented for the version I mentioned, even though the doc was already there with the feature explanation.
I was only mentioning the discrepancy between the doc and the actual code implementation in master due to my confusion for expectation on the policy.
I think your working around will do for our usage. Therefore, we will go that route instead for our scenerios (For example, using -cos to force only allowed numeric PIN, etc). Thank you for the suggestion!
