Subject: [http-auth] http-auth BOF

From: Sean Turner <[email-masked]>
Date: Tue, 11 Sep 2012 10:05:18 -0400

As you're no doubt aware, http-bis chucked the http-auth mechanisms out 
in Vancouver.  I'd like to have a forum to discuss http-auth options and 
ultimately publish them.  One idea is to create a WG in the security 
area and publish the proposals on the experimental track.  There's four 
that I've seen (in no particular order):

- draft-oiwa-*
- draft-farrell-httpbis-hoba
- draft-melnikov-httpbis-scram-auth
- draft-williams-httpbis-auth-classification

Does this sounds like a plan?  If it does, then let's chat about it here.

spt

PS - One of things I'd need to get a BOF going is for somebody [1] to 
ask for a BOF.  I'd be best if more than one author set asked too.

[1] In this instance Stephen F. doesn't count ;)

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Sep 2012 16:10:50 +0200

> ask for a BOF.  I'd be best if more than one author set asked too.

+1 in general.

<brokenrecord>
But let's fix I18N in Basic auth: 
http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html
</brokenrecord>

<brokenrecord>
But let's browsers to provide logout() functionality via Javascript
</brokenrecord>

Best regards, Julian

---

From: Sean Turner <[email-masked]>
Date: Tue, 11 Sep 2012 10:37:25 -0400

I knew I'd leave at least one off.  We should add the following to the list:

- draft-ahrens-httpbis-digest-auth-update

spt

On 9/11/12 10:05 AM, Sean Turner wrote:
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 12 Sep 2012 00:02:09 +0300

>> ask for a BOF.  I'd be best if more than one author set asked too.

+1 as well.

> http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html

Why do we need to fix sending your password in the clear?

> But let's browsers to provide logout() functionality via Javascript

Logout is terminating a session. Do we have a definition of "session" that's different from "the lifespan of a session cookie"? What would you want the javascript to do, and how can you tell that it's doing it?

Yoav

---

From: Tim <[email-masked]>
Date: Tue, 11 Sep 2012 15:29:50 -0700

> Logout is terminating a session. Do we have a definition of "session" that's different from "the lifespan of a session cookie"? What would you want the javascript to do, and how can you tell that i…

Yeah, I kinda thought we had settled on making this part of HTTP,
either through new auth protocols more more generally.  This doesn't
preclude doing it in JavaScript as well (as nonstandard
extensions/apis already allow), but doing it at a lower level will
allow logouts to work for non-JavaScript aware clients.

tim

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Sep 2012 17:41:27 -0500

On Tue, Sep 11, 2012 at 9:05 AM, Sean Turner <[email-masked]> wrote:
> As you're no doubt aware, http-bis chucked the http-auth mechanisms out in
> Vancouver.  I'd like to have a forum to discuss http-auth options and
> ultimately publish them.  One idea is to create a WG in the security area
> and publish the proposals on the experimental track.  There's four that I've
> seen (in no particular order):
>
> - draft-oiwa-*

Actually, please include draft-williams-http-rest-auth (RESTauth,
successor to REST-GSS) and remove
draft-williams-httpbis-auth-classification.

(No one seems interested in
draft-williams-httpbis-auth-classification.  Whereas there is some
interest in RESTauth (some in the IETF and at least one party outside
interested in deploying it in the enterprise.)

Nico
--

---

From: Yutaka OIWA <[email-masked]>
Date: Wed, 12 Sep 2012 11:00:43 +0900

Dear all,

> Does this sounds like a plan?  If it does, then let's chat about it here.

+1.  Really good points to start.

> PS - One of things I'd need to get a BOF going is for somebody [1] to ask
> for a BOF.  I'd be best if more than one author set asked too.

Is it meaning I should raise the hand explicitly? (^_^)/

-- 
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]

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Sep 2012 09:02:08 +0200

> Why do we need to fix sending your password in the clear?

Because it's widely used with TLS and causes real-world interop problems.

> Logout is terminating a session. Do we have a definition of "session" that's different from "the lifespan of a session cookie"? What would you want the javascript to do, and how can you tell that i…

What do cookies have to do with this?

The problem with HTTP authentication as of today is that there's no 
well-defined, interoperable way to stop the browser sending the 
credentials you entered. Again, this is a real-world problem that stops 
people from using HTTP auth in the first place.

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Thu, 13 Sep 2012 00:46:03 +0300

