1 What's the connection?

What’s the connection between people having to remember passwords, password resets, and cleartext passwords? Surely there’s a considerable difference between typing in a password while someone is ogling your screen and having someone hack into your email account, reset your password, receive the new password in your email account, and impersonate you?

I don’t buy it. I hate seeing my passwords in cleartext, it means I have to look around for suspicious people before logging in/signing up for a website.

Also, anyone who knows what highschool I went to can reset my password? Yes, but that reset password is sent to your email address, and if they have that you’ve already lost. Also, pick a better security question. “What high school did I go to” is known by many, but “What was the date of birth of the first girl I slept with” or “What odd medical condition does my father have” are a little more secure and still easy to remember.

A little unrelated, but a pet peeve of mine is when I get an email that says “your password is yaddayadda” and I just think “so you’re not encrypting my password?” but yeah, anyways that’s unrelated.

Back on topic, passwords are “a significant cognitive burden”? So what? What about remembering my NI number, my passport number, my ZA ID number, my driving license number, my street address, my telephone number and my cellphone number? Just deal. I think web designers/developers should do their part and make the site as secure as possible, everything else is the users responsibility.

Andrew

posted at 08:40 am on February 9, 2010 by Andaith

2 Security not obscurity

These debates often make me laugh. They often demonstrate a clear lack of understanding on the part of the author.

Ok, this article is meant to tackle the UX part of authentication, the fact we should be using more complex passphrases that are prone to mistyping, and how to reduce the apparent barrier to entry of a site (without compromising security).

The presented technique has a simple but significant flaw in that it does reduce the security of the site. Text Input fields can be copy/pasted from, Password fields can only be pasted to (not copied). If you use a technique that replaces the password field with a text input, it opens the possibility of a browser addon stealing the password. Ok, you might accept that a keylogger has the same capability.

Banking systems often get around the problem of mistyping by reducing the number of letters extracted from the password that are required for input (i.e. enter the first, six and last letters), which are randomised on each input and still concealed from view. However, this means that the server requires to store the password in the plain (or at least with some common decryption key), and means if the server is compromised all passwords are revealed. I never recommend the storage of the original password on a server – a hash should be stored which cannot be simply reverse engineered, but can be compared in its entirity to a hash generated on user input (so the hash itself would not succeed if used as user input). If the server is compromised, the hash is of limited value.

A bigger question in my mind lies in the definition of the user ID (email, nickname etc), and the definition of a strong password. I see so many sites these days implementing password strength tests whilst still majorly compromising the users choice of password content. e.g. they might insist on a mixture of letters and digits, but prevent spaces or overall password length, which means I can’t use an easy to remember phrase e.g. ‘a list apart is the 1st site i visit each day’ might be a very useful password which I can vary on each site I visit and still meets the requirements of a strong password. Instead the geeks out there seem to suggest I should use arcane passwords such as ‘B%^Dg6@’ unique to every site – how on earth are we supposed to remember those without writing them down or at least using a password manager.

The ID element is also more complex than meets the eye. My email address is unique to me (although many people share an email address amongst family members), but in the event that I loose access to my email address (a common occurrence) I cannot use most password reset/reminder systems as they require access to the recorded account address. A nickname may not be unique to me – how often has your preferred nickname already been taken by your favourite website – how often have you lost access because you can’t remember which nickname you used?

I’d love to see an ALA article written by a respected security expert that provides some clear guidance to UX designers and site developers on what is considered best practice, rather than piecemeal articles that only serve to weaken the security of websites when presented without the caveats.

posted at 09:05 am on February 9, 2010 by dmeehan

3 What gives!

Having just posted above, and needing to signup in to ALA for what is my first post, I can’t believe there is no apparent way for me to modify my own registration details! No link anywhere! No confirmation email from ALA on my new registration, with details of how to unsubscribe.

What gives!

posted at 09:09 am on February 9, 2010 by dmeehan

4 Some things are for browsers.

It’s my opinion that some things are better left to browsers. Ever filled out a form that was poorly done in flash? It’s obnoxious because it doesn’t behave like every other form element the browser renders.

I don’t mind changing some aesthetics of the form to match a site, but this feels like one of those items that is better left to the browser (like what if we could markup a scroll bar on the left of the screen).

HTML provides us with a password input to use and leaves it up to the browser to accomplish its function, “The user agent should obscure the value so that people other than the user cannot see it.” (W3C HTML5)

posted at 09:11 am on February 9, 2010 by tddewey

5 remember password in browser

how would this affect the browser’s ability to remember the password?

I don’t believe that we should mess around with standard controls.

