Almost every web service I can imagine has the user pick the password. Why is this? Couldn't the system choose a better password? It doesn't have to be some complicated mess; see this answer. Do users just find their own choices more convenient? When selecting the password for the user, you know the entropy, as opposed to placing some restrictions that may prevent them from using a low entropy scheme.

Why do we let the user pick the password?

  • 72
    If you make me remember your password, I'll forget your service.
    – Vercas
    Apr 14, 2015 at 22:15
  • 8
    It doesnt matter how secure a password you force the user to use if they write it down or put it on pastebin because they cant remember it.
    – Vality
    Apr 14, 2015 at 22:35
  • 10
    @Vality - that's not entirely true. If I pick a weak password on a web service, anyone in the world can try and guess it. If I use a strong password and write it on a post-it note on my monitor at work, a very small number of people I generally have to trust anyway have access to it. If I write it down in a password manager application that's protected by a password I don't write down, it's even harder for anyone else to access.
    – armb
    Apr 15, 2015 at 10:49
  • 16
    An actual example: My online bank generated a password for my account, which is only 5 characters long and can not be changed. That is not a happy feeling...
    – Lars Ebert
    Apr 15, 2015 at 15:07
  • 6
    @PyRulez No worries. I would not have posted that comment if I still was with that bank!
    – Lars Ebert
    Apr 15, 2015 at 19:31

11 Answers 11


Why, indeed?

Allow me to ignore that question for a moment, and answer your implied question: Should we?
That is, should we continue to have users create their own password, which is often weak, instead of just having the system generate a strong password for them?

Well, I am of the controversial opinion that there is a pretty strong trade-off here - having a secure password, and KNOWING how secure it is (as you point out), on the one hand, and on the other side is the user's feeling of security. "Usability", to some extent.

I think there are several aspects to this feeling of security: some users would want to ensure that they have a strong password themselves (e.g. via a password manager, or diceware); some users would want to select an easy password; and some users want to use the same password everywhere. And yes, many users just plain expect to be able to set their password, for whatever reason - so besides any specific cause, you will still need to fight the re-education battle, which is far from easy.

Also, don't forget that once you get a good strong password to the user, the (often non-technical) user still needs to figure out what to do with it - even passphrases become difficult to remember after the first dozen or so, or if you only use it every 6 months... The non-technical user would most likely save it in a word document on their desktop, or in their email. (And of course write the OS password on a sticky note attached to the screen).

Now, don't belittle these reasons, or these causes for using weak passwords - we the security industry have created this scenario for the simple folk over years. But it really comes down to: how secure do you need your site to be. How much risk can the user decide to take upon himself/herself, and how much of that is system risk that should be taken out of the user's hands.

So bottom line: Yes, I think most sites that have non-negligible security requirements should offer password/passphrase generation. Depending on the profile and architecture, you could offer 3 options when registering an account (or changing password, etc...) - just make sure to only display the password after warning the user against shoulder-surfing:

  • Generate passphrase - with a configured or flexible number of words (default)
  • Generate crazy-strong password with ridiculous entropy, e.g. for saving to password manager
  • Create your own.

In fact this is what I've been recommending for some time now (variants dependent on the specific requirements...).

Going back to your original question, why is the above not done?
I would guess a combination of legacy systems and bad habits; mis-education (the overwhelming majority of sites still have BAD password policies and recommendations); and perhaps just a lack of awareness of a better solution.

Yes, this is why passwords suck. :-)

  • 34
    And as a user, I want to choose my level of security. I reuse a certain (easy) password quite a bit. It's what I use for garbage accounts, or things that otherwise need no protection in my case. Apr 13, 2015 at 21:34
  • 9
    @PyRulez the reality is a bit more nuanced. Few non-security professionals have more than a handful of passwords, of which they create variations. There are no password strength metrics that fully account for this phenomena, as the security community still hasn't developed the tools to study the effects of password reuse, and the models to plug onto those tools to estimate the risks of different reuse strategies. Read up Cormac's papers on password portfolios and watch our group (sec.cs.ucl.ac.uk) closely if you want to know more. We have a team working precisely on this. Apr 13, 2015 at 23:19
  • 5
    Storing passwords on your desktop without any kind of cryptography is pretty bad, because an attacker gaining even just a read-only access to your box might get them. You'd rather use a KeyPass or such to mitigate this risk. Regarding the "password on a sticky note", I honestly think that's not such a big deal, physical security is far from being the main concern in most attacks, and if the attacker can read your sticky note, he can most likely have a direct physical access on most of your boxes, it's already game over.
    – Dillinur
    Apr 14, 2015 at 14:01
  • 24
    "Generate crazy-strong password with ridiculous entropy, e.g. for saving to password manager" -- I'd be interested to know whether anyone actually takes this option, since password managers can generate crazy-strong passwords for themselves. Doesn't do any harm, but seems a bit like offering a barking service to dog-owners ;-) Apr 14, 2015 at 14:03
  • 5
    @paj28 Not me, but every single program on your computer can.
    – Navin
    Apr 15, 2015 at 16:15

