<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 4/7/2022 8:48 PM, Tex via Unicode
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:00ad01d84afb$8fa79180$aef6b480$@xencraft.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style>@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}@font-face
{font-family:Vrinda;
panose-1:2 11 5 2 4 2 4 2 2 3;}@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}@font-face
{font-family:"\@MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#002060;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060">Aren’t
keystrokes device dependent, since keyboards vary,
physically and virtually?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060">We
would have to restrict passwords to the minimal keys that
are universal- it is the same problem with a smaller
character set.</span></p>
</div>
</blockquote>
<p>That's the thing.</p>
<p>The conclusion is that passwords really only work for
master/recovery passwords. Everything else should come from a
password manager.</p>
<p>Not enforceable, alas.</p>
<p>A./<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:00ad01d84afb$8fa79180$aef6b480$@xencraft.com">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"
moz-do-not-send="true"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></a></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Unicode [<a class="moz-txt-link-freetext" href="mailto:unicode-bounces@corp.unicode.org">mailto:unicode-bounces@corp.unicode.org</a>] <b>On
Behalf Of </b>Asmus Freytag via Unicode<br>
<b>Sent:</b> Thursday, April 7, 2022 8:19 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:unicode@corp.unicode.org">unicode@corp.unicode.org</a><br>
<b>Subject:</b> Re: global password strategies<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">It sounds to me that a general principle
ought to be that passwords should be limited to sequences of
"keystrokes", not specific characters. The problem is that
what that means is becoming device-dependent. But we don't
really want device-dependent password rules? Do we?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A./<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On 4/7/2022 5:37 PM, Martin J. Dürst via
Unicode wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Hello Tex, <br>
<br>
I'm surprised I haven't seen any answers to your post yet, I
think it's a very interesting and important topic. <br>
<br>
On 2022-04-05 08:23, Tex via Unicode wrote: <br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">What is the modern recommendation for
globalization of passwords? <br>
<br>
<br>
1) If your application (web, mobile, desktop, etc.) is
used worldwide, which characters do you allow or restrict? <o:p></o:p></p>
<p class="MsoNormal"><br>
I don't have an example of an own application where I made
such decisions (in most cases, such decisions are made at a
framework/library level). But in Japan at least, nobody
expects to use anything other than ASCII in passwords. There
are two interrelated reasons for this: <br>
1) Kanji, Hiragana, and Katakana would require conversion,
which would mean users have to visually check whether they
got the right character. That's not a good idea for
passwords. <br>
2) Conversion choices get stored on the user's system to
make future choices easier, but that would establish a side
channel. An attacker may get access to that data, and when
comparing before/after, can narrow down the choices for
passwords considerably. <br>
I'd expect this to at least apply for Chinese, too. <br>
<br>
I'd also guess that many password-related libraries restrict
input to ASCII. But with the deep penetration of smartphones
around the world, the need for non-ASCII passwords is
definitely increasing. As we are working on giving people
fully non-ASCII email addresses, we shouldn't ignore
passwords. <br>
<br>
<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">2) How do you deal with writing
direction? <br>
<br>
My concerns are that confirming and displaying a password
might look different depending on how well the browser or OS
implements RTL writing direction or features like dir=auto.
A user may then not be able to log in because they are
instructed to type it in a way that is inconsistent with
what they have seen on the screen. <o:p></o:p></p>
<p class="MsoNormal"><br>
This is definitely a problem, but maybe not such a serious
one. On such a system, the user may be used to such
inconsistencies. The user knows what characters they
intended to typed, in what order. When they do a visual
check, they don't need to verify the order, they only need
to verify character identity. On smartphone, there are also
many password input methods that only show the last
character. <br>
<br>
<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><br>
3) Do you allow control or other invisible characters
that a user may be used to typing in certain phrases? If
these are allowed, how to indicate to the user that they
have been used? <o:p></o:p></p>
<p class="MsoNormal"><br>
I'd just say the less allowed, the better. <br>
<br>
<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">4) Also, should passwords be Unicode
normalized? Seems damned if you do and if you don’t. Do text
input methods generate test the same way or is it possible
for a user to create a password on one system and then not
be able to log in on another device? <o:p></o:p></p>
<p class="MsoNormal"><br>
The Mac used to do decomposition (NFD), and Windows uses
composition (NFC), at least for file systems. I'm not sure
this is still the case. <br>
<br>
And there are other issues. In Arabic/Persian for example,
there are different forms of the letter YEH, with different
encodings, for things that may look the same on screen. An
Arabic keyboard and a Farsi keyboard may produce different
character codes. <br>
<br>
<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">(Not normalization related, but I have
experienced difficulty logging in to foreign systems, in
hotels etc., when the keyboard is different and it takes a
while to realize I have to abandon muscle memory and
remember the actual password and look for the keys on the
keyboard.) <o:p></o:p></p>
<p class="MsoNormal"><br>
The most important point is not "damned if you do and damned
if you don't", but "whatever you do, make sure you always do
exactly the same thing". <br>
<br>
This starts way before you get into normalization. For
example, do you remove leading/trailing white space? (The
user may have copied the password from some text file.
(That's not very good security, but some people still do
it.)) <br>
<br>
Another example: Do you always have the same length
restriction? I remember a case where I had set a password
for a site, and on a sister site, it only worked after I
tried to shorten it. What had happened was that when I set
it, it got accepted but truncated without telling me, which
worked well on the same site because the same truncation
happened again. But the sister site didn't truncate, and
this produced a mismatch. Make sure you tell people about
such issues when they are setting a password, don't just
'fix' things behind the scenes. <br>
<br>
Also remember that password encryption algorithms work on
binary data, not on characters. For ASCII-only, that doesn't
usually cause problems, but when working with Unicode, you
want to make sure you have a single encoding before the
encryption. <br>
<br>
Please also note that "whatever you do, make sure you always
do exactly the same thing" and using libraries or frameworks
may not work well together, because different
libraries/frameworks may do different things. <br>
<br>
Regards, Martin. <o:p></o:p></p>
</blockquote>
<p><o:p> </o:p></p>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>