Re: [http-auth] http-auth BOF

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

Thanks to you both for the helpful explanation!

On 9/16/12 9:31 PM, "Martin J. Dürst" wrote:
> 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<stpeter@stpeter.im>:
>>> 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
>>> precis@ietf.org and kitten@ietf.org lists. :)
>> 
>> Sure. I hope my little knowledge can help...:<
>> 
>> Regards, Boku KIHARA 
>> _______________________________________________ http-auth mailing
>> list http-auth@ietf.org 
>> 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/

iEYEARECAAYFAlBXRSAACgkQNL8k5A2w/vxfgQCfQl0TqTIQex9LRc8MpaROTxQ5
T7IAoNN3btWWwZC84ys15thBxPae3Ph8
=EKh/
-----END PGP SIGNATURE-----