Re: Unicode in passwords

From: Philippe Verdy <verdy_p_at_wanadoo.fr>
Date: Thu, 8 Oct 2015 18:14:38 +0200

They demand such passwords only for their web services, which are accessed
by web browsers. Not for booting devices. Being on the web, the protocols
are based on HTML and web browsers. As the web is now Unicode with UTF-8 in
a vast majority of contents, those web services are already UTF-8 ready (it
is also a requirement on those web insterfaces used by banks to have
javascript support).
So restricting those web passwords to only ASCII is a bad choice : to
extend the usable charset, forcing the inclusion of ASCII capitals and
punctuation is not sufficient, There is certainly a better way to extend
the set to include as well all characters supported by browser input
methods for the targeted languages, and that are still easy to type in on
most devices (this means not adding characters not suppoted by old versions
of Windows or by basic smartphones).

With an extended repertoire (not restricted to ASCII, thanks to UTF-8 on
the web), password lengths could remain relatively short and easy to type
and remember

(the alternative using passphrases also requires being able to type words
in the local language in its basic orthography, and some compatibility
normalization, as well as case folding will be helpful to provide good
interoperability across client devices, where typing letters with mised
case is frequently very inconvenient on touche devices, as well for people
with disabilities and that type with only one finger).

Still, there are still many banks whose passwords are limited to only basic
decimal digits, and limited to at most 8 of them.
As this is not enough, the input forms will also request other numbers that
people frequently cannot easily remember. others will use two-factor
authentication using mobile phones and confirmation codes sent by SMS, or
will send an additional code in physical letters, they will take footprints
of the browser or IMEI code of the smartphone used and preapproval required
before trusting devices, or giving the number of a physical credit card by
procesing a ¤0.00 online payment with it, and some pseudo "secret"
questions (social security number, identity card/passport/driver licence
number...) but some are very week and ask for something that is rarely
secret such as the birth date (Facebook initially published it by default
to anyone without asking when you create the account, now it is private by
default, except for the birthday application enabled by default and
notifying all "friends". But too late for those that had created their
account years ago, it is now public for eternity even if it can be hidden
on the current version of profiles... similar fake secrets are names of
family members and pets, as all the info is)

2015-10-07 18:10 GMT+02:00 Doug Ewell <doug_at_ewellic.org>:

> Philippe Verdy wrote:
>
> > This is a demonstration that using case differences to add more
> > combinations in short passwords is a bad design.
>
> But more and more organizations and banks and supermarket rewards
> programs are demanding it, along with "at least one digit" and "at least
> one 'special' character" and "at least N characters in length" and "must
> change every N days" -- regardless of what Bruce Schneier or anyone else
> says.
>
> --
> Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸
>
>
>
>
Received on Thu Oct 08 2015 - 11:17:03 CDT

This archive was generated by hypermail 2.2.0 : Thu Oct 08 2015 - 11:17:03 CDT