[precis] Fwd: Re: [http-auth] http-auth BOF

[Peter Saint-Andre <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Of interest regarding SASLprep...


- -------- Original Message --------
Subject: Re: [http-auth] http-auth BOF
Date: Mon, 17 Sep 2012 12:31:16 +0900
From: "Martin J. Dürst" <[e-mail]>
Organization: Aoyama Gakuin University
To: KIHARA, Boku <[e-mail]>
CC: Peter Saint-Andre <[e-mail]>,
"[e-mail]" <[e-mail]>

I wanted to make exactly the same comment as Mr. Kihara.

To give a simple example, when inputting the character/word "flower",
most Japanese would type the four keys 'h', 'a', 'n', 'a', which simply
corresponds to the pronunciation of that word, "hana". This is then
converted to syllabic writing "はな", and from there to the actual
character for flower, "花", as it would be used in everyday writing.
However, there are other characters that are pronounced "hana", such as
"華" (a variant character for flower), "鼻" (nose), and so on. To select
the correct character, various keys (space, arrow keys, number keys,
return,...) are used. To make sure the right character is selected, the
user has to *visually* check (-> shoulder attack) and confirm it.

As a result, as Mr. Kihara already explained, these characters are not
used for passwords in Japanese. Because the same homophone problem for
Han characters applies in Chinese and Korean, the situation is the same
there.

In terms of entropy, Han characters would indeed contribute a lot, but
because they require visual checking when entering, they are in general
not suited for passwords.

Regards,    Martin.

On 2012/09/15 3:35, KIHARA, Boku wrote:
> 2012/9/15 Peter Saint-Andre<[e-mail]>:
>> On 9/14/12 9:09 AM, KIHARA, Boku wrote:
>>> <off-topic>  I heard a discussion about i18n of passwords:
>>> about Chinese characters (of course used in Japan too), there
>>> are many characters that have the same pronunciations so they
>>> are input by input method software. Users type sentences in
>>> latin characters (such as pinyin and roma-ji) then pick
>>> intended characters from candidates. When inputting passwords,
>>> typically input method software are disabled and userstype
>>> unconverted characters. As a result, passwords become within
>>> ascii range. The problem might be more noticeable in non-ascii
>>> locales where characters are input directly from keyboards.
>> 
>> Hello Kihara-san,
>> 
>> Could you please clarify what you mean by "unconverted
>> characters"? It seems that you mean these are characters from the
>> ASCII range not converted into their CJ equivalents, but I'd like
>> to make sure.
> 
> Exactly. I meant they are ASCII characters that are not processed
> by input method software. In Japan, the input process is often
> called "Kanji Henkan" (Chinese characters conversion) so I used the
> word.
> 
>>> By the way, I think i18ning passwords in at least CJ locales
>>> will cause another problem that conversion process can be
>>> vulnerable to shoulder attacks :<
>> 
>> When you say "i18ning passwords", do you mean allowing
>> characters outside the ASCII range?
>> 
>> Of course, we like to enable lots of entropy in passwords, so
>> limiting the allowable characters to the ASCII range would be at
>> odds with that desire.
> 
> By all means passwords should become more secure and allowing
> non-ASCII characters is very good way. I only intended to notice
> that there may be issues to be solved and I am sorry if my message
> was misleading.
> 
>> By the way, some of these considerations are relevant to SASLprep
>> (RFC 4013) and its proposed replacement 
>> (draft-melnikov-precis-saslprepbis), so I hope you will review
>> the latter specification and provide feedback on the
>> [e-mail] and [e-mail] lists. :)
> 
> Sure. I hope my little knowledge can help...:<
> 
> Regards, Boku KIHARA 
> _______________________________________________ http-auth mailing
> list [e-mail] 
> https://www.ietf.org/mailman/listinfo/http-auth
> 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBXRT0ACgkQNL8k5A2w/vyBnQCgqHqmsFLuNJIPqa6YzeQVHotc
8xMAni0OJ+lRavA1CHfc5m+H5imQ+87U
=+6Ex
-----END PGP SIGNATURE-----