Implementing a passphrase instead of a password

Question

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?

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.

Answer 1

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:

• How to securely hash passwords?
• How to store salt?
• Why are salted hashes more secure?
• Do any security experts recommend bcrypt for password storage?

And some more advanced, specific questions:

• Are efforts being made to bring about password standards?
• What technical reasons are there to have low maximum password lengths?
• Is “the oft-cited XKCD scheme […] no longer good advice”?
• Why don't we reward users who choose strong passwords?

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.

Answer 2

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!

Answer 3

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.