Re: Unicode in passwords

NFC is probably not the best choice for passwords. It should probably be
NFKC

Look also in the recent proposed update for UAX #31, and consider the
special case where an application does not want passwords to be
case-significant, but accepts using something else than just ASCII letters:
it will be then necessry to apply some closure for NFKC.
Finally note that passwords are not necessarily single identifiers
(whitespaces and word separators are accepted, but whitespaces should
require special handling with trimming (at both ends) and compression of
multiple occurences. It would also be necessay to make sure that acceptable
passwords at least begin with an XID_Start character.

May be all this discussion could be a new section in UAX #31 to take into
account the possible presence of whitespaces (for "pass phrases" which are
not really "identifiers") in "Medial" positions : define a profile as
described in UAX #31 to add whitespaces in "Medial" and remove them from
excluded characters, and possibly extend the set of "Start" to more than
just XID_Start (e.g. you could use some punctuation like '!' or
mathematical sign like '+', and possibly also accept non-decimal digits
that are preserved after NFKC closure)

2015-10-05 17:12 GMT+02:00 Stephane Bortzmeyer <bortzmeyer_at_nic.fr>:

> On Wed, Sep 30, 2015 at 04:15:30PM -0700,
> Clark S. Cox III <clarkcox3_at_gmail.com> wrote
> a message of 73 lines which said:
>
> > You really wouldn’t want “Schlüssel” and “Schlüssel” being different
> > passwords, would you? (assuming that my mail client and/or OS is not
> > interfering, the first is NFC, while the second is NFD)
>
> Hence the RFC 7613, mentioned already here by Marc Blanchet, that you
> must really read if you're interesed in Unicode passwords.
>
> In that case, the RFC is clear: NFC mandatory (and UTF-8 encoding).
>
> 4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be
> applied to all characters.
>
>
Received on Mon Oct 05 2015 - 19:09:50 CDT