> Because it's widely used with TLS and causes real-world interop problems.

Strange. I never see them. In GMail, Facebook, CNN and bank websites you only see form-based authentication. And those forms work well with internationalization.

> What do cookies have to do with this?

You don't see a lot of websites that ask for the credentials with every request. They ask for them once (usually via a form), and plant a session cookie to remember you by. Do this on a public computer, and the next person comes in and is still logged on as you.

> people from using HTTP auth in the first place.

I see. Good point.

But adding this to Javascript does not show the user that it's happened. How do I know that the function has been run?

Seems to me that the "session", whether it's tied to a cookie, to cached credentials, or to a new field in http/2.0 should be indicated in the browser, and that log out should be time-based, explicit, or based on browsing elsewhere.

Yoav

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Sep 2012 00:00:21 +0200

> Strange. I never see them. In GMail, Facebook, CNN and bank websites you only see form-based authentication. And those forms work well with internationalization.

Form based auth doesn't work with programmatic clients.

If you're happy with form-based auth, why are you even interested in 
HTTP authentication?

> You don't see a lot of websites that ask for the credentials with every request. They ask for them once (usually via a form), and plant a session cookie to remember you by. Do this on a public comp…

That's cookie-based authentication, not HTTP authentication. I thought 
we're discussing the latter.

> Seems to me that the "session", whether it's tied to a cookie, to cached credentials, or to a new field in http/2.0 should be indicated in the browser, and that log out should be time-based, explic…

Maybe. We need to come up with a list of things that need to happen to 
make HTTP auth usable in practice. I'm aware of the UI issue (skinning 
the login), and the logout problem. What else is needed?

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 13 Sep 2012 10:20:03 +0900

Hi Julian,

2012/9/13 Julian Reschke <[email-masked]>:

> Maybe. We need to come up with a list of things that need to happen to make
> HTTP auth usable in practice. I'm aware of the UI issue (skinning the
> login), and the logout problem. What else is needed?

I had some strawman analysis (maybe not complete yet...) and
summarized (as a protocol) in
https://datatracker.ietf.org/doc/draft-oiwa-http-auth-extension/ .
Maybe for this thread, it worth reading just a TOC of this draft.

I put my goal on enabling current Form-and-cookie based Websites to use
HTTP-based authentication.
My current requirement list entries are:

 * Optional authentication (concurrent support for guest / authenticated users)
 * Redirection on unauthenticated cases only
 * Redirection hook on log-out
 * Timer-based expiration of authentication session
   (including 0-second "immediate" logout)

First two things may be replaced by use of WWW-Authenticate headers
with several non-401 statuses, but we will need more compatibility
analysis of existing clients. In any way, we need "standardization" here.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 13 Sep 2012 13:04:09 +0300

> we're discussing the latter.

They're not mutually exclusive. You can authenticate every single request, or you can authenticate once, and then the server can associate the session cookie with you identity, and use the cookie to authenticate subsequent requests. It makes no difference if the single authentication was part of TLS, part of HTTP, or form-based. If we adopt some kind of ZKPP where you need to perform public key operations for each authentication, extending the authentication to subsequent requests may be very attractive. I don't know if cookies as they are defined today are the appropriate way, but then logout becomes as simple as deleting the cookie.

> the login), and the logout problem. What else is needed?

I think the big security issue is how I can tell the Facebook login page (where I'm supposed to enter my credentials) to the phisher's website that looks exactly the same, where I'm not supposed to. ZKPP in Javascript doesn't help, because the phisher can create a page that looks exactly the same and has plain text fields.

Yoav

---

From: Leif Johansson <[email-masked]>
Date: Thu, 13 Sep 2012 12:49:20 +0200

On 09/11/2012 04:05 PM, Sean Turner wrote:
> As you're no doubt aware, http-bis chucked the http-auth mechanisms
> out in Vancouver.  I'd like to have a forum to discuss http-auth
> options and ultimately publish them.  One idea is to create a WG in
> the security area and publish the proposals on the experimental
> track.  There's four that I've seen (in no particular order):
> 
> - draft-oiwa-* - draft-farrell-httpbis-hoba -
> draft-melnikov-httpbis-scram-auth -
> draft-williams-httpbis-auth-classification
> 

What about Negotiate? Its already an informational RFC but I have
a hunch that work has been done on it since it was published.

Somebody should ask (nudge-nudge) MSFT...

	Cheers Leif

---

From: Nico Williams <[email-masked]>
Date: Thu, 13 Sep 2012 11:19:26 -0500

> Strange. I never see them. In GMail, Facebook, CNN and bank websites you only see form-based authentication. And those forms work well with internationalization.

Agreed.

The problems with passwords over forms are not interop ones, they are
security ones:

 - servers store hashes that are relatively easy to steal and then
brute-force with offline dictionary attacks;

 - this method (passwords in forms POSTed over HTTPS) is 100%
dependent on a very fallible TLS server PKI;

 - all too often the form is sent over HTTP, not HTTPS, so all too
often there's no real security in the first place.

>> people from using HTTP auth in the first place.

Any solution that's not entirely in the hands of the server (and
therefore entirely dependent on the TLS server PKI) will require
*proper* integration into the browser, *including* proper logout
support, and UI indications of whether the user is logged in, and with
what identity.  If this is not possible then we must give up on HTTP
authentication (for the browser anyways).