Getting the password to the user

The only times I have seen systems that set the password for the user, it is send to the user via email (obviously in plaintext), which is obviously a bad idea[*] (and SMS, Mail, etc are not that much better).

So that would leave displaying the password when creating the account (which might also be a bad idea because of shoulder surfing). I would assume that this would lead to a lot of users who would overlook this, or not realize that it is important. Users are used to remember/write down/store passwords when they create them themselves, but they are not used to reading some page after they created an account; many would most likely just ignore it.

[*] because anyone gaining access to the users mail account (brute force, user forgot to log off, etc) will not have access. If an attacker uses password reset to gain access, a user would at least notice this.

Getting the user to remember the password

Users need to know their passwords. Typically, they have a couple of options for this (memory, writing it down, or storing it in a file or password manager). One of the primary ones (memory) would not be practical with your approach[*], which I would assume is the main reason that websites do not generate passwords for users.

[*] even with easy-to-remember generated passwords users will still have a harder time remembering that than passwords they chose themselves.

User Experience

Security is not the main business of most web services. It's often more important that users are happy, and many users will not be all that happy if they cannot chose their own passwords (because they do not want to remember generated passwords, and they do not want to write them down, and they also do not want to use a password manager). Users just want to use a service, and anything that makes that more complicated can potentially lead to a percentage of people using a competing service.


Passwords are always a tradeoff between usability and security, and not letting users chose passwords reduces the usability of a service too much for most of them (and because of the problems of actually getting the generated password to the user, it might not even add all that much security).

  • 4
    +1 for the first point, the average human brain still remains the most secure storage of raw sensitive data. (from an architectural point of view of course) ;) Apr 14, 2015 at 13:36
  • 2
    I find the first point pretty dubious, with access to the user mail account, you can already reset his password for basically any website.
    – Dillinur
    Apr 14, 2015 at 14:03
  • 1
    @Dillinur yes, I did mention that. But resetting is different than knowing the password because the user notices it and can then take measures (like changing passwords, etc). Also, I could imagine that users would reuse passwords that are generated for them at websites that do let them chose their own password (so that they have to remember less passwords).
    – tim
    Apr 14, 2015 at 14:36
  • 3
    +1 For user experience. I've not used services because they restricted my password choice too much. If I wasn't even given the option to choose my own then I'd give up straight away and give the screen the middle finger. Rule number one, don't piss off users, let them do what they want.
    – Novocaine
    Apr 15, 2015 at 11:18

Organisations want users to be responsible.

If the user chose the password, they can be blamed for choosing a bad one.

Unfortunately, in the real world, organisations may have to be more concerned about seeming to take some of the responsibility for intrusions than about insuring they can't happen.

Users want to choose something they can remember

