16

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.

Reinstate Monica
  • 364
  • 2
  • 9
  • 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 Nov 14 '17 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 Nov 15 '17 at 00: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 Nov 15 '17 at 06:48
  • because nobody would friggin remember them. – user1067003 Nov 15 '17 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 Nov 15 '17 at 10:56

6 Answers6

23

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.

Conor Mancone
  • 29,899
  • 13
  • 91
  • 96
  • 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. – Reinstate Monica Nov 14 '17 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. – Conor Mancone Nov 14 '17 at 20:09
  • User Case #1 may be better off with this approach (which is obviously the problem you are trying to solve), but it is really hard to say, so I stuck with the devil's advocate position. The main impact here is moving the vulnerability from one that is well understood and known (people reusing passwords across sites) to one that is less-well understood (people storing passwords in easy-to-access ways). In the end, it's hard to tell which is better. – Conor Mancone Nov 14 '17 at 20:11
  • @Solomonoff'sSecret One more edit for you – Conor Mancone Nov 14 '17 at 20:13
  • I appreciate devil's advocate when it comes to security, thanks. – Reinstate Monica Nov 14 '17 at 20:21
  • 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. – user3338098 Nov 14 '17 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...? – user3338098 Nov 14 '17 at 22:06
  • `you never want to use SHA256 to hash passwords, [...] because your password is too long for a brute-force to be feasible anyway` how is to much security a bad thing? how low should we go? 80 bits? 64 bits? For only a little extra computing power I protect my users from undiscovered weaknesses in the SHA algorithms (assuming it is only a partial reduction in security). – user3338098 Nov 14 '17 at 22:33
  • I am no security expert but intuitively it seems that insecure bits of paper, or even passwords sent to oneself in plaintext in an otherwise secure email system, is far better than reusing and/or poor password choice. – stannius Nov 14 '17 at 22:33
  • Choosing a very secure password and writing it down decreases your attack surface from "the entire internet" to "people in your physical vicinity". If you only access a given site from home or keep the paper in your wallet at all times, that's pretty secure. There's a vulnerability, but no real threat. Certainly more secure than a weak password. If it's a post-it stuck to your laptop, or stuck to your monitor in the lobby of your office, that's a big vulnerability and a pretty credible threat. – TBridges42 Nov 14 '17 at 22:40
  • You guys are welcome to post an answer to the contrary. In the meantime, I would just reiterate what I said before. No one really knows if this is more secure because it just moves the vulnerability somewhere that we are less familiar with. A post-it in a diary seems secure, especially compared to the risk we already know (brute-force searches on leaked databases). However, who says that is what will happen? – Conor Mancone Nov 14 '17 at 23:09
  • I remember a story (haven't found it yet) about a bank that put their secure access codes on a post-it note in a back room. A computer repair guy saw it, recognized it, memorized it, and stole lots of money using it. Just google "credentials accidentally published in github" to read about all the fun things that happen when people don't think about how to securely store long strings of text. Granted, that is a slightly different use-case, but I think it is still very applicable. If you are worried about passwords, the best bet is to simply follow best practices, or ditch passwords. – Conor Mancone Nov 14 '17 at 23:11
  • 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 – Conor Mancone Nov 14 '17 at 23:15
  • @user3338098 regarding hashing, see here: https://security.stackexchange.com/questions/169320/any-reason-to-slow-hash-passwords-generated-randomly-by-our-site – Conor Mancone Nov 14 '17 at 23:16
  • @Conor About your story ... if they had stored the access codes somewhere on the internet ("secure" password manager or cloud or whatever), their money could have been stolen by thousands of "computer repair guys" around the world. –  Nov 15 '17 at 11:09
  • @ConorMancone the top answer for [https://security.stackexchange.com/questions/169320/...](https://security.stackexchange.com/questions/169320/any-reason-to-slow-hash-passwords-generated-randomly-by-our-site) actually recommends using SHA256 instead of MD5. However, I do understand that MD5 is still reasonably secure in this scenario, however that is not a good enough reason to *_never_* use SHA256 in this scenario. – user3338098 Aug 30 '18 at 22:02
9

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.

JPhi1618
  • 490
  • 1
  • 5
  • 8
  • Which browsers store passwords in an unencrypted form? – Blender Nov 14 '17 at 23:49
  • 1
    @Blender all of them if you don't use a master password – user253751 Nov 15 '17 at 00:08
  • @immibis: I'm pretty sure Chrome, Safari, and Internet Explorer tie into some form of encrypted storage secured by your account password. Firefox seems to be the only browser that stores your passwords in a format readable by anybody with your hard drive. – Blender Nov 15 '17 at 00:33
  • Based on the helpful comments of @Sebivor, we realize Chrome, IE, and FF tie in some form of encrypted storage, which is secured by an account password. It's [not true](https://support.mozilla.org/en-US/questions/1084997) that Firefox stores passwords in plaintext. Exactly how secure these security measures are is, as we have seen, questionable. It makes sense, without a higher level password to encrypt by, any default encryption key in browsers would be just 1 more self-defeating step in the process of decrypting data. While they may not be stored in plaintext per se, they may as well be. – Bango Nov 15 '17 at 02:17
  • 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 Nov 15 '17 at 03:52
  • @Blender *"Firefox seems to be the only browser that stores your passwords in a format readable by anybody with your hard drive."* ... Do you still believe this? – autistic Nov 15 '17 at 08:45
  • 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 Nov 15 '17 at 08:49
  • @Sebivor isn't that only when logged into your user account though? – Baldrickk Nov 15 '17 at 09:12
  • @Baldrickk [ChromePass](https://www.nirsoft.net/utils/chromepass.html) is apparently able to "get the passwords" ... "from a user profile stored on external drive". Alternatively, by extracting the Windows SAM file which isn't usually visible unless you have the hard drive mounted as an external drive, you can fire up an NT password cracker and have a password from your NTLM database in a short enough time. – autistic Nov 15 '17 at 09:28
  • @Sebivor: Yes. ChromePass still needs you to know the account password to function. You either have to run it while logged into the account (which requires you to know the password or physically be in control of the computer), or to manually supply the password when you try and extract Chrome passwords from another disk. The OS allows Chrome to read from secure storage that's decrypted with your password when you log in, but that doesn't mean that everybody can read it, especially when you're not logged in. NTLM does suck, but password guessing is a last resort and isn't guaranteed to work. – Blender Nov 15 '17 at 10:26
  • 1
    I run Linux, so Windows SAM is irrelevant to me. – user253751 Nov 15 '17 at 21:27
3

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.

downwardCorgi
  • 169
  • 4
  • 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. – Reinstate Monica Nov 14 '17 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 Nov 15 '17 at 00: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 Nov 15 '17 at 00: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 Nov 15 '17 at 01: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 Nov 15 '17 at 01:50
3

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.

autistic
  • 734
  • 6
  • 17
3

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.

Community
  • 1
Cody P
  • 1,148
  • 6
  • 14
  • 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](https://www.nirsoft.net/utils/chromepass.html), 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 Nov 15 '17 at 09:50
2

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.

Kaji
  • 121
  • 4