Subject: Re: [saag] internationalized passwords

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 18 Oct 2011 11:51:40 -0600

On 9/6/11 10:45 PM, Mouse wrote:
>>> it's quite obvious to me that Unicode must be supported.
>> I'm happy to hear it. :)
> 
> I'm not entirely clear what the context here is, but you might want to
> at least consider that you'd be repeating the ssh mistake if you make
> this a MUST.  (ssh, as specified, is unimplementable on some Unix
> variants, and quite possibly other OSes, because some things which the
> RFCs say MUST be in UTF-8, such as usernames or passwords, exist in the
> system as octet strings rather than character strings and thus
> inherently cannot be recoded.  That ssh comes as close to working as it
> does is a testament to ASCII's ubiquity.)

As I see it, the PRECIS WG is not mandating, and could not mandate, that
any given application technology MUST support non-ASCII passwords.
Instead, it's giving protocol designers a common tool for preparing and
comparing passwords (and other strings) containing Unicode characters,
if they choose to support such things.

Peter

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Oct 2011 14:42:03 -0500

> it's quite obvious to me that Unicode must be supported.

Agreed.

I think it will be a long time yet before users can reliably enter
non-ASCII passwords on all their operating systems and applications on
all their devices.  But that's no reason not to specify how compliant
implementations would achieve this.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Oct 2011 14:47:31 -0500

> does is a testament to ASCII's ubiquity.)

I see nothing wrong with a protocol spec saying that passwords MUST be
UTF-8 with such and such processing.  Sure, some implementations will
fail to comply, but applications that cannot handle Unicode as
specified should a) just never allow non-ASCII passwords to be set, b)
otherwise just-use-8 (so as to help interop, if accidentally, with
implementations that do support Unicode as specified and where users
have non-ASCII passwords set.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Oct 2011 14:52:23 -0500

On Tue, Sep 6, 2011 at 4:25 PM, Peter Saint-Andre <[email-masked]> wrote:
> On 9/6/11 3:04 PM, Yaron Sheffer wrote:
>> And one feedback (I am not an I18N expert by any means, although I can
>> write both LTR and RTL :-): how can you disallow space characters
>> (presumably including ASCII SPACE) from the Secret Class?
>
> That was one point of contention. You're probably right that spaces are
> needed to suppose pass phrases instead of just pass *words*.

Map all space codepoints to ASCII 0x20 space.  Spaces are required for
passphrases.  Sure, you could also map them out, meaning that that
"foo bar" would be the same as "foobar", but I think that would be
rather surprising, whereas the equivalence of "foo\tbar" with "foo
bar" would likely go entirely unnoticed (ditto other spacing marks).

Nico
--

---

From: Alan DeKok <[email-masked]>
Date: Tue, 18 Oct 2011 21:59:12 +0200

Nico Williams wrote:
> all their devices.

  I'd change the word "reliably" to "consistently".  Users can enter
passwords everywhere.  *Something* will get sent over the wire.  Whether
it's consistent from one OS / application to another is different story.

  In my experience, I've seen very, very, few problems with end-users
entering passwords.  The historical approach has been to insist on
ASCII.  Recently, i18n passwords have become more widely used.

  But all that's required is consistency.  The user enters what he
thinks is the "same" password, and gets authenticated.  That's proof it
works for him.

  The availability of commercial && open source authentication systems
means that de-facto standards exist.  Everyone tests against everyone
elses systems, and end-users test even more combinations.  It all Just
Works.

  I'm sometimes still surprised that it does work, tho.

  Alan DeKok.

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Oct 2011 15:57:44 -0500

> it's consistent from one OS / application to another is different story.

I don't agree.  We, and I would say also *users* want consistency, but
we can't get that unless we also aim for reliability.

Put differently, if all implementations just-send-8 then there's a
high risk that we'll end up with only ASCII working consistently.  If
all implementations just-send-UTF-8 then there's a high risk that
we'll end up with only a subset of Unicode working consistently (e.g.,
that subset which doesn't require normalization, or perhaps only that
subset for which input methods reliably produce the same form).

> ASCII.  Recently, i18n passwords have become more widely used.

I've never even tried.  The main problem is that I have no idea what
input method is available on any login screen, with the main exception
-oddly enough- being smartphones and tablets, oddly enough, because
on-screen keyboards and tiny keyboards typically make it easy [for
sighted people anyways] to enter non-ASCII, at least for Latin
scripts.

> thinks is the "same" password, and gets authenticated.  That's proof it

Yes, but since that is also desired going forwards, we need a
standard.  A standard calls for more than consistency even if we're
turning a de facto standard into de jure -- a standard calls for
reliability.

>  I'm sometimes still surprised that it does work, tho.

I'm not surprised.  Most input methods (on Windows, Mac OS, Linux,
Solaris, ...) reliably produce NFC for Latin scripts.  I'm not sure if
most input methods reliably produce one form or another for Korean or
other non-Latin scripts that require normalization.  "Consistency"
might be available, but perhaps only for a small subset of users.

Even the MacOS X input methods produces NFC for Latin scripts even
though HFS applies NFD on create and reads back NFD (strange, I know).

The hard part is knowing what input method is in effect.
US-International keyboard, or compose sequences?  At the login screen,
who knows?  I guess MacOS X allows one to enter non-ASCII at the login
screen, but for Windows I'd be less sure without trying it.  And then,
all these input methods require different key combinations for things
lik &aacute;.  (I find compose sequences to be the most
straightforward and obvious, particularly after I understood their
background.)

As a user who often has to enter non-ASCII, I'd not brave the
non-ASCII password waters myself.

Nico
--