Many users will not write down their passwords (setting aside whether this is a good idea or not). They prefer to choose something they think they can remember. (This is especially important for the thousands of sites that shouldn't need a password but force users to pick one).

  • 5
    Your point about blame is spot on. Most web sites tell you to pick a unique strong password and never write it down. No-one is actually going to be able to do that for all their online accounts. But now it's their fault, rather than the web sites! The solution? Password managers!
    – paj28
    Apr 14, 2015 at 12:19

One respondent touched on the right answer, but didn't expand on it enough, so I will.

You are asking the question from a computer- or IT-centric perspective. But why does that IT exist? To serve the customer. Let me repeat this: The customer is not there to serve you, you are there to do what they need you to do.

So with that in mind, let's revisit the question: Why do we still allow customers to choose their own passwords? Why don't we set passwords for the customers?

Because if we force passwords on customers, what do you suppose they are going to do? We imposed something immemorable on them that they need to know later. I guarantee they are going to grab a Post-It and write that password down.

You have failed. Passwords written down on paper are a security failure. You never want that to happen. And before you blame the customer in this case, you're the ones who forced them to use a password they had no hand in creating. They had no chance to make it memorable. You told them "Memorize 'F82$fVq9' and don't write it down." As a customer my first reaction would be "F*** you." Companies don't get to tell customers what to do. Customers will find ways to rebel, including writing down your random passwords. Don't fight human nature. You. Will. Lose.

This is why we let customers choose passwords. If your site is worth any salt, it does as most sites do today, it checks the chosen password strength. It ensures the password is 8 characters long, has two digits, an uppercase character, and a symbol.

And you've still failed your original objective because today's computers can brute-force 8-character passwords in seconds. Just sayin'.

You want real password security that the customer chooses and where you're also happy with the strength? Here you go: https://xkcd.com/936/

  • 5
    I think you missed the point of the question, if you even read all the way through it. The OP specifically refers to xkcd-style passphrases (even linked to it), and explicitly mentions how your "Memorize 'F82$fVq9'" is broken, and typically what users do anyway - which is what the OP is trying to fix. This whole password requirement thing is something that IT came up with and enforces, its definitely not something for serving the customer.
    – AviD
    Apr 15, 2015 at 6:31
  • I mostly agree with this answer, but I don't think written down passwords are as bad as suggested. Extending this answer, we can say that some of our users are customers and some are employees. In certain circumstances, it might make sense to generate passwords for our employee users.
    – emory
    Apr 15, 2015 at 21:06
  • @AviD - What you can memorize/use easily is emphatically NOT what I can memorize/use easily; NOBODY can generate an easily-remembered passphrase for another person (without then going on to habituate the user by making them jump through that particular hoop frequently over an extended period). Whatever you generate for me may as well have been 'F82$fVq9'; it just requires more keystrokes per character, so to speak. Apr 16, 2015 at 3:24
  • 1
    @StanRogers that's actually a good point there - generic wordlists are generic, and do not take into account things like culture differences, language barriers, and globalization issues in general. Not to mention personal idiosyncrasies... That's why I recommended to offer generated passphrases, and never to enforce them. So it would be better in the general case, and revert to the status quo in the exceptions.
    – AviD
    Apr 16, 2015 at 7:34
  • I think this answer points out some very good/important points. We in IT often put our needs in front of the user needs. It is far better to let the user choose a password they are comfortable with and meet their security requirements. The other point to consider is how difficult it is to actually create a system which generates 'random' passwords that are user friendly (i.e. rememberable) AND don't exhibit a bias/pattern which could result in overall weaker security should someone guess the pattern
    – Tim X
    Apr 16, 2015 at 23:03

Think about it this way, if you choose the user's password for them, they will forget it, and have to use password reset systems.

The 'forgot my password' is usually less secure than the password, so making the password more secure, but causing more password resets makes the entire system less secure as it would be harder to detect fraudulent 'forgot my password' attempts.

Edit: I am assuming you don't work for a bank or nuclear weapons silo. If you do, please disregard my advice.

  • 1
    Why wouldn't a system be able to make a memorable password? Its a simple task. Apr 13, 2015 at 22:25
  • 4
    Count up how many passwords you have, I'm going to guess it's in the range of 50+. No-one can remember that many passwords, even if they are memorable.
    – Scott
    Apr 13, 2015 at 23:03
  • 6
    @PyRulez Define "memorable". Your usenet provider (which you use mostly through an exposed API and key between used by your software interface) gives you the passphrase "Blue elephants, only eat 12 green turnips" (punctuation and numbers intentional). You come back after not using the user-side interface for 6 months, because you want to change plans or buy more download quota. Dangit, what was that passphrase? Something about pink dinosaurs and onions?
    – killermist
    Apr 13, 2015 at 23:16
  • 10
    @ PyRulez Yes, I reuse passwords. If you work out how to post cat pictures for me on my reddit account, then you will also be able to post cupcake pictures for me on my instagram. I will live with either of these dire consequences. Unimportant services need to focus on taking up as little of my brain as possible, so that I can focus on remembering high entropy passwords for work, banking, and other things that have a consequence if the password is made public.
    – Scott
    Apr 13, 2015 at 23:49
  • 2
    If you work in a nuclear weapons silo, then the password is "00000000" (seriously!).
    – Simon B
    Apr 15, 2015 at 15:56

I don't pick my own passwords. I use a password manager that generates random passwords for me.

However, most web sites are based on the idea that users will memorise their passwords. It's much easier for a user to memorize a password they picked themselves, rather than one assigned to them. In practice as well, users typically use the same password on many sites, and while the small print will tell them not to, the sign up process can't stop them.

I strongly feel the "memorize your passwords" model is flawed, and a password manager is a better choice for just about everyone. But this is not the reality; I don't have figures, but even among my tech-savvy friends, using a password manager for everything is rare.

  • 2
    The problem with the password manager approach is that either you only have it on your main computer, or you trust a third party with all of your passwords (at least that they have the right crypto). I've not managed to overcome the fear of letting some sync service sync my passwords to everything.
    – RomanSt
    Apr 15, 2015 at 13:00
  • 2
    @romkyns - you can use your own password manager and sync the encrypted file through a cloud service, or a USB stick
    – paj28
    Apr 23, 2015 at 8:36

In many situations, the user is expected to be their own security watchdog because the user of the system is not the threat to the system. The threats to the system are administrators and employee-grade operators that by virtue of position have elevated exposure and permissions/rights within the system.

Without a seriously flawed system already, James Random Person won't be able to generate and add to his account $4 million out of bits and bytes, all by himself. He, or someone acting as him can only really damage his own account. The real threat is from those with elevated privileges/rights, that are on the inside. If James Random Person has a password of "xxxx22", and his account gets compromised, that's on him, not on you.

Yes, secure passwords/passphrases are a great idea. But as soon as you start forcing users to use them, users will get upset, and users will leave.

  • In a bug-free world, you may be right. However, I don't think we are yet to the point that we can dismiss privilege escalation as unimportant. Apr 14, 2015 at 1:51

Despite this question already having a billion answers, very recent proposals for browsers make it worth mentioning another possibility. Yes, the current password solution sucks. However, the answer isn't to do passwords better. The answer is to ditch passwords. A new proposal is out from W3C and Fido to push for native browser support of external user authentication - hardware keys, biometrics, etc... Here's just a couple articles:

https://techcrunch.com/2018/04/10/fido-alliance-and-w3c-have-a-plan-to-kill-the-password/amp/ https://fidoalliance.org/fido-alliance-and-w3c-achieve-major-standards-milestone-in-global-effort-towards-simpler-stronger-authentication-on-the-web/

Obviously this is a long way from being in common use. It's also worth a mention that it will be a long time (if ever) before login options like these completely replace passwords. Passwords will be around for a long, long time. However, if I were building a system that needed top notch user security, I wouldn't bother providing an alternate password-generation option. I would simply support current password best-practices, and I would provide support for alternate authentication schemes such as the above as soon as the technology is feasible.


Other people have mentioned it before- but I feel that a user is expected to have control over the security of their account.

That being said, I do agree that many passwords aren't very strong and should certainly should be checked by a client-side (so we're not sending raw passwords through the network) checker for complexity, and if the password doesn't score high enough, we require the user to create a stronger password.