> But adding this to Javascript does not show the user that it's happened. How do I know that the function has been run?

In my conception there are native JavaScript interfaces to SASL or
whatever, and when authentication succeeds the browser will indicate
this to the user via some UI element (kinda like the old lock icon).
I understand that browser folks have all but given up on such UI
elements, and that there's full screen apps to worry about, and so on,
but I don't think these are issues that cannot be overcome.

> Seems to me that the "session", whether it's tied to a cookie, to cached credentials, or to a new field in http/2.0 should be indicated in the browser, and that log out should be time-based, explic…

Indeed!

Nico
--

---

From: Harry Halpin <[email-masked]>
Date: Thu, 13 Sep 2012 18:52:53 +0200

> authentication (for the browser anyways).

Before we give up depression over this, I will add the W3C would like to 
help the IETF in this effort.  The main issue holding us back is that 
there is no draft scheme that the major browser vendors support right 
now. However, we will try to have this discussion at W3C TPAC on Oct 
31st (and thus shortly before Atlanta IETF BoF) to see if we can invoke 
interest in this topic again.

In essence, I think most of us agree there just has to be some way for 
the browser to create in sort of "chrome pop up" so that whatever 
happens in that "chrome pop up for login" gets encrypted and shipped out 
to the JS, with the plaintext never seen by the JS, and of course better 
than HTTP Digest/Basic. Also, ideally this login can happen outside the 
browser (say at OS login)  and then be shared with the browser.  
However, we are unlikely to get UI co-ordination in the chrome across 
browser vendors. Yet, we can specify that *something* needs to happen in 
the chrome that requires *user interaction* and then make sure every 
browser supports that *something* in test-cases.

So I agree none of these problems are insurmountable. Also, I would add 
that this is larger problem than just rewriting HTTP Auth, as what is 
really needed is a superior identity/session manager (although how to do 
that while avoiding user confusion is tricky) so that a user can keep 
track of where they are logged in, and one would want to provide some 
kind of identity management API that could then be used by WebApps that 
need to figure out a user's identity. Furthermore, this session 
information should be portable across browsers.  However, given that 
this already happens in Android, that session management APIs already 
exist in Mozilla, and that similar work can happen with WebIntents, and 
that its a clear and pressing need, I think we should move on the issue. 
I'd like to see one solution that's actually mature and implemented 
across browsers, and again, if there's a clear proposal, we will be more 
than happy to help on the API/browser front. I'm not sure if there's any 
possible relationship to the WebCrypto API, but that work is going 
nicely and FPWD should be published later today [1].

   cheers,
     harry

[1] http://www.w3.org/2012/webcrypto/WebCryptoAPI/

---

From: Nico Williams <[email-masked]>
Date: Thu, 13 Sep 2012 12:16:22 -0500

> Before we give up depression over this, I will add the W3C would like to

Heheh, well, I wasn't assuming that the above was impossible.  (I
think you meant give into depression.)

> help the IETF in this effort.  The main issue holding us back is that there
> is no draft scheme that the major browser vendors support right now.

Right.  This is key.

> However, we will try to have this discussion at W3C TPAC on Oct 31st (and
> thus shortly before Atlanta IETF BoF) to see if we can invoke interest in
> this topic again.

I guess I should head out there.

> In essence, I think most of us agree there just has to be some way for the
> browser to create in sort of "chrome pop up" so that whatever happens in
> that "chrome pop up for login" gets encrypted and shipped out to the JS,

