AppSec Blog

AppSec Blog

Response to Nielsen's "Stop Password Masking"

I just ran across Jakob Nielsen's Alert Box post titled Stop Password Masking and wanted to provide some feedback from a security vs. usability perspective. I have great respect for Nielsen's contribution to the usability of the web. Back in the early days of the internet (mid 1990's), his books were gospel at my consulting firm, ATGi.

My initial reaction to his article was 'that's a crazy idea' - but after some reflection, I really felt like it was a good mental exercise to actually consider what he was saying. If I hadn't known who Nielsen was, I probably would have dismissed his suggestion outright. Sometimes it is a good exercise to go back and review why we do the things we do - especially as it relates to information security controls. Nielsen questions the real security benefit of password masking - something I haven't given a second thought to...well, ever.


"Typically, masking passwords doesn't even increase security, but it does cost you business due to login failures."



Nielsen's probably right: It might be costing you business. The question is, how much business? Security shouldn't be the be-all, end-all goal. It's there to serve the organization first and foremost. Viewing the cost of security controls with respect to the function it's protecting is the correct perspective. Enter risk analysis - risk analysis is an important process that helps determine if the cost of having (or not having) a security control mitigates threats, while not adversely affecting the business (too much). It's about reducing risk to an acceptable level, not about 100% security. It's a balancing act. Why not target 100% security? Well, if an organization attempted to implement absolute security, it'd go out of business - it's just too expensive. For example, it doesn't make sense to spend a million dollars on security solutions that will protect a web site that only earns a few thousands dollars a month.

Again, Nielsen pretty much has it right- except for the 'true loss of security' statement:


"The more uncertain users feel about typing passwords, the more likely they are to (a) employ overly simple passwords and/or (b) copy-paste passwords from a file on their computer. Both behaviors lead to a true loss of security."



Next Nielsen gives a nod to the importance of security and provides an option for masks that takes security into consideration:

"Yes, users are sometimes truly at risk of having bystanders spy on their passwords, such as when they're using an Internet cafe. It's therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there's a tension between security and usability, sometimes security should win."



Though I would go further than Nielsen: Users, unless forced, won't use a complex password even if there is no mask, unless complexity is enforced. If complexity is enforced, a non-masked textbox would certainly help the user meet complexity requirements more easily - which is probably what Nielsen means. Likewise, when presented with an option for masked password or not masked - users typically chose convenience over security so in most cases I would want to default the option to show the mask.

Using simple passwords or 'copy-paste passwords' is not NECESSARILY a 'true loss of security', but the devil's in the details.

The loss of security for 'copy-paste password' scenarios (which assumes users are storing passwords locally in a file of some sort) assumes a local computer or local network compromise. If so, he's correct - the gig is up, but that's not necessarily a true loss of security...well, it IS for the ONE compromised user (or network of users) - but not for all the users of that web site. The main reason we insist on password complexity is increase the keyspace of a password which helps stop brute force and dictionary attacks that originate from attackers "out there" who don't require access to the user's computer to begin with. The attacker attempts to find a collision with a password for a known account through a dictionary attack and if they have more time, a brute force attack. Additionally, Password Manager Software (KeePass or Password Safe) will encrypt password stores locally and even associate them automatically with the appropriate web site. Though I suspect the use of password management tools is the exception, not the rule.

As for users choosing too simple of a password: If the site allows users to pick an insecure password, that's already a failure of the site. But it's possible to have both a simple password as well as a secure password. Contrary to common belief, good passwords don't necessarily have to contain symbols, digits, upper and lower case characters. The reason these complexity requirements were introduced was to protect against brute force attacks as well as dictionary attacks on shorter passwords. Humans have a natural propensity to use simple dictionary words that are easy to remember - such as names, meaningful numbers/dates, pet names, etc., as passwords - hackers take advantage of this seemingly reasonable behavior and use it to their advantage. By adding complexity - that is, the symbols, digits, upper/lower characters - this makes the dictionary attacks more expensive (time consuming) to the attacker since each time we increase the length and the number of possible combinations, this increases the keyspace of the password. So if instead of increasing the combinations, instead increase the password length and use a simple phrase or sentence as the password. These long passwords with less complexity are called a passphrase. Dictionary attacks are useless against passphrases since they are not made up of a dictionary words. By increasing the keyspace by requiring a minimum of 30 normal alpha characters (including spaces and maybe an optional period or comma) we've also made it very expensive (time consuming) to brute force. So my passphrase could be "my name is jason and this is my password." - this is 40+ characters and no more difficult to remember than a dictionary word - but it's not found in any dictionary so it will stop dictionary attacks and it has a very large keyspace so it will slow down brute force attacks considerably, making them impractical.

A true loss of security? It doesn't have to be - at least not for the organization. However, I can already hear Nielsen groaning on the usability of typing 40+ characters blindly into a masked password box. :) This is where two-factor authentication can solve the problem of passwords and passphrases completely - which can really improve usability.

Nielsen's observation about typing in passwords on mobile devices makes the most sense to me.It is more difficult to shoulder surf someone on a mobile device. It's also much more difficult to type a password with complexity requirements correctly on a mobile device unless you're a profession texter. There's probably not as much risk here by unmasking, so we could probably forgo the mask on mobile devices. It's trivial to detect mobile devices, so simple choosing to use a non-masked text box in these situations would be okay for most situations.

But before we go running to dump the masked password box, there's a few questions we must ask - what are the unintended side-effects of this change? Are there good workarounds to these issues? How much education do developers need to implement this? Remember, we've known about and had solutions to SQL Injection for over 10 years now, yet there's still a constant barrage of developers who still don't know how to protect against this properly - this is an education problem.

Here's my initial pass of issues I see by displaying (not masking) passwords to end users:

  1. Accidental observation - in the enterprise there are many opportunities where someone else will be at your computer and may accidentally see your password. A great example of this is when using older command line programs that required the password as an argument. I've on occasion seen others' passwords and others have seen mine.
  2. Autocomplete Web Forms - Modern web browsers now remember and prefill text boxes with previously used input. This is a usability feature at the expense of privacy/security. This means the password is stored not only in the OS somewhere for retrieval later, but will pop-up anytime a user starts typing in the textbox. This has the most serious implications on public systems. Developers, if aware of the issue, can prevent this data from being stored by setting the autocomplete attribute to off in the form. This is a developer educational issue.
  3. Compliance - I don't want to get into all the details here, but bad password management practices can cause compliance issues. Lack of compliance can affect business. Not masking passwords may be in violation of certain security requirements for the organization.
  4. Nuanced Issues - there are potentially a variety of issues for every masked password box implementation - for instance, in .NET for Windows Applications, there's a way to encrypt passwords in memory (using the System.Security.SecureString object). Displaying the characters in the textbox first may completely defeat the security provided by this control.
  5. What else? - Are there other issues here?
Certainly a usability guy isn't going to or need to understand all the ins and outs of security, just as I won't understand the broad range of usability issues. We should be cautious when recommending broad sweeping changes that affect security. Additionally, us security folks should not resist usability improvements that affect security just because we've always done things another way - we should have a good solid business reasons why we do things the way we do. We need to make sure changes can continue to protect our customers/users. Changes to security functionality can often cause unintended side-effects that can put us at risk. Not that there isn't a good solution - to me, the most IDEAL solution to improve usability would be to dump passwords as the authentication mechanism all together - there are some partial solutions to this problem, but Identification is a difficult problem to solve - we're definitely not there yet. Personally, I look forward to the day where authentication, passwords, and password management all become a thing of the past, but that's a completely different conversation.

18 Comments

Posted June 28, 2009 at 5:11 PM | Permalink | Reply

buherator

What if we use the solution available on many mobile phones: you only see the last character of your pass, the previous part is masked.

Posted June 28, 2009 at 9:51 PM | Permalink | Reply

TurboBorland

5.) Hijacked &saved video feeds and the birth of hidden recorders aimed at screen to capture passwords. Now, this might not be your casual hack, but with the advancement of these things getting smaller and smaller everyday, unmasked passwords open up doorways to all sorts of tech treachery. With social engineering and a small recorder placed on a stitch in the back of your shirt, as to if they ask you to 'turn around' while they type their password into the system to get the information you need. Now, this is of course a dramatic example, but with being able to "see" passwords, this type of physical attack becomes commonplace again. We also have places who store video feeds from their security cams. If an attacker has access to them, what's to stop them from using it to fast forward or rewind to the point that a person is entering in their password,t hen zooming in? Here's what I responded with to the webappsec email feed 4 days ago, "Well coming from real experience with using acquired security cams to spy on computers and capture their hand movements, spying on a screen to view what they enter is insanely easy. With the amount of resolution these cameras have, you have a long time to capture them entering characters into the input field (lets take time to type in a password, time it takes to load the next page, and the length of the password). However, with the hand placement of typing techniques, the amount of time the finger is on each key, and the angles of viewing and capturing keyboard strikes is a whole lot more difficult." In the end, allowing users to view their password may not open up many more remote attack vectors, but new physical attack vectors for things like corporate espionage would definitely be on the rise. After all, most attackers do come from the inside.