Even if the password has a required change the user is still coming up with the change, and like you've always heard back in school, "if you write it you won't forget it," and I think the same is true in this circumstance with creating passwords.

Off topic, but I highly recommend 1Password for users having trouble remembering passwords.


When selecting the password for the user, you know the entropy, as opposed to placing some restrictions that may prevent them from using a low entropy scheme

In order to have the best of both worlds, you could also compute the entropy (or whatever mechanism you deem appropriate) while they type their chosen password. This is the mechanism used on many sign-up pages:

enter image description here

enter image description here

There are several advantages of this method (the user picks his password, he is aware that this is a "good" or "bad" one, ...).

Just make sure that your philosophy of what constitutes a good and bad password makes sense and that your implementation is password managers-friendly (I simply HATE these sites which break Lastpass in the name of god-knows-what)

  • Password entropy is a function of generation method. Assuming you generated it the obvious way, piepiepiepiepiepie is not a good password, and there is intrinsically no way to determine entropy from the password. Apr 15, 2015 at 16:36
  • @PyRulez: the password entropy is a mathematical function and can be computed on the fly. This is a terrible indication of the strength of the password and your example is very good: the entropy is 84 bits (good!) but if the attacked knows how this particular password is built (the same word repeated several times) then it becomes a bad one. If the enforced rule is that it is made up of 6 words, lower case - it is very good, etc.
    – WoJ
    Apr 16, 2015 at 7:01
  • Its a mathematical function of process, not password. (-sum(p log p)). Assuming I got pie randomly from randalls list, its slightly more than 11 bits (the number of times I repeated it is somewhat random.) All the attacker has to do a simple dictionary attack, except he tries repeating the word multiple times. Apr 17, 2015 at 9:39

Ok passwords suck. I actually have found more evidence of early password failure than well designed password systems when looking at passwords as an access control method prior to computers. There is unfortunately three methods I have seen to "address" the problem.

  1. cost risk analysis: Decide that the risk is small and the cost is large so do nothing (there are a lot of answers that argue from this point of view on this question).

  2. better passwords: At the core your question is looking for a way to do this. Unfortunately this is hard and expensive (opportunity cost at a minimum). For example I made an effort in my spare time over a period of months to setup a password generator integrated into the login password expiry of my computer using pam. I have made no significant progress and the base components have been removed from my chosen distribution for bugs.

  3. something other than passwords: I have made a effort to setup smartcard based login on my computer before recommending it to my boss. I have not found anyone to sell me one to test. Hopefully this has changed in the last year, but last time I checked they were less available than previously in the US.

I find this depressing.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .