Unicode in passwords

[Richard Wordingham]

On Tue,  6 Oct 2015 20:13:12 +0100 (BST)
Julian Bradfield <jcb+unicode at inf.ed.ac.uk> wrote:

> On 2015-10-06, Asmus Freytag (t) <asmus-inc at ix.netcom.com> wrote:
> > All browsers I use display spaces in input boxes, and put blobs for
> > hidden fields. Do you have evidence for broken input fields?</pre>
> >     </blockquote>
> >     <br>
> >     Network keys. That interface seems to consistently give people a
> >     choice to reveal the key.<br>
> 
> ? That's not broken in the way Philippe was discussing.

No, but if you make the password up as you type it, you might not then
notice that one accidentally typed a double space.

> > Copy-paste works on all my systems, too - do you have evidence of
> > broken copy-paste in this way?</pre>
> >     </blockquote>
> >     <br>
> >     I've seen input fields where sites don't allow paste on the
> > second copy (the confirmation copy).<br>
> >     <br>
> >     Even for non-password things.<br>
> 
> That's not relevantly broken, either - it's a design feature, to make
> sure you can type the password again (from finger memory!).

It's an interesting issue for a password that one can't type.  It's by
no means a guarantee, either.  I once specified a new a password that
changed case in the middle not realising that I had started with caps
lock on.  Consequently, both copies has the wrong capitalisation.  I
was using a wireless keyboard, which to conserve battery power doesn't
have a caps lock indicator.  (In the old days, caps lock would have
physically locked, but that's not how keyboard drivers work nowadays.)
It took a little while before it occurred to me that I might have had a
problem with caps lock.

Richard.