Since starting my new role I've found that 20% of log in sessions are resulting in a dropout.

From watching user recordings, I believe this is down to users forgetting their password. Users log in with their email address and a password that consists of:

  • UpperCase Letter
  • Lowercase Letter
  • Number
  • Special Character

I'm now looking into ways to resolve this issue and reduce this percentage. I have previously seen the question regarding showing password complexity on the login page but that is a no go from Security.

Would reducing the password complexity for future registrations/password resets be a viable option? Could a reset prompt be emailed to users offering them the chance to reset their password with less complexity if they have had trouble in the past?

  • 6
    Take a look at this question at security.stackexchange.com. I think it covers your question in depth. – Tom K. Jun 6 '17 at 12:57
  • 2
    This is a good question. From a security standpoint I completely agree with the complexity requirements, but purely from a UX standpoint these requirements can be counterproductive obstacles. I've often wondered if requirements should really be recommendations? Like a seat belt that can be taken off at the user's own risk. Obviously not all sites could use this approach due to company policy or other factors, but many could. Occasionally I intentionally want to use a simple password. Like signing up for a low-risk service on a desktop, then later logging in from a smart tv or a phone. – Ben Harrison Jun 6 '17 at 13:36
  • 26
    password rules are bullshit – hansmaad Jun 6 '17 at 14:04
  • 3
    If you can find the password complexity rules anywhere on the site without having to actually enter a password, it makes no difference where they are- an attacker can find them and exploit them. Since the password requirements are probably accessible to your registration page, and registration is usually public, you aren't exposing more security information by putting it on the login page too. As a way to do it, I'd suggest you might pop it up after a couple failed password attempts. – Delioth Jun 6 '17 at 16:53
  • 6
    From a usability perspective, you should have three rules for passwords: 1) The password must be suitably long. 2) The password must not be the same as the username. 3) The password must not be on the list of most common passwords. Anything beyond this reduces usability, which in turn reduces security as people apply strategies to work around your rules. – Mark Jun 7 '17 at 0:23

Average person has 19 passwords


https://nakedsecurity.sophos.com/2014/10/17/average-person-has-19-passwords-but-1-in-3-dont-make-them-strong-enough/, 2014

Imagine how many passwords the user needs to remember! Asking your user to have 5 requirements

  • Uppercase Letter
  • Lowercase Letter
  • Number
  • Special Character

increases the safety, but also increases the complexity. So 20% of dropouts seems logical.

Option 1 Decreasing the requirements is a logical option, as long as it does not make the system less safe.

Option 2 Sending an email to you users when they try to log in after x number of tries, and asking them to reset their password is a nice option as well. The drawback is that they will still need to create a complex password.

Thinking out loud What about reminding them that they password meets the following requirements? If they know what requirements their password meets, maybe they will remember also the password. This is kind of a reverse engineering way for your users.

Therefore, the best option is Option 1. You will need to convince your security that this is the way to go. There must be a way to settle this in the middle because the user should be able to log in easily but security should not be compromised.

