I came across this question and I have never seen a site that does that, which is a red flag. However, the approach seems sound and it gets around having to implement password rules to enforce strong passwords. Also, if all sites did that it would ensure users don't reuse passwords. So what are the drawbacks of that approach? Is there a good reason all sites don't use that approach?

Specifically, I'm assuming we follow best practices that came up in the comments and answers of that question, such as:

  • generate a long (32+ char), random (with good randomness) password
  • show it to the user once
  • hash it with SHA256
  • resetting the password generates another long, random password

In fact perhaps the approach could even be enhanced if instead of showing the password to the user, the site simply displayed a form with the password field filled in so the browser and/or passwords managers could memorize it. The user would just submit the form and would never have to see it.

  • 2
    I worked on a password auto-generation feature and users complained that the password was too long, too random, and had too many special characters. I ended up writing a "feature" to remove all non-alphanumeric characters (we were using a Microsoft security library to generate the passwords and it didn't have a parameter for "don't use any special characters.") and make them shorter.
    – stannius
    Commented Nov 14, 2017 at 21:11
  • 1
    How over-inflated is your opinion of the importance of your own site, versus how much I would care as a user if someone guesses my password? That's the problem with stats like "50% of passwords to people's Yahoo account were 'qwerty'".
    – Coxy
    Commented Nov 15, 2017 at 0:19
  • 4
    Hash the password with SHA256 is not following best practices. Hash it with bcrypt, scrypt or other password hashing algorithm is following best practices
    – rypskar
    Commented Nov 15, 2017 at 6:48
  • because nobody would friggin remember them. Commented Nov 15, 2017 at 10:36
  • @user1067003 well, surely part of the point is that nobody would remember them; since they're talking about a website rather than to gain initial access to a computer or password manager there's no advantage in remembering them and any password you can remember is too short and/or easy to guess. The problem does remain that people keep trying to remember passwords.
    – Jon Hanna
    Commented Nov 15, 2017 at 10:56

6 Answers 6


Security at the expense of usability comes at the expense of security

The problem is that there is only so much a web application can do to force good security practices on users. In this particular case I can tell you what will happen in the vast majority of cases: people will write down their "secure" password somewhere nice and insecure. As a result, this will not necessarily make anything more secure: it will just shuffle around where the vulnerability lives. In essence, this system is missing some necessary supporting architecture to make the user experience very easy, and therefore very secure. As a result there are basically three kinds of people with three different results:

  1. People who don't care/understand about password security. They are going to write down that uncrackable password in a place that is super-accessible, and as a result super-insecure. These are the same people that reuse the same weak passwords on every site. As a result, they go from one bad security solution to another bad security solution. These are also the majority of web users, so for the majority of the internet your solution has no real benefit.
  2. People who use password managers and other password helpers, their password systems cannot integrate with your website. These people will be worse off, as suddenly their normally-secure system can no longer be used. As a result they'll probably end up writing it down, maybe not securely, and be worse off then they were before. To be clear, this will definitely happen: your "show the password in a form so that the password manager can record it" solution will absolutely not work with some password managers. I can just about guarantee it.
  3. People who use password managers, and those password managers integrate properly with your system. They were already storing things securely and still are, but now with another point of failure: your random number generator. Overall, though, there security will neither have decreased nor increased substantially.

Overall therefore, I would say that I see no real benefit for this system.

I have to say this out loud because it is critical in all other contexts: you never want to use SHA256 to hash passwords. In this case you can probably get away with a fast hash because your password is too long for a brute-force to be feasible anyway.

Edit to add the obvious answer

I think the biggest problem with this solution is that it doesn't go far enough to fix the underlying problem. The underlying problem is that people suck at passwords: we either pick poor ones, reuse them, or don't store them securely. The solution isn't to come up with a new password system: the solution is to ditch passwords all together. Many companies are starting to introduce password-less login. That's the answer you really want.

  • 1
    Good points. The users in case 1 might be better off with this approach, as they wouldn't be vulnerable to hacking from mass breaches if they write their passwords down locally. Also, the consensus in the related question is that a slow hash is not necessary in this case. Commented Nov 14, 2017 at 18:39
  • @Solomonoff'sSecret I updated my answer regarding slow hashes. People use outright dangerous hashes so often in production systems, that I consider it a matter of principle to comment on such things. You're right though: in this particular case it probably doesn't matter. Commented Nov 14, 2017 at 20:09
  • 4
    How is writing down the password poor security? I thought that was the universal consensus of best security practices (short of actually remembering the random password). It is impossible to remember the hundreds of totally random passwords I have for all the sites I have registered with... It is far easier for a dumb user to understand someone reading a piece of paper (like a diary) than it is to understand a distributed bot-net brute-forcing millions of phrases.... you are forcing the user to understand the security implications in the easiest way possible... I just don't see the problem. Commented Nov 14, 2017 at 22:00
  • 2
    You say "The underlying problem is that people suck at passwords" and yet that is exactly what the question proposed to solve... Solve A with B, reject B because A... isn't this circular reasoning...? Commented Nov 14, 2017 at 22:06
  • 1
    I can also guarantee that no one is going to be writing down a 32 character password and typing it in everytime they have to login. If that is the only option, they are going to stop using such a service. If such a system becomes the norm, people will start coming up with new attack vectors to take advantage of it. When people first started storing passwords online I doubt anyone thought to themselves "What happens if someone gets a copy of my database and uses these passwords on other sites?" The attack vectors become obvious after the fact. This seems secure only because it is different Commented Nov 14, 2017 at 23:15

Your solution is forcing people to use a password manager. People may save their passwords in a browser, but thats not always encrypted, and is often only stored locally, so they now can't access your service from more than one computer. Keep in mind that most people won't even know what a password manager is.

Also, even if they have a password manager, do they have access to it on all of their devices? If someone has to type in a random 32-character password even once, they will start to hate your site for that.

  • Which browsers store passwords in an unencrypted form?
    – Blender
    Commented Nov 14, 2017 at 23:49
  • 1
    @Blender all of them if you don't use a master password Commented Nov 15, 2017 at 0:08
  • 1
    Thanks for the research guys... I've been using a password manager for years and have my browser password saving disabled. I didn't realize they were mostly encrypted now.
    – JPhi1618
    Commented Nov 15, 2017 at 3:52
  • 1
    @Bango Contrary, my argument was against the sentence "Firefox seems to be the only browser that stores your passwords in a format readable by anybody with your hard drive." I use Chrome, and I can tell you now, by visiting chrome://settings/passwords all of my saved passwords show up in plain text. They might be encrypted, but they're also readable by anybody with my hard drive as they are, as you pointed out, automatically decrypted by Chrome itself.
    – autistic
    Commented Nov 15, 2017 at 8:49
  • 1
    I run Linux, so Windows SAM is irrelevant to me. Commented Nov 15, 2017 at 21:27

Two things that come into my mind:

  1. Users would hate not being able to choose their own password because unless they already have a password manager or some kind of system, it's an extra thing they have to remember or write down or keep track of somewhere.

  2. If the website takes on the responsibility of generating "random" passwords, the methods it generates a password might turn out to have flaws in it in the future, which will jeopardize the security of all existing passwords at once. I think recently there was some hardware chip that generated BitLocker passwords in computers whose flaw was discovered and now all those BitLocker passwords can be cracked with about $40,000 in AWS - a lot of money for an individual, but for a company or a government, not much.

  • 1
    Regarding 1, one could argue that letting users choose their (presumably easy to remember) passwords is a security flaw. 2 is a good point: every site generating passwords is a lot of surface area for failure compared to a small number of password managers. But user who aren't using password managers are an even larger surface area and sites could use the same carefully written library, but that requires developers to be competent instead of rolling their own. Commented Nov 14, 2017 at 18:29
  • @Solomonoff'sSecret Counter 1, I suppose one could argue that, but they'd be swiftly disproven by the person who suggests that not letting users choose their (presumably difficult to remember/guess) password is even worse, not just for security but also for functionality.
    – autistic
    Commented Nov 15, 2017 at 0:48
  • @Solomonoff'sSecret Regarding your second point, it is from "rolling their own" seemingly secure password requirements or "reinventing the wheel" that the biggest security vulnerability occurs. Website X has obscure password requirements, users commonly forget the password and so end up entering login credentials for website Y, thus handing their password over. Compounded is that there are thousands of websites which do this, and you end up with some users entering their entire list of credentials for just one site. Cue password reset, except that some sites use mobile phones...
    – autistic
    Commented Nov 15, 2017 at 0:54
  • @Solomonoff'sSecret If you're unfamiliar with the world of digital security, common cellphone configurations are the weakest link. An attacker can often call you, tying up your line while they simultaneously call your message bank (using your phone number forged into the session) to access your messages, and you probably don't want your password recovery message going there, right? That's just scattering the mess, rather than fixing it. To fix the "password mess" you need to think very deep and reflective about the "password problems" and work out how to solve them. It's not PEBCAK. It's us.
    – autistic
    Commented Nov 15, 2017 at 1:46
  • Password problem #1: User forget passwords, and end up guessing which is insecure as it likely divulges personal information or passwords for other services. They invented "password recovery" to solve this, but that's just another feature to get wrong. #2: Users chose too easy passwords, so some sites invented arbitrary requirements, making passwords harder to guess, thus harder to remember and thus... #3: In response to obscure password restrictions, users are STILL guessing, which is STILL insecure. Gotta fix THIS problem!
    – autistic
    Commented Nov 15, 2017 at 1:50

what are the drawbacks of that approach?

For a start, it's an extra step which other methods of authentication have significantly reduced. It's extra effort for your users. Passwords are... easy to forget, and that can become a problem which defeats their very purpose. Most significantly, strong password rules which are out of touch with reality are an insecurity.

You can observe this through the people who try their most common password on some forum, only to find they got it wrong because of some obscure, abnormal rule which they've forgotten about, and so they go on to parrot ever username and password combination they've ever used into the login fields. What's the point of passwords if you're just going to share them with random strangers like that?

Whenever I notice sites that do this, I'm suspicious that they might be subtly trying to phish for passwords for other sites. As far as I'm concerned, unless you're a banking agency nowadays, you should probably avoid storing passwords if you want to be seen as legitimate. There are better methods which are more reliable and safer.

To elaborate: Unless your users have something to protect, let them use whatever the hell they want as a password. That is, if you decide to use a password, even blank passwords should be acceptable.

Is there a good reason all sites don't use that approach?

I run what some commonly consider "sites" which I give others access to at times, and I don't store passwords or enforce password requirements at all; I use certificates for authentication (like any modern-day technology should), and people can (if they choose) protect those certificates with a passphrase at their end.

My sites are servers, and there's a very good reason I don't want to be storing passwords of other people. If one of my users manages to gain administrative access to my servers, they might obtain other password hashes.

Similarly, you can observe this site, which you likely didn't have to enter a password for because you were already logged into the StackExchange network... and the StackExchange network allows you to login using Facebook or Google, so there's that, too.

Certificate authentication is nothing new; it's been used in PAM for years now, doesn't require password authentication and is certainly even stronger for banking institutions to use than just a password.

generate a long (32+ char), random (with good randomness) password

You could do this, but when you forget or misorganise your passwords, you'll end up giving passwords for some services to other services. If you're happy with that, so be it. The world won't stop spinning if your bank account gets cracked open.

Sorry, but you won't find anyone to argue that generating a long, random password is more secure than generating a long, random private certificate that's used to sign some nonce salt and never directly stored on the servers side.

show it to the user once

You shouldn't show the user (unless the password is for something unimportant, like your internet forums), but instead your SSH key generator should ask the user to repeat their passphrase at the time the key is generated. This has the same effect as visual verification (perhaps even stronger), except you're not showing your "password" in plain text for anyone watching over your shoulder to see...

hash it with SHA256

One might even go as far to suggest that a salt be used. The problem is, you're still storing a digest and your users may still parrot passwords for other services at you. The solution to the "forgot your password" problem is not to try every password you've ever used, thus significantly weakening your security, but to eliminate passwords (from your server).

resetting the password generates another long, random password

Even the strongest password-based authentication schemes have long-lasting flaws due to some other technology, such as email or cell-phones; when either of those becomes the weakest link, you'll find the password option collapses entirely.

The way forward regarding both privacy and security is to use cryptographic keys to authenticate, rather than emails, phone numbers, passwords and pin codes.

In fact perhaps the approach could even be enhanced if instead of showing the password to the user, the site simply displayed a form with the password field filled in so the browser and/or passwords managers could memorize it. The user would just submit the form and would never have to see it.

The solution is to store the password somewhere in memory, so that people only have to access that memory location to find it? That hardly seems like a solution to me. Use something physical, such as a passphrase-protected GPG key on a USB pen drive.


You're not the only one to suggest this, as I've seen many papers study similar schemes. However usually system-generated passwords are significantly worse in usability compared to user-generated passwords.

In A System Generated Password and Mnemonic Approach, researcher Sanjaykumar Ranganayakulu concluded:

In general, this research found that people tend to remember passwords and mnemonics they generated better than assigned ones. Even though the system-generated mnemonics were meaningful sentences, the participants could not relate as well to them as to passwords or mnemonics created themselves.

An older 1990 US Naval study by Moshe Zviran and William J. Haga compared several password schemes. Recall for the passwords after several months showed that system-generated pronounceable passwords performed best, user-generated passwords and passphrases performed ok, and alphanumeric system-generated passwords were worst in recall, with every user writing down their password rather than memorizing it. Despite the surprising performance of pronounceable passwords, users still preferred picking their own passwords:

no one was able to recall their random-character, system-generated password from memory...

When asked to rank the various methods as to how easy they were to remember, the respondents clearly chose user-generated passwords as the one that they thought was easiest...

When user ability to recall the different types of passwords is examined, [system-generated] pronounceable passwords... proved to be much better than passphrases, random system-generated passwords, or even user-selected passwords

At the end of the day the usability of the system-generated password varies wildly on the scheme. Your system, with 32 random alphanumeric characters, does not seem to be designed to be user-friendly at all. However, some system-generation schemes do have decent security and reasonably high usability, like xkcd's "pick four random words" scheme. Other user-friendly system-generated schemes include pronounceable password generation, and randomly generated alphanumerics with a helpful mnemonic generated by the system. These kinds of schemes, where studied, hold up much better than systems like the one you're suggesting.

There are other technical concerns beyond just the researched usability concerns, but other answers have already covered those concerns.

So schemes like yours have been evaluated several times in research and are not well-received by the users. In general, system-generated passwords are not received well by users, and unless carefully implemented are harder to recall. The alternatives are usually much more appropriate, like password strength meters, notifications of suspicious behavior, two-factor authentication, password length requirements, disallowing common passwords, and protection from brute force attacks and password hash leaks.

  • I wish I could give this my own "tick" due to the citation, as this is the only answer so far that has one... As a supplementary citation, I thought it'd be nice to add that I found a tool which compromises Chrome autofill on Windows, to respond to the "password manager" part of the question. I suppose I could add this to my answer, but in all honesty, I like yours better because it already has a citation. I hope you don't mind that I want to have your answers babies!
    – autistic
    Commented Nov 15, 2017 at 9:50

Not a lawyer, however one significant reason I can think of for companies not wanting to take responsibility for passwords away from the user is that it then opens the company up to liability should a data breach occur because someone got a password and did something. True, what happens once the password is generated is the user's responsibility, but it would be expensive to establish that in court if someone (or worse, a class of someones, in a case such as Yahoo! or Adobe) decided to hold the company solely responsible for it.

On a more practical level, people have options, and only die-hard security fanatics are going to go with something that discards common practice and convenience in the name of a degree of increased security that they're not even sure how to quantify. Even if they decide to go forward with trying the service, by the third or fourth password reset because they forgot it, mistyped a character (that they couldn't see, due to password field restrictions), couldn't paste it in, etc., they are going to be giving serious thought to your competitor that doesn't put them through such hoops just to check on how their fantasy football team is doing today.

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