Re: Unicode in passwords

From: Richard Wordingham <richard.wordingham_at_ntlworld.com>
Date: Tue, 6 Oct 2015 20:57:34 +0100

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.
Received on Tue Oct 06 2015 - 14:58:46 CDT

This archive was generated by hypermail 2.2.0 : Tue Oct 06 2015 - 14:58:46 CDT