Excellent news!  Now we need the browser folks to agree too :)

Nico
--

---

From: Cameron Jones <[email-masked]>
Date: Thu, 13 Sep 2012 19:00:56 +0100

>> Strange. I never see them. In GMail, Facebook, CNN and bank websites you only see form-based authentication. And those forms work well with internationalization.

Disagree. Facebook, Gmail and banks do not the internet make.

There are valid uses for using unsecured BASIC which are not your 1st
class websites which everyone is concerned with.

The benefits of BASIC are that is is trivial to implement, has
existing widespread support in browsers and servers, and can be made
'secure' with TLS. The problem which has been highlighted is that it
requires the necessary encoding to be universally applicable. There
are CJKV users who use their own language characters as passwords. It
would be nice to be able to decode these reliably and then we can just
ignore BASIC for ever more and get on to developing more secure
methods.

> often there's no real security in the first place.

Existing form-based password authentication is the worst possible
situation so anything which stops people needing to use this method is
a huge win, including even just an upgrade to BASIC over HTTP as at
least the password won't be sent in completely plain-text, although
that gain is relatively marginal.

>>> people from using HTTP auth in the first place.

There is a proposal in HTML5 for enhancing form support of HTTP which
includes 'mapping' username\passwords into the same XHR.open()
functionality. Also included is a method for clearing the auth cache
on successful response which integrates with a HTTP request for server
notification and cookie clearing:

http://www.w3.org/wiki/User:Cjones/ISSUE-195

This approach does not require producing a heavy new specification for
browsers to implement and instead lends the HTML methodology of
providing simple, high-level semantics which can be interfaced within
the site and applicable to virtually any authentication scheme.

Thanks,
Cameron Jones

---

From: "KIHARA, Boku" <[email-masked]>
Date: Sat, 15 Sep 2012 00:09:20 +0900

2012/9/14 Cameron Jones <[email-masked]>:
> The problem which has been highlighted is that it

<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.

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 :<
</off-topic>

Regards,
Boku KIHARA

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 14 Sep 2012 09:25:23 -0600

On 9/14/12 9:09 AM, KIHARA, Boku wrote:
>> The problem which has been highlighted is that it requires the
>> necessary encoding to be universally applicable. There are CJKV
>> users who use their own language characters as passwords. It 
>> would be nice to be able to decode these reliably and then we can
>> just ignore BASIC for ever more and get on to developing more
>> secure methods.
> 
> <off-topic> I heard a discussion about i18n of passwords: about
> Chinese characters (of course used in Japan too), there are many 
> 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.

> 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 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-masked] and
[email-masked] lists. :)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Sep 2012 17:39:02 +0200

On 2012-09-12 23:46, Yoav Nir wrote:
> ...

tools.ietf.org

w3.org

my company's internal pages

...

It's not as nearly widely used as form-based login, but that doesn't 
mean it's not widely used.

Best regards, Julian

---

From: Cameron Jones <[email-masked]>
Date: Fri, 14 Sep 2012 16:50:56 +0100

> another problem that conversion process can be vulnerable to shoulder

Good points. I don't actually speak (or type) asian languages so
identifying them was purely for illustratory purposes. The point i was
making was that ASCII-only is a limitation we could do without based
on the scope of foreign languages.

There do seem to be some hurdles with the application of the charset,
partly that it won't be retroactive so there will always some level of
need to manage the decoding. I was initially concerned with the
potential to use this as an attack vector, but since BASIC is only
sending base64 it's not supposed to be a full-proof security method on
it's own, only an authentication method, so providing some extra
support in this area is an enhancement for error mitigation. I can't
see any danger and maybe in future with greater device support for
localized character input it may become even more important to have
this support.

I also forgot to mention that since this thread was about the BoF, i
will sadly be unable to make it to Vancouver but i hope that this is
one area that can be discussed by those who can.

Thanks,
Cameron Jones

---

From: Cameron Jones <[email-masked]>
Date: Fri, 14 Sep 2012 19:09:46 +0100

> one area that can be discussed by those who can.

I misread the reference to Vancouver as the suggested location for the
BoF, so perhaps i may make it if\when\where the BoF takes place (i
don't make it down from the Scottish glens and across the English
channel much these days, lest the Atlantic and the Canadian prairies
:)

Thanks,
Cameron Jones

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 14 Sep 2012 12:18:06 -0600