Posted June 29, 2009 at 12:35 AM | Permalink | Reply

Reggie

More IT Geeks going over the top instead of using their head.

I was a manager in the past and I saw similar issues. We had this stupid copy machine fixit guy turned IT trough night classes at Devry or something. He comes back from a security seminar that had him spazing for day. He shorty after created this stupid "Strong" password policy. To which all employees hated and all of senior management ignored. What I saw was every employee putting their password somewhere on their desk, then complain because they would have to change the PW in 6 months! When I told him how stupid the whole thing was he insisted everyone would remember. I couldnt get some to tie their shoes in the morning!

After a while he claimed that there we "viruses", and was of course vocal that these came through people not using "strong" password. Then one day my computer froze. Which he claimed was because I wasnt using strong passwords and didnt have time to fix it. Being a computer stud, I found a work around, you could see the rage as his plot to suggest not have "strong" passwords didnt work. I had enough, I orchestrated a series of "failiures" on he part and got him fired. I told the new IT guy we were not going to have strong password for people to forget and paste all over their desks. For the following year and a half, till I left, there were no more virus or security break-ins. I took the time to see some of these security seminars of youtube,ect. Many of these IT security firms are nothing more then several thousand dollar scare seminars that slow productivity to cover the IT departments butt. I found it funny that I could see through this IT guys BS and all the security break ins were non-existent with his departure. As I approved purchased for the IT department, there was no new software or equipment either.

