RE: Unicode in passwords

[Marc Durdin]

That’s a good list. A few other things I’ve seen:


1.   Even if the user sees the character for an instant, complex script 
characters can be very puzzling as they appear differently and “out of order” 
when isolated.

2.   The number of dots corresponds to the number of code points, which is 
misleading with complex scripts or advanced input methods: you won’t 
necessarily see one dot per keystroke; in some cases, typing a character may 
replace a dot with another dot or even delete a dot.

3.   Directionality can be frustrating.

I’ve had to assist in situations where a user has set a new Windows password 
using a custom keyboard, and then been unable to login, e.g. with Remote 
Desktop, or even with the standard Windows login screen.

iOS, for example, doesn’t even allow the user to select a different input 
method for password boxes – it seems to always be Latin script only (even if 
you’ve removed all your Latin script keyboards from Settings).

Marc

From: Unicode [mailto:unicode-boun...@unicode.org] On Behalf Of Mark Davis ??
Sent: Thursday, 1 October 2015 3:01 PM
To: Jonathan Rosenne 
Cc: Unicode Public 
Subject: Re: Unicode in passwords

I've heard some concerns, mostly around the UI for people typing in passwords; 
that they get frustrated when they have to type their password on different 
devices:

  1.  A device may not have keyboard mappings with all the keys for their 
language.
  2.  The keyboard mappings across devices vary where they put keys, especially 
for minority script characters using some pattern of shift/alt/option/etc.. So 
the pattern of keys that they use on one may be different than on another.
  3.  People are often 'blind' to the characters being entered: they just see a 
dot, for example. If the keyboards for their language are not standard, then 
that makes it difficult.
  4.  Even if they see, for an instant, the character they type, if the device 
doesn't have a font for their language's characters, it may be just a box.
  5.  Even if those are not true, the glyph may not be distinctive enough if 
the size is too small.


Mark

— Il meglio è l’inimico del bene —

On Thu, Oct 1, 2015 at 6:11 AM, Jonathan Rosenne 
mailto:jonathan.rose...@gmail.com>> wrote:

For languages such as Java, passwords should be handled as byte arrays rather 
than strings. This may make it difficult to apply normalization.



Jonathan Rosenne

From: Unicode 
[mailto:unicode-boun...@unicode.org] On 
Behalf Of Clark S. Cox III
Sent: Thursday, October 01, 2015 2:16 AM
To: Hans Åberg
Cc: unicode@unicode.org; John O'Conner
Subject: Re: Unicode in passwords


On 2015/09/30, at 13:29, Hans Åberg 
mailto:haber...@telia.com>> wrote:


On 30 Sep 2015, at 18:33, John O'Conner 
mailto:jsocon...@gmail.com>> wrote:

Can you recommend any documents to help me understand potential issues (if any) 
for password policies and validation methods that allow characters from more 
"exotic" portions of the Unicode space?

On UNIX computers, one computes a hash (like SHA-256), which is then used to 
authenticate the password up to a high probability. The hash is stored in the 
open, but it is not known how to compute the password from the hash, so knowing 
the hash does not easily allow authentication.

So if the password is

… normalized and then …

encoded in say UTF-8 and then hashed, it would seem to take care of most 
problems.

You really wouldn’t want “Schlüssel” and “Schlüssel” being different passwords, 
would you? (assuming that my mail client and/or OS is not interfering, the 
first is NFC, while the second is NFD)

Re: Unicode in passwords

[Mark Davis ☕️]

I've heard some concerns, mostly around the UI for people typing in
passwords; that they get frustrated when they have to type their password
on different devices:

   1. A device may not have keyboard mappings with all the keys for their
   language.
   2. The keyboard mappings across devices vary where they put keys,
   especially for minority script characters using some pattern of
   shift/alt/option/etc.. So the pattern of keys that they use on one may be
   different than on another.
   3. People are often 'blind' to the characters being entered: they just
   see a dot, for example. If the keyboards for their language are not
   standard, then that makes it difficult.
   4. Even if they see, for an instant, the character they type, if the
   device doesn't have a font for their language's characters, it may be just
   a box.
   5. Even if those are not true, the glyph may not be distinctive enough
   if the size is too small.



Mark 

*— Il meglio è l’inimico del bene —*

On Thu, Oct 1, 2015 at 6:11 AM, Jonathan Rosenne  wrote:

> For languages such as Java, passwords should be handled as byte arrays
> rather than strings. This may make it difficult to apply normalization.
>
>
>
> Jonathan Rosenne
>
>
>
> *From:* Unicode [mailto:unicode-boun...@unicode.org] *On Behalf Of *Clark
> S. Cox III
> *Sent:* Thursday, October 01, 2015 2:16 AM
> *To:* Hans Åberg
> *Cc:* unicode@unicode.org; John O'Conner
> *Subject:* Re: Unicode in passwords
>
>
>
>
>
> On 2015/09/30, at 13:29, Hans Åberg  wrote:
>
>
>
>
>
> On 30 Sep 2015, at 18:33, John O'Conner  wrote:
>
> Can you recommend any documents to help me understand potential issues (if
> any) for password policies and validation methods that allow characters
> from more "exotic" portions of the Unicode space?
>
>
> On UNIX computers, one computes a hash (like SHA-256), which is then used
> to authenticate the password up to a high probability. The hash is stored
> in the open, but it is not known how to compute the password from the hash,
> so knowing the hash does not easily allow authentication.
>
> So if the password is
>
>
>
> … normalized and then …
>
>
>
> encoded in say UTF-8 and then hashed, it would seem to take care of most
> problems.
>
>
>
> You really wouldn’t want “Schlüssel” and “Schlüssel” being different
> passwords, would you? (assuming that my mail client and/or OS is not
> interfering, the first is NFC, while the second is NFD)
>

