Unicode in passwords

[Philippe Verdy]

Also some people may want to use now emojis within their passwords or pass
phrases (they are now very common on most smartphones and layouts for
tactile screens or in instant messaging applications used on desktops,
using mouse clicks or taps for selecting them). But I would not recommend
them for encrypting bootable disks or in BIOS/UEFI boot environments
without support for extended input methods and rich graphics to render them
on basic text consoles, unless they are part of a national encoding
standard and supported natively).

For boot environments, you'll be limited by the local hardware support, but
if there's such a support (keyboard or font), it may be helpful to include
some extra symbols, to block remote accesses without this native support
(e.g. on Japanese systems, you could use the extra keys found only on
Japanese keyboards and you won't be able to control the system without the
appropriate device recognized in the booting environment).

2015-10-06 2:08 GMT+02:00 Philippe Verdy <verdy_p at wanadoo.fr>:

> 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.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20151006/f52ac296/attachment.html>