9

I was reading about UX and passwords to try to decide on explaining the requirements (ex: 1 capital letter, 1 number, 1 special character,eight characters) and came across this answer which sent me down a bit of a rabbit hole.

I understand how passphrases might be easier to use than passwords. Mobile users won't have to switch keyboards. I can see how it might be easier to remember like the cartoon suggests. From what I can understand, after reading some posts and articles it is actually more secure which is good, of course. I'd like to encourage our users to create more secure passwords and hopefully help them develop good habits for other sites they visit. I went to read the OWASP recommendations based off of this answer but it actually has the typical requirements listed. Perhaps I'm looking at the wrong but I don't understand why it tells the OP to link to the OWASP when it's actually reinforcing the traditional guidelines.

Plus, I haven't found anywhere that actually use passphrases in all my time as a person who logs into sites. Or I haven't come across a site that asks for longer passphrases (Any examples out there I could see?) I suspect for the most part it's the user who chooses to do this. But most sites have informed users that the special characters and numbers are stronger so (again, I'm assuming, bad) I doubt many people do it. Should I just let them create a password and encourage them to create a passphrase? Again, this accepted answer says no. So lets say that I don't.

Going this route also makes them think about passwords in an entirely new way. They're accustomed to dealing with the typical password generation process used to meet all of a website's password requirements. Especially if they're allowed to reuse the same password across multiple sites. Which, we know that's not good, but they like that. So while that's kind of frustrating, it's also expected and not much of a surprise. That has to speak to usability to some degree, right?

This post is now kind of a two-parter:

1) I'm trying to figure out the best way to implement this so I can decide if I want to make the push for it or not. I have worked it out a bit in the wireframe below. The user clicks 'what's this' and then it shows the pop up to teach them. They click the learn more and get the details on the increased security benefits and ease of use (since we think it's easier to remember). I thought I was going to send them to the OWASP site, but now I'm not so sure. I don't really want to show a cartoon because it's a cartoon and this site is not that kind of site. I'd also keep the user from using my example passphrases. If I give the user the guidelines for passphrases on the login screen like I do on the sign up screen I think that'd help with the usability. This post gave me that idea. The wording in the pop up will change. This post also gives some feedback into how to educate the user.

Also, look at all that text surrounding that passphrase input field. It's crazy. But if I'm going to try to teach them and make it easy to use, then isn't all of that necessary? Do I need to confirm a passphrase if I give them the ability to show it instead of masking it?

enter image description here

Can I make the process better?

2) Passphrases are so different I'm having a hard time actually convincing myself to use it.

This question kind of broaches this subject but it's more on labelling and not really on the usability of the idea itself. The accepted answer does have ideas on how to educate users about passphrases which help for the first half of my question, but I'm still wondering about the usability of this technique.

Has anyone tested the usability of passphrases over passwords? Has anyone out there implemented it? How successful has it been?

The last thing I want to do is implement something like this based off of four posts I found and then discover it's too frustrating. I'll do some wireframe testing of my own but if I can get some feedback before making the argument for this approach it'd be helpful. I think it's going to raise some eyebrows.

Basically, I'm confused. And I'm a UX team of one. StackExchange is about the only place I have to throw a question like this. This may be too broad to live here. You guys just let me know.

  • Bear in mind that OWASP is actually in need of UX / usability advice. They've asked researchers for help on producing usable security advice, and I'm currently looking for students / FOSS enthusiasts to build and deploy the research tools we need to provide OWASP with that information </shameless-advertising>. – Steve Dodier-Lazaro May 12 '15 at 17:34
  • 1
    Maybe this questions and answer(s) will help? – RoraΖ May 12 '15 at 17:46
  • 1
    Passphrases are often used in the digital currency world, where people are somewhat more security-minded than average. I don't think passphrases are "easier" because most people are unfamiliar with them, and if you only require 16 chars my guess is the security will be less effective than traditional passwords. I would follow the more common password practices that people encounter when they sign in for email or their Amazon account. If you need extra security go with 2 factor authentication. – obelia May 12 '15 at 17:47
  • 1
    Raz, that link you sent helped, too. Okavango, your illustration was great and I actually did end up implementing something like that to encourage them to use a passphrase. Obelia, your suggestion for 2 step authentication was pretty good. Not sure if I'll get the chance to go that route, but I like it. It was also nice to learn where passphrases are generally used since I haven't come across one yet. Thanks everyone! – Fletchling May 24 '15 at 23:04
  • @obelia the numbers speak for themselves. 16 characters of lowercase characters gives you 75 bits, equivalent to a 11-12 character password comprised of uppercase + lowercase + digits + symbols (assuming both words entirely random), and the issue lies entirely elsewhere: user-chosen passwords are not random, and the addition of structural fluff (mandatory symbol sets) introduces more effort than it introduces entropy. – Steve Dodier-Lazaro May 25 '15 at 0:21