This article (https://uxplanet.org/why-complex-passwords-are-bad-design-and-5-ways-to-do-better-affcc4516406) could be of a great help and it provides 5 ways that can help your users get their passwords better.

  1. Explain why they need secure passwords
  2. Make it easy to create a password
  3. Use social login
  4. Use only email address in your login form
  5. Remove sign up wall completely
  • 1
    I'd like to chime in on this as a member of the security auditing industry. Never, ever, list the "requirements" for the password on the login page or upon a bad login. It simply gives attackers a easy way to identify which restrictions to place / remove on their brute-force tools. Similarly, "Only use email address [...]" is pretty much just advertising for malicious logins. Social login options are probably your best bet if you don't want to be the "bad guy" by asking users to be bothered to create and remember a secure password. – WorseDoughnut Jun 6 '17 at 16:53
  • 3
    @WorseDoughnut What if we all just used the same, good-enough requirements? I don't use Facebook or Google+ etc, and even if I did, I would not want all my accounts cross-connected, so I don't agree with that solution. – user67695 Jun 6 '17 at 19:20
  • 1
    @nocomprende First off, the google sign in is through a "Google" account, not exclusive to G+, but any/all of google's platforms(Gmail, youtube, Android, etc.), but you're correct in that relying solely on social is a bad idea in some POVs, but when the alternative is sub-par password security, it's better than that alternative for sure. Regardless, there is no "good enough" that isn't just a significantly long password, but that lands us back in the camp of "can't be bothered to remember it". – WorseDoughnut Jun 6 '17 at 20:12
  • 5
    @WorseDoughnut listing the requrements shouldn't be a security issue. Anyone wanting to know them can just look at your registration or password update pages, and you need them there so people know how to make a password in the first place, it's hardly secret knowlege... yes to password managers though. – Baldrickk Jun 7 '17 at 13:59
  • 2
    @WorseDoughnut Hiding it from the login page but including it in the page to register means you don't hide the information from attackers at all, but you're still hiding it from legitimate users. Actual security doesn't "hide" password restrictions so the attacker spends 10 more seconds before bruteforcing the login form - actual security simply doesn't allow bruteforcing the login form. – Peter Jun 8 '17 at 12:13

The most common solution I've seen to this is including Facebook and Google login, considering most users will already be logged in to either of the social sites.

Buttons for ‘Login with Facebook’ and ‘Sign in with Google+’

  • 5
    I agree with @DimitraMiha, sometimes adding external login providers is a no go mainly because it doesn't fit with the application, or the user account could be a group account and used by more than one person. A good suggestion though :) – George Jun 6 '17 at 13:03
  • 31
    This is a great solution as long as it's an optional requirement and creating a standard account is still possible. If there are only those possibilities you will lose some users because many people are hesitant when it comes to linking FB/Google accounts, probably due to the fear of the personal data being abnormally accessed, or the fear of the unwanted publications on one's social media profile. – Tim Jun 6 '17 at 13:13
  • 13
    @TimF Right, I do not use Facebook, or Google+ or OpenID, or or or... So when I see those "Log in Using" boxes, I close that browser tab and find something else to look at. If a site that I do not absolutely need requires logging in, I do not use it. All those boxes that say "BlahBlah wants your location" or "wants to send notifications", etc, I close the tab and find something else to look at. If I wanted to be heckled and evangelized, I would go to church (which I also don't). To me, the browser is like a piece of glass, it should not know anything, do anything or be anything. – user67695 Jun 6 '17 at 14:16
  • 9
    As someone who has implemented both FB and G+ login, and seen what amount of personal data they pass to third parties by default. Let me just say that I am comfortable using G+ to create accounts on any reasonable reputable site, but I will never use FB to log in. – stannius Jun 6 '17 at 16:17
  • 4
    If you do this, always provide a non-third party way to log in. I don't and won't use either. – Criggie Jun 6 '17 at 23:39

The very famous xkcd comics about password strengh come to mind.

What you really want is not a mix of lowercase, uppercase, number, and special character. You want a password with a lot of entropy and the user to not be bothered unneccessarily. So I think that what you should do is getting rid of the arbitrary set of rules and focus on the password's entropy. Is the password hard to crack ? Long enough ? Not just the name of the user with his phone number at the end ? Not just "mypassword" in l33t speak ?

In order to do this you can use the zxcvbn library. You provide the password, information about the user and you get a grade between 0 and 4. Then you can reject the password if it's graded less than x. It provides indication on how to make the password harder to crack if the grade is low enough. You get security, and users get to use the password they want if its strong enough.

I work in an environnement where the requirements you're talking about are enforced and some of the password of my users are graded from 1 to 4 by zxcvbn, because a password used very often can pass the requirements (For example "Myp@ssword1", "1Azertyuiop^" or "3.1451592Pi"). So it's actually more efficient to use this library for strict security reasons.

  • 1
    @Celos : No plain text passwords are stored anywhere if that's the question. I'm calculating the zxcvbn score when the user enter the password to log in, then I save the score. A score of 2 is'nt so bad its only "somewhat guessable: (guesses < 10^8)". – Pierre.Sassoulas Jun 6 '17 at 14:06
  • 3
    I hope the score is stored anonymoysly or at least on a different server than the password hashes. Otherwise, you're pointing to the passwords that will be easy to crack. – Dennis Jun 6 '17 at 14:13
  • 1
    The hash are not stored on the same server, I'm using a remote authentication service. But you raise a good point, the score do point to the user with the less secure password and storing the advice and warning would further help an attaquer. ("Uppercase does not help much", would help much). You probably want to just display those information to the user when he or she choose its password and delete them afterward. – Pierre.Sassoulas Jun 6 '17 at 15:11
  • 6
    +1 for the xkcd link; it's an answer to this question all of it's own. Nothing pisses me off more than a site that doesn't allow spaces in passwords, or limits them to e.g. 16 characters long - there is absolutely zero need for such pointless "passphrase eliminating restrictions" in today's world.. – Caius Jard Jun 6 '17 at 16:05
  • 2

There's a similar discussion in the comments of this response to a similar question the response to this question.

Tight password restrictions are fantastic at increasing traffic to your password reset page, to the extent that you might as well make all users log in via email rather than provide a password at all.

One suggestion I see regularly is to have no restrictions on passwords, and have a password-strength indicator to encourage the user to provide a secure password. But all this does is let the user decide between getting their account hacked or having to use the password reset form each time they log in.

So far the best solution I've found is to allow login through Google/Facebook/Twitter, but I'm yet to see any recent evidence to the effectiveness for this. Back in 2012 it certainly wasn't well adopted, but it might be worth asking your users to see if it's relevant to them.

  • @nocomprende That's certainly a disadvantage, but given that approximately 55% of users use the same password for all websites (nakedsecurity.sophos.com/2013/04/23/…), it's a problem which is prevalent with all login systems. – Joel Tebbett Jun 6 '17 at 19:37
  • I bet that 55% of people do not use the same key for every lock they need to get in to. So the solution is... Issue keys, and users keep them on keychains. If that is the solution, let's do it then. – user67695 Jun 6 '17 at 19:57
  • 1
    @nocomprende Great analogy, I love it. I keep all of my keys on a keychain: house keys, car keys, work locker key. If I lose it, I lose it all, but the convenience of having them all together outweighs that small risk. I'm improving my user experience significantly at the cost of security. There's no silver bullet (yet) when it comes to UX and security. – Joel Tebbett Jun 6 '17 at 20:31
  • I keep a spare housekey in the car, an extra car key in my wallet, and other copies at home. I also don't keep them all on one chain: each car key is separate because I can only drive one car at a time, and someone else can also use that car, even when I am out taking a walk. Work keys I only carry at work. The crucial point was that I don't make the keys, so there is no possibility of duplication or choosing an 'insecure' key shape. – user67695 Jun 6 '17 at 21:21
  • @nocomprende But surely this just makes the keychain the single point of failure? This would certainly be the case if someone found the password for my iCloud Keychain, and even worse, it would give them a tidy list of all of the sites in which they can use those passwords. I am of course playing devil's advocate here :) – Joel Tebbett Jun 6 '17 at 21:42

Help the user come up with more intuitive passwords. It's daunting when you come across a set of requirements that says something along the lines of:

  • You have to come up with a SECRET PASSWORD.
  • It has to have NUMBERS (Americans hate math).
  • It has to be at LEAST this long.
  • It has to be at MOST this long. (ed: why?!)
  • It has to look like THIS: @#$346%^&*(D

If I were still designing public-facing apps in this day and age, instead of a block of nonsense like the above, I'd tell the user:

  • "What's the first thing someone ever said to you that made you really happy?" Add a few other prompts/suggestions relevant to your business case, but try to avoid prompts that are relevant only to the here and now or are very common-- i.e. favorite song lyric, etc).
  • Capitalize and punctuate it as proper English.
  • Add a number to the beginning or end.

With that, you've met all the password complexity requirements, introduced a ton of entropy into every user's password, mitigated the scary and overrated aspects of password complexity and if they struggle with remembering it, remind them that they're on that weird site that made them use an entire sentence written in proper English for a password and what the suggested context for it was.

  • 1+ Then at least the crooks will have to be able to write proper English! (is that your password?) (Shh! you'll ruin the story) – user67695 Jun 6 '17 at 19:26
  • 1
    "Capitalize and punctuate it as proper English" and "Add a number to the beginning or end" - These are not good suggestions. They won't help with entropy. Clever password libraries easily account for these nowadays. See: (1) , (2), (3), (4), (5). – Marc.2377 Jun 7 '17 at 6:14
  • @Marc.2377 how many valid English sentences are there with say, 7 words? There's your entropy. – user67695 Jun 7 '17 at 12:31
  • "at most this long" - oh that's one that really annoys me - it gets hashed! (or should be) it doesn't matter! - it really makes me wonder about the quality of the authentication system. I can understand a sensible limit, of say 128 characters or similar, there isn't really a need to be using books as passwords, but limits of say 10-12 are stupid. – Baldrickk Jun 7 '17 at 14:05
  • 1
    @Baldrickk The financial institutions started this problem as the result of the password being stored in a mainframe datatype that can only hold 8-12 bytes max. Modern systems don't have such technical limits but somewhere along the way people assumed "if the banks do it, it must be best practice!" – Ivan Jun 7 '17 at 14:27

To add to the other answers, another way to make it easier for the users to remember their password is to offer a reminder picture and/or text they can set when they first setup their account. Show that picture or text when they have to enter their password to help them remember.

For example, I could have "piZza2014!meLike" for password. I would of put a picture of the pizza I had during my vacation in Italy in 2014 and maybe the word "facebook" to remind me of the "meLike" part.

Humans remember visual cues much more easily than words.

  • One high security scheme is that the photos and the user's recognition of them are the password. Show the user a bunch of photos and they have 3 seconds to touch the ones they recognize. Can't be stolen, spoofed, shoulder surfed, tortured out of someone, lost, misplaced, etc. Done. – user67695 Jun 7 '17 at 12:29
  • "can't be shoulder surfed"? Why wouldn't somebody looking over your shoulder be able to tell which pictures you touched? – Stephen Ostermiller Jun 7 '17 at 18:42

Passwords suck. I have said so many times and I will say so many times in the future. They have been broken from the time of Aladen and his cave and have only gotten worse since. cutting off peoples head on wrong passwords is an excellent way to prevent brute forcing but not exactly popular or easy to implement on the internet. I have looked at various methods to replace passwords. Everything from kerberos to ssl certificates. I have played with one time passwords, hardware modules and biometrics. The one thing they all have in common: they don't work in places I don't have control over. I cant use them at the bank or to check email. they are not used for credit card verification (although this is starting to barely improve) or to order pluming parts. I even looked at running my own oath server, but no one was willing to authenticate against it. So I use a password manager and curse loudly when someone makes it hard to use a password manager in the name of security.

What can you do to make my life easier?

One: allow multiple forms of authentication. If I want to use Google, fine that works. If I don't trust Google, fine it is not required. If Google goes down, fine there are other options.

Two: allow experimental forms of authentication. (but not as the only method) Let me play with time based one time passwords. They might suck, but they might not. let me play with client side certificates or hardware security modules. Although none of these may be the solution we are looking for we wont know until we try, but we know passwords suck, we already tried that.

  • So, what has worked in the past? A hard to fake form of ID issued by a trusted authority, like a passport or driver's license with a photo. This is my solution: when you are born, about 100 cryptograpically enabled rfid chips are embedded in your body and the public part of the challenges are published ubiquitously. It can't be stolen, spoofed, altered, etc. Done. – user67695 Jun 7 '17 at 1:43

Not only is mandatory password complexity a nuisance, so is frequent mandated password changes, according to the Chief Tech Officer of the U.S. Federal Trade Commission. I remember when I first read this feeling elated that someone finally gets it!


I would remove the complexity requirements, but reduce flexibility. Here's what I mean by that:

Instead of telling the user

"Choose a password that follows these rules, and hopefully you'll choose one that's so complicated nobody will be able to crack it, yet not so complex that you'll have trouble remembering it"

it would be

"Here's your password. Memorize it."

For security, this password should be randomly generated. For ease of memorization, instead of random letter/number/symbol combinations you could follow XKCD's suggestion and use random words.

Your Answer

