Subject: [http-auth] Problems with passwords in various locales (was Re: http-auth BOF)

From: "KIHARA, Boku" <[email-masked]>
Date: Tue, 18 Sep 2012 23:10:02 +0900

2012/9/18 "Martin J. Dürst" <[email-masked]>:
> In addition, because past input statistics are shared among applications on
> the same system, there's some danger that this information may leak.
> (Similar things may be possible on a mobile device if input prediction is
> on, for any kind of language.)

Some problems including the above will be solved by introducing
identity managers that input strong and memorable passwords on
behalf of users. In normal cases managers input passwords so
characters won't seen and conversion histories won't be stored.
Of course this does not apply when identity managers are not
configured.

Protection of identity managers? More problematic...
(More frequent conversion, more priority in conversion,
more vulnerability...)

By the way, current password fields in major systems have strange
behavior on input method softwares and characters in (at least)
Japanese. They disable input method softwares and force ASCII
characters for passwords. However, they also accept pasting
the contents of clipboard. As a result, people who use Chinese
characters (limited at this moment) may use other text fields
or editors as temporary working area.

Regards,
Boku KIHARA

---

From: Yutaka OIWA <[email-masked]>
Date: Wed, 19 Sep 2012 12:28:47 +0900

Dear http-auth people,

If we completely rely on identity managers,
we do not need localized "passwords".
Longer ASCII random tokens can provide enough entropy.
Localization of passwords means that we should work with
human users.
# Localization of IDs is important for both cases, of course.

The most strong point of passwords is portability: whenever we needed,
we can memorize it in our brains, or write it on a small piece of paper
(and burn it using lighters after its use: easier and reliable than
eliminating contents on harddisks!).
For this purpose, we need properly defined semantics for
canonicalizations of passwords and IDs.  If we have more than two
binary representations for a single "human-recognizable" IDs or
passwords, the whole authentication systems will not work.

Unicode has a lot of messes, and just specifying it "UTF-8"
will not solve the problem. We will definitely need to quote
precis WG outcomes.

P.S.
Also, as a Japanese, I may need to clarify some of our needs
and situations for Western people:
we do *not* have virtually any difficulty on memorizing or
recognizing two ideographs of similar sounds in passwords ,
as far as we generate it by humans ourselves.  As western people
will not likely to confuse on Q and K for the same sounds,
we will never confuse on noses and flowers.
# Of course, we may sometimes confuse on similarly-looking
# characters written down on papers, as Western people
# do in 1-I-l or u-v.

The problem on Japanese (and Chinese, possibly) is
to input them into computers reliably without visual or other feedbacks.
Same sequences of typed keys will produce different sequences of
characters from time to time, as IMEs use intelligences to provide
the best-possible guesses to optimize the input time.
# Imagine if you input ASCII passwords using mobile phones,
# where the system "optimizes" and changes the order of characters
# appear on key "2" in order of most-frequent use from time to time,
# like a-c-A-b-B-C or c-a-A-C-B-b.

That is why most Japanese people just use ASCII passwords,
even if systems allows ideographs.  Japanese has already
accustomed to use ASCII characters for passwords.
We will still need I18n on authentications, but mainly for the ID side.
Situations may be different  for Korean-speaking people,
as their main characters (hangeuls) can be mapped to
fixed sequences on keyboards.

## <off-topic>we Japanese do have some direct input systems for
## ideographs using 2 to 4 strokes for 1 character:
## 3-combinations of 40 keys will provide 64000 possibilities...
## The difficulty of that system is to memorize a key sequence
## for every one of >10000 ideographs to input.</off-topic>

2012/9/18 KIHARA, Boku <[email-masked]>:
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]