On Tue, Mar 26, 2019, at 12:56, Martin Casanova wrote:
> I know that you have foreseen draft-gould-regext-login-security-policy
> to query about password complexity but I think for convenience of the
> registrar it would still be nice to somehow include the password
> requirement in the response even if it is redundant. Otherwise one has
> to implement draft-gould-regext-login-security-policy at the same time
> or communicate the requirement out of band.
>
> maybe like that
>
> S: <loginSec:event
> S: type="newPW"
> S: value="expression:
> (?=.*\d)(?=.*[a-zA-Z])(?=.*[\x21-\x2F\x3A-\x40\x5B-\x60\x7B-\x7E])
> (?!^\s+) (?!.*\s+$)(?!.*\s{2,})^[\x20-\x7e]{16,128}$"
> S: level="error">
> S: New password does not meet complexity requirements
> S: </loginSec:event>
> Page 10:
>
> S: <result code="2200">
> S: <msg>Authentication error</msg>
It may be nice to try giving back all the requirements... except that you can
not always express all of them with a regular expression for once, and because
there are different flavors of regular expressions for another reason,
two points I already raised on the "policy" extension.
Some registries may have requirements like: at least one letter and at least one
digit and at least one "special" character.
While this may still be done by a regex, it will not be nice (as you need to
consider at the same time the range of characters allowed and the constraints
on length), and yet there may
be even harder cases, like "no sequence of repeating characters"
or like "at least 2 "special" character, but not twice the same one".
Aside, there is RFC 7613 "Preparation, Enforcement, and Comparison of
Internationalized Strings
Representing Usernames and Passwords" and it may be a good
idea to reference it or derive from it. Note specifically sections 3.5 and
4.2.2 (that touches the other point raised about handling spaces, etc.)
And I do not even touch things like:
- checking if the password does not contain a known word for some definition of
word in some dictionaries
- checking if the password does not match any given leaked passwords (why not?
some websites are already adding in their signup/login process a check if the
password is among the list of leaked ones)
- not reusing one of the X previously used password, or one of the previous
passwords slightly changed like reversed or appended with 1, etc.
Also, related, I would be interested into works that goes into the direction of
not having to exchange the password in the clear at all (even if we are inside
TLS), because the server does not need to have the client to send it, just to
make sure it can prove it has it, and there are various mechanims existing for
that (but they may be complicated to port to EPP as they may need further
exchanges besides our current greeting/login).
Like SRP and the example of RFC5054 "Using the Secure Remote Password (SRP)
Protocol for TLS Authentication".
Or at least, like I suggested on the policy extension, but that was not meant
with a lot of enthusiasm, to implement SASL instead of the current purely
login+password, so that at least other methods of authentication could be
plugged in.
--
Patrick Mevzek
[email protected]
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
