2015-10-06 21:57 GMT+02:00 Richard Wordingham < richard.wording...@ntlworld.com>:
> It's an interesting issue for a password that one can't type. It's by > no means a guarantee, either. I once specified a new a password that > changed case in the middle not realising that I had started with caps > lock on. Consequently, both copies has the wrong capitalisation. I > was using a wireless keyboard, which to conserve battery power doesn't > have a caps lock indicator. (In the old days, caps lock would have > physically locked, but that's not how keyboard drivers work nowadays.) > It took a little while before it occurred to me that I might have had a > problem with caps lock. > This is a demonstration that using case differences to add more combinations in short passwords is a bad design. As well hiding typed input is not a good idea: we need at least a pressable button to look/confirm what we are typing. Instead of lettercase combinations limited to ASCII, it is highly preferable to extend the character repertoire to Unicode and accept letters in NFKC form and unified by case folding (NOT conversion to lowercase or uppercase, as it is not stable across Unicode versions). So we should define here the usable set of characters (and define characters that should be ignored and discarded if present on input). This should be a profile in UAX #31 (and we should issue a strong warning against the recent RFC that forgot the issue : its case-insensitive profile based on NFC and conversion to lowercase is definitely broken !)