Generate user a password instead of asking for one?

Question

I'm trying to weigh the benefits of not allowing users to create their own passwords, but must pick out of a generated selection. Are there any examples of sites that use this approach?

Workflow adjustments for such a site would be along the lines of:

Registration: user is prompted to pick of the generated passwords for their account. Password reset: user is prompted to pick a password from a list of generated passwords after clicking the reset password link in their email or SMS.

Assuming that this system was coupled with instructions on how to use a password manager or other password memorization system, would it be worth implementing on a new site?

Answer 1

Generating passwords for user means that you will get good passwords. However, security is an all-encompassing thing; you also need the users to remember the passwords, and not store them insecurely (the traditional stick-up note under the keyboard), and, generally speaking, you need the user to cooperate. There is little worse that you can do than turning the user into an enemy.

Therefore, a good thing to do is to provide an optional password generator: a button which the user can click, to obtain a strong, randomly generated password, which they can use. But do not enforce it: otherwise, users will become hostile, and hostile users are very creative when it comes to working around security features.

There are a few gotchas to be mindful of, when generating user passwords:

• Don't overdo it. We know that your password generator can produce passwords with 37 random signs. But you really really need the users to accept the passwords.

• Have the user type the password. Passwords are remembered with the fingers. If the user can just select the password with a button, or copy-and-paste it, then he will enter it at registration time without typing it, and 90 seconds later he will have forgotten it entirely. Forgotten passwords are extra helpdesk time. Preventing copy-and-paste means that the password will have to be shown on the screen as a collection of pictures, not selectable text.

• Beware of shoulder surfing. If the user sees the generated password, then the password in displayed on the screen. In many situations (in particular work-related environments), the user cannot practically prevent colleagues with sneaky eyes from taking the occasional peek. This is the reason why password-entry fields are obscured, and the same reason applies here.

Answer 2

I think testing your password strategy with a test environment involving at least 50-100 participant may give some answers. Its always not about security but people behaviors how they respond to changes. Following is a on survey on how people reason about insecure passwords

• its Easier to remember
• We have Too Many Accounts
• Same password for same Category/Class of Websites
• its an Unimportant website
• Too Difficult Otherwise
• using One Password for all websites

Answer 3

I think it's important to consider who will be using the site. Children and senior citizens probably couldn't make use of this type of security measure. While a site focused on IT Professionals could be a perfect place to change the (in)security paradigm related to passwords.

Answer 4

Unless a user has a strong desire to interact with your system, I expect that they would go to a competitor or continue to do without in the case of a novel service. You may be able to get traction if the account is extremely valuable (examples: bank or a business hosting service).

Transitioning to a password manager for just your system would probably not be enough; a user is likely to forget how to retrieve their password (or any process) if they don't use it frequently. What you would need is for users to transition to using a password manager for everything.

Users would also need access to this password manager everywhere, since now all of their passwords are random strings that they have no hope of remembering. At computers they don't own (work/client or friends/family), they need to retrieve a password with nothing installed, so you need a phone application (and to assume the user has a smart phone).

It would be great if everyone used random and unique passwords for every system that they log in to. I also expect that it is impractical in most cases.

Answer 5

I think it might be worth it for some business critical apps, banking apps, maybe even hosting control panels. But I think some consumers and others will get annoyed by it and might not want to signup. Maybe you should do a UI where you have auto generated good passwords and notes about them on the left, the non the right or have a small link to enter a password manually. Maybe do some checking if it's a strong password, like some requirements and some short easy to understand educational information nearby. Like maybe a hybrid approach would work better. I haven't seen anything like this done before, so seems like a new and unique idea.

Answer 6

I have several doubts:

• Is the password generation scheme you use truly random and unbreakable?
• Can generated passwords be recovered from auxiliary information like time of sign-up etc.? What you are actually doing is reducing entropy for the attacker who would have to try three choices instead of a full-blown dictionary attack.
• You will alienate a certain proportion of the users who don't like being spoon-fed security-critical solutions.
• You may incur legal risks (am not a lawyer) if the access is broken and clients accuse you of being the negligent party.

Considering the four items above, would generally recommend against offering users generated passwords.

Answer 7

This is a surefire way to get flooded with password reset request. NEVER DO THIS.

I have seen a grand total of zero average users use a password manager. Those who uses a password manager already knows to randomly generate passwords.

Answer 8

I believe the practice of top-down password assignment is (or was) common in military deployments.

Typically, you would estimate the average time to for a password being lost, though any number of means, some of which might include:

• Social Engineering
• Brute Force
• Careless Users Leaking Them

You would then take this estimate and force passwords to be re-generated in a "safe" time window. Your end users may hate you for this. It does however have many benefits:

• You can more easily link a password to an end user -- you generated them for everyone, so why was Bob using Alice's password when Bob has been given a password.
• The organisation can explicitly balance the risk of their passwords against their end user's convenience, specifically by varying the password's length and lifetime accordingly.
• Different systems can require different passwords for the same user, leading to easier-to-implement access controls, and better separation of concerns. However, you could just delegate authentication & authorisation to a specific identity provider for the same benefits.

However, you also need to be able to deliver the passwords to the users in a secure fashion. This is surprisingly difficult; you certainly can't email them over the open internet, a courier might be bribed (and can perform a DoS by being slow or "losing" the keys to the local river), and so on.

This scheme will also probably lead, as noted by The Bear to extremely hostile users. Hostile users are a serious security risk. They may stop using the system to do their job, by taking the data out of the (secure) application to work with it, which defeats the point of the system entirely.

All in all, for most applications, you're not guarding sensitive enough data to warrant this level of paranoia. You can't guarantee secure delivery of the passwords, you can't train your users, and you probably can't compel them to use your system. This is almost certainly a horrible scheme for 99.9999% of applications.