7

Security engineer / usable security researcher here. Most often the security advice handed out to website makers is not evidence-based, and even though we have plenty of knowledge and data about passwords, we know little about what makes them work. If you wonder why they're still around, Herley and Oorschot's 'A Research Agenda Acknowledging the Persistence of Passwords' might give you some ideas.

The main responsibilities you have with regard to memory-based authentication factors as a service provider are:

  • to prevent people from using obviously very guessable / common secrets
  • to properly store their secrets so that you don't compromise users' security
  • to be upfront and efficient about communicating security breaches
  • to not get in the way of the variety of secure password/passphrase practices out in the wild

Let's get into detail.

Prevent obviously wrong choices

You must compile, store and update a list of the most commonly used passwords and of common dictionary words and prevent your users from using such words as passwords. Choosing very predictable or common words is very detrimental to users because their accounts will be the first to fall when your database gets breached.

Likewise, if you give specific examples of passphrases, you must forbid your users from using those (stating that these are public examples and that attackers might test those first). You could work around the fact that some users will pick those ready-made example passphrases by generating random ones on every page load on an already encrypted connection.

Properly store secrets

It goes without saying... or does it? See those Security Stack Exchange questions:

And some more advanced, specific questions:

Just don't be that moron that compromises millions of unsuspecting individuals because they didn't want to spend a few hours improving their hashing and salting procedures. Especially, these operations are now trivial with web development frameworks.

Be upfront about breaches

If you have good reasons to suspect you have been compromised, you must immediately email all the potential targets and let them know that their password has been compromised, and that they must change this password wherever they use it.

Of course this is not your job as a UX consultant, but from your users' perspective, it's a very important aspect of good security hygiene so your company / agency should ensure they communicate such information.

Don't get in the way of secure practices

There are many ways to deal with the fact that we're asked to remember more passwords than we can, and asked to create insanely complex and even unique passwords (as if we had just that to do).

Keep in mind that ultimately, if you ask people to create 50 four-word unique passphrases, memory interference will kick in just the same as it currently does for passwords, and users will hate passphrases no less than passwords.

Typical coping strategies include:

  • federated authentication - you must support OAuth2, Google Auth or Facebook connect unless you have very good reasons not to.
  • password managers - these can create long, random passwords so you shouldn't prevent people from creating reasonably long passwords with any sort of structure
  • actual unique and strong passwords - some people, including me, reward high-value service providers that respect them by actually going through the pain of remembering a unique password. However if you start asking your users to change their passwords every other month or impose silly restrictions on them, don't expect them to make this effort
  • strategic password reuse - why would users create a strong and unique password if the consequences of a data breach are marginal for them? Surely their bank account is more important than your local book club's newsletter. Please accept that and move on.

Besides, keep in mind that input modality matters. If I have to use your site via a mobile UI, there's no way on earth I'm going to type 16 characters; the error rate would just be too high, notwithstanding the actual typing time!

In the end, passphrases have no specific requirements that justify getting in the way of other approaches. You can recommend users to use passphrases rather than difficult passwords, but you shouldn't force them to.

4

Lets start with the essential, whatever solution you choose to go for, test, test and test again... its worth every effort!

Now to the core of your question:

Passphrase vs Password