On 9/14/12 12:09 PM, Cameron Jones wrote:
>> I also forgot to mention that since this thread was about the
>> BoF, i will sadly be unable to make it to Vancouver but i hope
>> that this is one area that can be discussed by those who can.
>> 
> 
> I misread the reference to Vancouver as the suggested location for
> the BoF, so perhaps i may make it if\when\where the BoF takes place
> (i don't make it down from the Scottish glens and across the
> English channel much these days, lest the Atlantic and the Canadian
> prairies :)

If approved, the proposed BoF will take place at IETF 85 in Atlanta
(November 4 - 9, 2012), although remote participation will be possible
as well.

http://www.ietf.org/meeting/85/

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Cameron Jones <[email-masked]>
Date: Fri, 14 Sep 2012 19:21:33 +0100

On Fri, Sep 14, 2012 at 7:18 PM, Peter Saint-Andre <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Good to know, thanks!

Cameron Jones

---

From: "KIHARA, Boku" <[email-masked]>
Date: Sat, 15 Sep 2012 03:35:41 +0900

> 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.

> the allowable characters to the ASCII range would be at odds with that

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.

> [email-masked] lists. :)

Sure. I hope my little knowledge can help...:<

Regards,
Boku KIHARA

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 17 Sep 2012 12:31:16 +0900

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-masked]>:

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Sep 2012 01:53:09 -0500

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

Solutions:

 - require partial echo on for password entry (like on many mobile devices)
 - require audio feedback (such as sight-impaired users might use)
 - recommend that passwords be comprised of a sub-set of Unicode that
   can be input on most devices without visual feedback.

IMO partial echo on is the only sufficiently general solution.  And
it's already the rule, not the exception, in the world of mobile
devices.

> because they require visual checking when entering, they are in general not
> suited for passwords.

The key is total entropy for the whole password, not entropy density.
That CJK might use 17 bits more efficiently than ASCII uses 7 (8,
really, since we don't try to pack ASCII codepoints more tightly than
one per-octet) is not enough.  (Of course, UTF-8 is not that
efficient.)  That CJK speakers might more easily recall high-entropy
passwords due to the use of visual memory (say) would be very
interesting indeed, but that's not something we'd have an easy time
grafting onto users of western scripts.

If it turns out that it's easier for users to recall high-entropy
passwords with echo on, would we choose to give up on protection
against shoulder surfing?  I think I would, yes.

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 17 Sep 2012 09:43:28 -0600

Thanks to you both for the helpful explanation!

On 9/16/12 9:31 PM, "Martin J. Dürst" wrote:
> 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.
> 
>>>> <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-masked] and [email-masked] lists. :)
>> 
>> Regards, Boku KIHARA 
>> _______________________________________________ http-auth mailing
>> list [email-masked]

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 18 Sep 2012 15:51:31 +0900

>   - require partial echo on for password entry (like on many mobile devices)

Interesting that this is done on mobile devices. I guess the "over the 
shoulder" problem may be slightly different for (small) mobile devices 
than for e.g. PCs with big displays.

>   - require audio feedback (such as sight-impaired users might use)

Except for very special feedback (which I assume exists for 
sight-impaired users), this won't help. The underlying problem is 
homophones (a typical English example is "sun" vs. "son"), so 
pronouncing them doesn't show a difference.

>     can be input on most devices without visual feedback.

That's a recommendation that's easy to make but difficult to implement. 
There's no easily defined or definable subset of writing Japanese (or 
Chinese) that doesn't contain homonyms.

> grafting onto users of western scripts.

The problem isn't about easier recall with visual memory. Even without 
seeing the characters in any way, the average user may be perfectly able 
to remember whether s/he used the character for "flower" or for "nose" 
in the password.

The problem isn't memory, the problem is to make sure that the right 
character is input in the password field. For some words, the 
probability that this happens is quite high. Imagine having "flower 
garden" as a password. "nose garden" makes much less sense, and so the 
input conversion engine will select "flower garden" rather than "nose 
garden" with high probability. But because the input conversion engine 
will try to use all kinds of information from general language knowledge 
and previous inputs by the user, the results are never guaranteed. Also, 
if users are pushed to rely on the "most probable" conversion, that will 
lead to words and phrases with low entropy.

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.)

> against shoulder surfing?  I think I would, yes.

The premise doesn't apply.

Regards,   Martin.