A centralized authentication service might one day be sufficient to remove password identification requirements on third party sites completely – maybe google can do this…but the tradeoff would be that every site that you visit, after you’ve signed in, would know you, and your information…

posted at 09:41 am on February 9, 2010 by AdriaanNel

6 JQuery

I like this article, and love that in a Mac you can see wireless connections’ passwords whereas in Windows you can’t. Letting the user choose seems like the best of both worlds. In the programming aspect of it, I don’t really know much about it, but would JQuery also do the trick maybe with less code?
Excellent article.

posted at 10:50 am on February 9, 2010 by rosaiani

7 Iffy Area

This area of usability is really difficult to judge. I think in most cases it would make the user feel more vulnerable – I know that it would make myself and many of my friends, colleagues and family feel that way.

@rosaiani: There is an option on Windows Vista that allows you to see the password.

posted at 11:03 am on February 9, 2010 by traxor

8 I can't think of a concise title...

I liked the article myself, even if I probably won’t end up implementing it. If I were to choose one of the two methods mentioned (Using plain-text passwords doesn’t count as a real option) I would probably choose the first, the ability to toggle between the two. Your implementation was rather nice on that one.

The second technique, however, posed some problems for me. First, it might be my browser alone, or a result of the attached events, but the cursor showing my typing position didn’t work correctly (as in, I couldn’t ever see it :P). Also, with the way that implementation was written, it’s impossible to delete and replace the first (or middle) letter of the password. Deleting the first bullet in the text field will remove the last letter from the password field. And while I would assume that users do not often do this, it would still break were they to try.

In addition to the two methods listed, the only other suggestion that I can give to help users input their passwords correctly is to warn them that caps lock is on. Sadly we can’t do this until the user actually presses a button. We can’t find the status of capslock specifically, but we can mostly determine one way or the other. though I don’t have time currently to write up an example in Javascript, I can give you some (very)pseudo code:

On keypress (in the password field): A. Check to see if the letter presses is a capitol letter. B. Check to see if the shift key was held for this event.

Now, if it was a capitol without Shift, then caps lock is probably on.
Also, if it was NOT capitol but shift WAS held, caps lock is probably on.
If caps lock is probably on, display a warning. If not, clear the warning (if it exists).

Well, I guess that’s all for now. I can write up an example function and post it here later if there’s any interest.

But overall, thanks for the great article Lyle.

posted at 11:13 am on February 9, 2010 by Chibu

9

Despite the obvious issues and concerns raised already in these discussions, it’s clear that there will be support for these techniques – at least in some arenas. Apple’s implementation on the iPhone is clear evidence of this. I, for one, am avidly in favour of improvements that make it easier for the user to enter their details correctly.
For UX designers set on implementing these techniques, the emphasis should lie on minimising the differences between expectation and delivery. Users will expect their ‘improved’ password field to still respond to human interface (typing, backspacing, pasting, selecting, etc.) in the same way the old fields did, but if they don’t it could lead to serious issues of distrust.
In testing the Progressive Masking technique (Firefox, Chrome, Safari) it becomes evident that the overlay field plays havoc on the user’s ability to select characters in the same way the password field allows. Consider a user who enters their password incorrectly, is notified by the overlay, and uses Shift + ← to highlight and delete the incorrect character. The user gets no indication of the password being highlighted, and thus becomes suspicious of the integrity of the password field, and the environment in which it resides.
Similarly, when the user attempts to highlight with the text selector cursor, the user either gets no feedback as to what is being selected (Chrome, Safari), or the masked layer is selected but cannot be manipulated (Firefox).
For this technique to be effective in the wild, the implementation must have the same functionality as the original, but with the added benefit of self-validation. I believe that somehow implementing synchronised feedback between both the mask layer and the input layer (when highlighting) is essential in ensuring a usable improvement to the password field.

posted at 11:15 am on February 9, 2010 by juanojeda

10 I don't see the issue, or what it fixes...

I know there was some controversy when Nielson first mentioned this. Then, as now, the only real argument I’ve heard that makes any sense in a user experience setting is the added confusion by discarding a known consistency. Otherwise, I’ve heard no argument that justifies the extra development time or potential for conflict that the “solutions” offered here (and elsewhere).

There is either an issue masking the text or there isn’t. If there is, then half-masking or toggle-masking isn’t a solution — it adds another layer of complexity to the interface. The only real solution is clear text (which I personally agree with).

Or, maybe the issue is pretty non-existant, and we’re worrying over nothing. In both cases, these half-measures only muddy the situation. Instead of one known interface that does or doesn’t work, we have 3 (or more) interfaces, none of which really fix the core issue.

posted at 11:16 am on February 9, 2010 by Nathan Ziarek