[kde-guidelines] Password Field

[Thomas Pfeiffer]

On Saturday 07 December 2013 10:44:33 Björn Balazs wrote:
> Am Freitag, 6. Dezember 2013, 22:27:20 schrieb Thomas Pfeiffer:
> > On Friday 06 December 2013 15:20:23 Aaron J. Seigo wrote:
> > > On Friday, December 6, 2013 14:58:32 Björn Balazs wrote:
> > > > Actually I am not such a big fan of the double entry security myself.
> > > > If
> > > > I
> > > > should have switched e.g. Caps Lock on, the two passwords are actually
> > > > the
> > > > same - even though I won't be able to enter the password the next time
> > > > correctly.
> > > 
> > > that’s a really good point.
> > > 
> > > hell i’ve managed to mistype a password the same way twice before :P
> > > 
> > > > What do you think - would we still need the double entry of a NEW
> > > > password,
> > > > when we can choose to show the password inline?
> > > 
> > > probably not, though typos can still make it in. would need testing over
> > > time, but i like the idea of the “just show me my damn password” :)
> > 
> > What we have to prevent is people creating a new password with a single
> > masked entry, especially since in the rare cases where you set a password
> > locally (which is where that HIG would apply mostly), there is no "I
> > forgot
> > my password" option. I am open to any solution which does that.
> > Just completely disabling the masking wherever a new password is set and
> > preventing changing a password while the field is masked would be a viable
> > solution, thought it would mean that people cannot set new passwords while
> > in a public space.
> > Personally, I would even be okay with showing a re-type field only if the
> > original field is masked, but showing/hiding the re-type field when the
> > original one is masked/unmasked might feel weird.
> 
> So we should add to the styleguide that a recovery is preferable to a double
> entry? If there is no recovery option possible, we should first enforce
> that user do have any keyboard modificators (Caps Lock) switched on. And
> then?

Since if you create passwords locally it's mostly for encryption purposes, I 
assume recovery would be impossible in most cases. Preventing password 
creation with capslock switched on would be a good idea, yes. Or maybe a 
prominent indicator telling users if it's on would already be sufficient?

> I do not like a jumpy interface which offers two password fields when
> entries are invisible and only one when they are visible. Then I would
> prefer to always go for two fields as to say: Look, this is important!

I think we should either go with always re-type or no masking at all. It's 
really a matter of preference of convenience vs. security. We have to keep in 
mind that setting a new password locally is a rather rare case. 

Any other opinions on this?
 
> > > > This was actually the start for my thoughts. When designing on the
> > > > networkmanager, this horrible 'show the password' line simply gets in
> > > > the
> > > > way all of the time :) - so a more compact solution would be great.
> > > 
> > > +100
> > 
> > I'm fine with an inline masking control. As long as we do have that
> > control
> > and people notice it, I don't have a strong opinion on where it's
> > positioned or what it looks like.
> 
> So how do we proceed? Ask Nuno for a design? Who would provide the code that
> others can embed?

We can post a request for an icon to the kde-artists list. As for who will 
write the code: Well, maybe someone on the usability list would like to help 
or if it's easy to do we might even make it a Google Code-In task.
Could a developer reading this please give us a quick estimation of the effort 
for something like this?