So the next time one of your IT losers tries to orchestrate a security break in to sert your agenda, remember people are computer savy these days more then they ever were.

Posted June 29, 2009 at 1:16 AM | Permalink | Reply

Philip Dorrell

One useability issue is that the user shouldn't be forced to choose a strong password. Instead the website should be more intelligent about throttling excessive login attempts (without actually locking the user out).

I wrote in detail about this at http://www.1729.com/blog/WeakUserPasswords.html ("How to Secure a Website Against Weak User Passwords").

Posted June 29, 2009 at 2:40 AM | Permalink | Reply

SteveC

Masking passwords, as opposed to displaying them doesn't help security?

And, unmasking passwords gives feedback that's needed?

Only if you don't know how to touch type.

Here's what I take away from this idiotcy:


LEARN HOW TO TOUGH TYPE!

Posted June 29, 2009 at 3:00 AM | Permalink | Reply

Wireghoul

I think it's time we move past password complexity unless you are working with a limited keyspace. It is far more efficient to use longer passwords and a long lowercase password like "thisismypassword" is far more usable and secure than "aPhw9mxU" when brute force is concerned.

The biggest threat to passwords these days are trojans, which will I expect will change from keyloggers to MITM capacity as two factor authentication get more common. In the paraphrased words of Bruce Schneier, "two factor authentication will not save you"

Posted June 29, 2009 at 3:39 AM | Permalink | Reply

hanford

It's a great theory, but the number one thing I think is missing from both Nielsen's article (and from your article, but you're taking a different angle) is proof of a real problem, and proof as to whether or not unmasking the password solved it.

Neilsen insists its an issue but doesn't really offer any solid evidence of a problem, whether or not making it unmasked fixed it, and whether or not there were any *new* issues that came up because of it. So it's a great theory, but like all UI improvements, they must be tested. Had he sited a case where passwords were a serious problem, and unmasking solved it without creating more problems, I'd be more interested. But I'm simply not convinced that for most of the internet, the current masked password box is a problem worth fixing, especially if it means users security is compromised significantly.

This is what irks me about a lot of Nielsen's posts. He tends to assert things as gospel (and I'm sure some people believe it as such) but if this is just a theory of his that he really hasn't studied, he's basically asking his users to be guinea pigs, possibly to disastrous results.

If anyone implements this, PLEASE test it extensively before rolling it out, and then PLEASE post the results.

Posted June 29, 2009 at 6:39 AM | Permalink | Reply

Brian Mobley

