Re: [http-auth] http-auth BOF

["Martin J. Dürst" <[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
>