Passphrases are great way of dealing with forgotten passwords as they are generally "generated" from user memory and might also remind user of a specific situation or emotion... etc. So, they work well as an alternative to arbitrary passwords. That being said, I don't think you should enforce their use for the following reasons:

  • Users are acustomed to using "username" and "Password" approach and I think that this approach is so embedid in the way we do things that its not even worth trying to change it. Remember, people are not only using your site but many others as well and the norm is kind of set!

  • Requiring a minimum of 16 digit passphrase might alieante people who are used to inputing passwords with a more limited number of characters,so your solution might not be inclusive enough to allow ease of use for everyone.

  • Trying to come-up with a pass phrase could overcomplicate the task and overwhelm some users, particularly if they have to go through a number of mental associations before they are happy with the end result. This takes time and as you know... time doesn't really work in your favour!


Handover control to your users

Encorgaging users to use a passphrases instead of a password is definitely a step forward, enforcing their use is however a step back as your are removing control from users and in the process alienating some of them.

What you could take away from this is:

Encouraging users to use a passphrase is more geared towards providing information and useful tips to aid with the conventional process but not to replace it.

Of course their are smaller enhancements that could go a long way in improving this process such as the use of unmask password functionality.

With that in mind, I think you can make use some interactions to allow users to access information about the strength of their password and advise them more explicitly to use passphrases for better password memorability. Even better, You can use a password strength meter to help them create a stronger password.

The wireframe below encapsulates some of these idea, Good luck!

enter image description here

  • Please don't tell people to use unique passwords everywhere, all the time. That's a very unrealistic requirement and nobody does it. It's better to only ask for it when it's crucial (e.g. finance and email apps). – Steve Dodier-Lazaro May 12 '15 at 17:30
  • @SteveDL Agreed! Context should determine password criteria. – Okavango May 12 '15 at 17:36
  • 3
    @SteveDL: Actually, some people do use unique passwords everywhere — people who use password managers. It's scarcely harder to generate a unique complex 20-character password with upwards of 100 bits of entropy than it is to reuse the same one for several sites. Although looking at your answer, I see you're aware of those already. – Nathan Tuggy May 12 '15 at 18:58
1

Can I make the process better?

Yes. Just give them a password field:

Password
[                     ]

If they want to use a passphrase, a password, or just 12345678, let them.

If you have to have some level of checking, then perhaps implement some minimum criteria, but for the most part, password requirements are usually more of a pain point than user benefit.

  • 12345678 is not always acceptable. If OP is implementing a small community site or blog with no security implications, then that might be an acceptable oversight, but if any harm can be done to users with weak passwords, then OP should filter out commonly used passwords (and let users decide what uncommon password to use) – Steve Dodier-Lazaro May 12 '15 at 17:27
  • @SteveDL hence my suggestion for 'some minimum criteria' but it should be pointed out that that is still a user annoyance. You are correct in that it may very well help with security. And that's good, of course. – DA01 May 12 '15 at 17:34
  • I just meant to point out that the 'minimum criteria' should precisely be to forbid obviously known passwords -- attackers who steal a hashed password db will try those first and break any account using them in a matter of minutes. For the rest, I'm also in favour of not getting in the way of people's habits -- that's often detrimental. – Steve Dodier-Lazaro May 12 '15 at 17:36
  • But, that said, there's a fuzzy line here that is often crossed in the name of trying to 'help users have secure passwords'. A lot of password restrictions actually ENCOURAGE weak passwords. If you insist my password have punctuation, a number, and a capital letter, people will just enter A1! or some common 'beat the automated checker' phrase--which can ultimately be a lot less secure than a long purely alpha-based phrase. So I strongly encourage minimal password requirements. (See also sites that turn autocomplete off on password fields...it can backfire) – DA01 May 12 '15 at 17:37
  • 1
    Oh yes, I totally agree. We now have kinda good models of the predictability or guessability of a password, though the existing prediction models are too US-centric (and possibly desktop-centric?) and don't apply to other languages, cultures, etc. The important opportunity for improvement in password policy is to combine those general models of predictability with the actual practices and needs of individual users (on this front, research is severely lacking as of now). – Steve Dodier-Lazaro May 12 '15 at 17:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.