Thank God someone else sees the sensibility of using passphrases. I have often wondered WHY DoD protocols never adopted their use (That I'm aware of), forcing users as you said to do foolish things to remember their X-number character "complex" password such as post-it notes stuck to their monitors or whatnot. I have yet to find a sysadmin who could explain to me the rationale of not using passphrases as opposed to current requirements.

Posted June 29, 2009 at 7:18 AM | Permalink | Reply

drewp

I'm concerned about a loss of business from users who start typing into the ***** box and panic when it shows their characters.

Wouldn't such a "highly usable" site accidentally resemble the lousiest sites ever, the ones that have homemade security systems that leak passwords all the time?

It's hard to put myself in the non-technical users' place, but I would think that as they make their first impressions of the professionalism of a site and judge its trustworthiness, seeing their passwords in the clear would probably not make them think of a security- and usability-conscious design.

It would be interesting to ask some users if they think the password is getting "encrypted" as they type it in, i.e. that's *why* it looks like *****. If that happens to be people's mental model, then I'm definitely keeping with the tradition.

Posted June 29, 2009 at 2:56 PM | Permalink | Reply

Michael

Passphrases are nice. The biggest issue for end users will be during adoption: 5 sites support them and 30 don't. "Do I want to use different passwords for the 5 that do?" Most users probably won't since security isn't paramount to their way of thinking. If only we could educate them.


In response to the original article by Nielson:
--
The biggest hangup on this idea is how browsers work. Passwords are only saved in browsers if they use the masked "password" field, and are generally stored by the browser encrypted. Text fields store autocomplete data making them vunerable ot physical browser access (though it can be disable in most browsers with autocomplete="off") and are generally stored by the browser unencrypted.


So, do do you allow browsers to remember the password in their password history and keep it masked? Or do you use a text field and allow autocomplete of a text field which might expose the password? Or do you use a text field and require the user to manually enter the password each time?


Hard choices...somehow I think the existing system will win out until browsers allow unmasked password fields (if you type in it, you see the letters, if it is autofilled, it is masked).

Posted June 29, 2009 at 6:44 PM | Permalink | Reply

Jason Montgomery

hanford - supposedly all of Nielsen's usability information comes from real world experience. That being said, I also would prefer to see the stats to back it up. It's difficult to weigh a security benefit vs. loss of business when there are no numbers to back it up. I suspect there are no easy answers here, though. The numbers would most certainly vary per site - depending on the demographic of users...for sites of a more technical nature this probably isn't much of an issue due to the demographics.

Posted June 29, 2009 at 9:18 PM | Permalink | Reply

Richard

I think both neilsen and you have missed a big issue. If I go to a site and the password is not masked, it's going to feel very awkward. It's the same thing if the site uses some label other than password (e.g. PIN, passphrase, etc.) - it's just weird and doesn't feel right. It has nothing to do with whether it's secure or not. As soon as I read Neilsen's article I thought he had lost his marbles. He could have made a very good case for keeping the mask and keeping the label "password", but no, he had to go the other way and lose credibility.

Posted July 01, 2009 at 2:07 AM | Permalink | Reply

Jason Montgomery

Richard - You are correct! I would guess usability as well as a sense of security is about the users' expectations. Changing expected behavior into something that may appear less secure could ALSO cause a loss of business.

Posted July 02, 2009 at 6:33 PM | Permalink | Reply

Steve

Reggie,

Computer users are more savvy than ever, but they can't remember a strong password? More likely they just chose not too, because a good policy was not properly supported.

My personal experience: strong passwords work very well, just spend a bit of time working with your user community to come up with easily memorized passwords so they don't just write them down.

Our security policy includes removing any postings that look like password notes. Our information is worth protecting.

Posted July 04, 2009 at 12:07 AM | Permalink | Reply

Andrew Chee

http://andrewchee.tumblr.com/post/129688047/in-response-to-jakob-nielsens-stop-password-masking

Posted July 23, 2009 at 7:58 AM | Permalink | Reply

Klaus Johannes Rusch

<a href="http://www.atmedia.net/KlausRusch/blog/2009/06/disagreeing-with-jakob-nielsen-on.html">Disagreeing with Jakob Nielsen on security, and a workaround to reveal passwords if needed</a>

Posted July 28, 2009 at 4:35 AM | Permalink | Reply

gtanuel

I'm a month late but here's my thought:
I agree much with hanford about the actual usability benefit [evidence] and Michael about the technicality (browser form data save feature).

In a place/system where its functions/services are considered critical (online banking, ATM, etc.), you don't want your password/pin entry to be fed back on the output screen in clear text, simply because you want the best possible protection that [you think] you can get. Admittedly there's psychological consciousness due to prolonged habit to see them masked, but there are other reasons as well.

Here's mine: people tend to have less than a handful of passwords we can memorize and their slight variations (e.g. to meet the complexity requirements). Any more complex than that, we would write it somewhere in anticipation we will likely to forget it in a month or so. Those memorizable password/pattern, we took effort to come up with in the first place to make them mentally storable and unique - at least to ourselves. In a way, it's becoming our 'intellectual property' which we're reluctant to share with anyone else because if one is compromised, it may compromise other passwords for other systems that utilize the same patterns. In short: we don't want to keep them anywhere else but our own mind let alone keeping/seeing them in clear text, anytime, anywhere. Consider the recent Twitter documents leak incident. The attacker managed to keep his hijack unknown to the victim because he's able to uncover the Gmail password by searching for any site new registration email feedback in the archive that may contain some password, any password: in clear text. I searched mine recently and surely enough there are 20+ results showing my Gmail password in clear text.

In closing: I don't want to see my password in clear text anytime, anywhere. It should be clear text only in my mind.

Posted October 02, 2010 at 4:28 PM | Permalink | Reply

jessica

What if we use the solution available on many mobile phones: you only see the last character of your pass, the previous part is masked.

Post a Comment






Captcha

* Indicates a required field.