Why don't applications suggest passwords themselves?

Question

Imagine a web app that, on the login page, has a password field which does not allow user input, but just displays a client-only generated password that is reasonably strong, with a button to re-generate the password.

In this approach, instead of leaving it to the user to supply a strong password (either by typing it in or using a browser-suggested password), the app ensures that only strong passwords that meets it policy are used.

I wonder why this approach is not used. Apart from usability concerns with not allowing users to use their own passwords (mitigated by using a password manager or having the browser remember passwords), I think this approach should massively increase the security of apps.

What am I missing?

Answer 1

Any site that allows non-interactive account creation does this. Typically, it'll send you a one-time password out of band (like via email or SMS), you'll log in, and then you'll immediately need to set up a password.

Better-designed devices do this with their default passwords rather than something you can look up in a manual and therefore must be the same for each unit. The password is written on a sticker, typically alongside the serial number.

Firefox has a password manager that I think is enabled by default and will offer to generate passwords for you whenever it detects you're creating a password. The codes it generates look good to me.

Despite browsers' built-in password managers and syncing options, not enough people use password managers (built-in or otherwise). Those few users with password managers who are following best practices are already randomly generating their passwords, so they're not a part of the consideration here.

For users that need memorable passwords because they don't generate and manage their passwords, you reach an impasse: memorability is inversely proportional to entropy. If a site forces its own password generator on users, it will be overrun with password reset requests.

A better solution would be to ask whether a password is absolutely necessary or if you can use another authentication technique. I think we're headed to this model for most items. Rather than requiring a password and either an authenticator app or security token, why not use just the authenticator app or security token?

Solely using an authenticator or token should provide sufficient security ~90% of the time (the other ~10% includes email and finance). Given current password insecurities, many users are already effectively at this level in most 2FA systems.

Answer 2

Short answer: the application does not have to choose the password, it should simply let the user choose but enforce complexity.

Implementing such a system means you are setting a maximum baseline for complexity. What if I want to use a password even longer and stronger than the application would suggest? I use a password manager, so I can afford that.

AFAIK most people are not using password managers. That means they actually type their passwords, and sometimes they rely on the browser to store them. But often, they have to access sites from another device where the password may not be stored, so for that reason they tend to choose passwords that they can remember, and that are not too long (and tedious) to type in.

This is a reality you will have to take into account.

The only benefit I see with your suggested approach is that the generated password should very probably be unique. But that doesn't stop people from reusing that same password on other websites. There is a chance that they will, precisely because they don't want to remember hundreds of different passwords. If they are asked for a strong password elsewhere, then they might want to use something they already know.

When you say:

I think this approach should massively increase the security of apps.

I think what you mean is: this should increase the security of user accounts (minimize the risk of hijacking).

Besides, the password is the not sole line of defense. Think about two-factor authentication. This is how you can mitigate the password issue.

Answer 3

Other answers named some valid reasons. Here is one more.

Preventing users from entering passwords does not add any security. Malicious users can easily manipulate web application and change passwords to anything they want. Furthermore, users can send requests even without web application, just using tools like curl or Postman, and can send any password they want. The server cannot distinguish if the data were manipulated on the client. That's why the server cannot trust the client and should always validate every single request received from the client.

That's why preventing users from entering passwords makes no sense.

You can duplicate password validation logic on the client to provide immediate feedback and better usability. But you can rely on the server validation only.