RE: Unicode in passwords

[Jonathan Rosenne]

For languages such as Java, passwords should be handled as byte arrays rather 
than strings. This may make it difficult to apply normalization. 

 

Jonathan Rosenne

 

From: Unicode [mailto:unicode-boun...@unicode.org] On Behalf Of Clark S. Cox III
Sent: Thursday, October 01, 2015 2:16 AM
To: Hans Åberg
Cc: unicode@unicode.org; John O'Conner
Subject: Re: Unicode in passwords

 

 

On 2015/09/30, at 13:29, Hans Åberg  wrote:

 





On 30 Sep 2015, at 18:33, John O'Conner  wrote:

Can you recommend any documents to help me understand potential issues (if any) 
for password policies and validation methods that allow characters from more 
"exotic" portions of the Unicode space?


On UNIX computers, one computes a hash (like SHA-256), which is then used to 
authenticate the password up to a high probability. The hash is stored in the 
open, but it is not known how to compute the password from the hash, so knowing 
the hash does not easily allow authentication.

So if the password is 

 

… normalized and then …





encoded in say UTF-8 and then hashed, it would seem to take care of most 
problems.

 

You really wouldn’t want “Schlüssel” and “Schlüssel” being different passwords, 
would you? (assuming that my mail client and/or OS is not interfering, the 
first is NFC, while the second is NFD)

Re: Unicode in passwords

[Richard Wordingham]

On Wed, 30 Sep 2015 16:15:30 -0700
"Clark S. Cox III"  wrote:
 
> You really wouldn’t want “Schlüssel” and “Schlüssel” being different
> passwords, would you?

It'd make them slightly safer to write down!  I trust the tradition of
truncating Unix passwords to 8 bytes is well and truly defunct - that'd
reduce Thai passwords to two characters plus one bit!

Richard.

Re: Unicode in passwords

[Clark S. Cox III]

> On 2015/09/30, at 13:29, Hans Åberg  wrote:
> 
> 
>> On 30 Sep 2015, at 18:33, John O'Conner  wrote:
>> 
>> Can you recommend any documents to help me understand potential issues (if 
>> any) for password policies and validation methods that allow characters from 
>> more "exotic" portions of the Unicode space?
> 
> On UNIX computers, one computes a hash (like SHA-256), which is then used to 
> authenticate the password up to a high probability. The hash is stored in the 
> open, but it is not known how to compute the password from the hash, so 
> knowing the hash does not easily allow authentication.
> 
> So if the password is

… normalized and then …

> encoded in say UTF-8 and then hashed, it would seem to take care of most 
> problems.


You really wouldn’t want “Schlüssel” and “Schlüssel” being different passwords, 
would you? (assuming that my mail client and/or OS is not interfering, the 
first is NFC, while the second is NFD)

Re: Unicode in passwords

[Hans Åberg]

> On 30 Sep 2015, at 18:33, John O'Conner  wrote:
> 
> Can you recommend any documents to help me understand potential issues (if 
> any) for password policies and validation methods that allow characters from 
> more "exotic" portions of the Unicode space?

On UNIX computers, one computes a hash (like SHA-256), which is then used to 
authenticate the password up to a high probability. The hash is stored in the 
open, but it is not known how to compute the password from the hash, so knowing 
the hash does not easily allow authentication.

So if the password is encoded in say UTF-8 and then hashed, it would seem to 
take care of most problems.

Re: Unicode in passwords

[Marc Blanchet]

On 30 Sep 2015, at 12:33, John O'Conner wrote:

I'm researching potential problems and best practices for password 
policies
that allow non-Latin-1 Unicode characters. My searching of the 
unicode.org
site showed me a general security considerations document (UTR #36) 
but

nothing specific for password policies using Unicode.

Can you recommend any documents to help me understand potential issues 
(if
any) for password policies and validation methods that allow 
characters

from more "exotic" portions of the Unicode space?


the IETF have been doing work related to this exact issue. You might 
want to look at RFC7564 (generic framework) and RFC7613 (username and 
passwords, used in various IETF protocols).


Marc.



Best regards,
John O'Conner

Unicode in passwords

[John O'Conner]

I'm researching potential problems and best practices for password policies
that allow non-Latin-1 Unicode characters. My searching of the unicode.org
site showed me a general security considerations document (UTR #36) but
nothing specific for password policies using Unicode.

Can you recommend any documents to help me understand potential issues (if
any) for password policies and validation methods that allow characters
from more "exotic" portions of the Unicode space?

Best regards,
John O'Conner