-----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" <[email protected]> Organization: Aoyama Gakuin University To: KIHARA, Boku <[email protected]> CC: Peter Saint-Andre <[email protected]>, "[email protected]" <[email protected]> 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<[email protected]>: >> 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 >> [email protected] and [email protected] lists. :) > > Sure. I hope my little knowledge can help...:< > > Regards, Boku KIHARA > _______________________________________________ http-auth mailing > list [email protected] > 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----- _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
