Do longer, more complex passwords actually increase the incidence of breaches?

Factual Questions
21

For scary -

I don’t remember who this was, but some low-value site included, in every email to a member, not only the user’s ID, but password as well - in plain text.

I did manage to convince them that, because they didn’t have critical data on file, didn’t mean that the ID/passwords weren’t valid on a target system.

The last email I got from them no longer contained ID and password.

Scary.

Anybody who looks me up will find Im not worth robbing.

Yet I still don’t like the fact that my bank just sent me a new Visa/Debit card “just because”. No, re-issuing every card is NOT something anyone does “just because” - it costs too much, and I woudn’t be surprised if it cost them customers.
If I have that card set up on 37 different sites as the source for auto-pay, I’m probably thinking about a new bank…

I was in a conversation about collapsing acquired banks - how do you do this? Do you send everyone a new checkbook with a new account number? One of the participants related that she had worked for a bank that did “re-paper” accounts - 20% of the customers walked.

22

It depends on local banking regulations, but also on how smart the people managing the change are.

One of my banks acquired my mother’s savings union, which in turn was the product of a large merger between unions. Gave me an enormous scare when I entered my bank’s page and saw two bank accounts instead of one, until I realized that the second one was Mom’s: I am its “sub owner” (not the primary owner, but I can operate with it). All accounts have kept their original IBANs, that is, the ones they had before even the original merger between unions. Old cards worked the same. There is some reorganization ongoing, but if a product is disappearing that means you can’t get it now, not that people who had it are forced to change to another one.

My other bank, which for some reason has some clumsy designers: at one point they closed the office out of which I operated. They changed me to the one which is geographically closest to the closed one: it also happens to be in a town where I’ve set foot once in all my 46 years. They changed my account number. OK, so I asked to have it changed to a third, more convenient office. New change of account. I needed to run separate paperwork to authorize moving my mortgage from that second office to the new one, but at least the mortgage doesn’t appear three times, in bits and pieces… doing my taxes last year involved three separate extracts from what should have been a single account. And of course, new cards - twice.

23

How does guessing work, in the sense of workflow between the miscreant and the secure server? Seems like it would have to include a secure server letting unknown outsiders rapidly try thousands or millions (or billions or trillions) of passwords that are nowhere near correct, without setting off any alarms.

24

The guessing does not happen on the compromised server, which, as you note, would be quickly detected. It happens offline on a leaked list of password hashes.

Important context is that in any halfway competent system, no list of username/password pairs is ever stored, even on the server that is protected by those passwords. Instead a list of password hashes is stored. When a user wants to log in, the password they enter is hashed, and if matches the hash of the stored password the login is accepted, without there having to be plaintext passwords stored anywhere.

If the password hashes are leaked, that’s when all of this offline cracking comes into play.

25

I am really not an expert, just a (hopefully) well-educated layman when it comes to computer security. Everything I know comes from articles like the one I linked, and semi-regular reading of experts like Brian Krebs and Bruce Schneier.

Still, as I understand it:

Any website where you have to sign in needs to store your password somehow. Rather than storing your password as plain text, any responsible website will store password “hashes”. A hashing algorithm transforms your password into a long string of characters in a way that is practically impossible to reverse. Thus, to log in, you type in “P(ett4R0se”, and your computer computes the hash “2fa5411230d2972868267a1f0f46dd1f1f552205” (using the SHA-1 hash function). Your computer sends a username and password hash to the website, which checks it against their list of usernames and password hashes.

A malicious hacker somehow obtains access to a websites server, and downloads all the account information they can, including lists of usernames and password hashes. This has happened on the Straight Dope Message Boards! (If the website was run by idiots, the hacker now has a list of usernames and plain-text passwords).

With a list of usernames and password hashes, the hacker has all the time they want to try to guess each password with their own computers. The ArsTechnica article I mentioned above describes this process. Since hashes can’t easily be reversed, the hacker has to essentially guess by brute force, computing the hash for many many candidate passwords and seeing if any match. Again using the linked example, the hackers tried (1) all 1-6 character passwords, (2) dictionary words including common substitutions (i.e. “3” for “E”), (3) dictionary words plus a handful of random characters, and (4) more sophisticated guessing methods which learn and use common combinations of characters (i.e. “q” followed by a “u”, or a “1” followed by “9”). This approach plausibly could have identified P(ett4R0se.

At the end of this process, the hacker now knows the actual password for a large majority of accounts, along with the username and email. They can use those to log into the hacked website, or try to use them to log into associated accounts.

Or, they can add these new usernames and passwords to the accumulated millions of known usernames and passwords and try them on any website they like. I believe most websites will block lots of rapidly repeated login attempts from a single computer. However, the hacker can use botnets (armies of hacked desktop computers) to automatically do the dirty work, allowing them to potentially try thousands of logins per second.

If the hackers break into an email account, they can easily find and reset the password for many other accounts. If they break into an online store or banking account, they can straight up take your money or buy valuable stuff and have it shipped elsewhere. If they break into a social media account, they can post links to malware or direct fraudulent ad clicks to generate revenue for a website.

Finally, when I talk about “the hacker”, it’s really a network of organized crime. The password crackers sell their lists of passwords to the person running the botnet. The botnet owner gathers lots of working account information for all sorts of sites, and sells it to someone else. Finally, a criminal group buys (say) your Amazon login, or your credit card info, and uses it to buy iPads, which are then sold on Craigslist.

So, after all of that, what should the ordinary shlub do? I honestly am not completely sure. But my advice is:

  1. Never ever re-use passwords between websites.

  2. Set up two-factor authentication for really critical accounts - e.g. if you log into your email or bank account from an unknown computer, you’ll need to provide something like a code texted to your phone.

  3. Use lots of long, unique and truly random passwords.

  4. Since random passwords are hard to memorize, use a password manager.

  5. For the master password on your password manager and any others you wish to remember, use a string of random words as a passphrase. This is far easier for our chattering monkey brains to memorize than 16 random characters.

26

Missed edit:

I realize that list of security recommendations is a lot to do. But if you start down that list, you’ll significantly increase your security at each step.

And finally, writing down passwords for your personal accounts isn’t a terrible idea. Store them in a wallet or a purse, where you’re already storing valuable bits of paper and plastic. They’ll be safe from online attacks, and if they’re stolen you’ll know to reset your passwords (a mugger probably won’t even care about them!)

27

I never use standard hashes when I store something that needs to be secure. I modify the hash, sometimes extensively. So if someone steals the list of hashes, he will also have to steal my hashing code to do anything with them.

28

Honest question: Doesn’t the user need to know the hash function so they can compute and send their hashed password? It seems to me that any website login would need to use a standard hash. I suppose that if the user is running your program to log into your server (e.g. for a mobile app) then you could use any hash you want. To me that seems to be “security by obscurity”, since the hash function still needs to be available to all users (and thus potential hackers).

29

The password is sent using SSL, not hashed. The hashing/storing of the password happens on the server.

30

Got it, thanks.

31

How do we know if a password manager can be trusted? This isn’t a technical question, but one of chain of custody. Publishing a password manager has to be one of the more effective ways of harvesting passwords with account information.

32

Hey, thank you for a fascinating explanation that makes perfect sense. Yes, I can see where all kinds of guessing would accomplish various things.

33

Third-party verification.

I use LastPass. Their security claims are based on them using high-grade encryption, and that the decryption only happens on the client machines. So far, these claims have been verified by others, but I do have to trust those others since I haven’t done the check myself.

In principle, the company could “turn evil” and update their clients to start harvesting passwords. Others would catch on to this pretty quickly, but there could be a period of vulnerability. Not much to do about that besides blocking all updates until they’ve also been verified.

34

This is probably a bad idea. Hashing and encryption algorithms are finely tuned by their creators, and even changing a random constant can have catastrophic consequences to the strength of the result.

If you’re an experienced security researcher, maybe you know how to avoid these pitfalls, but if you’re just a random schmuck you should almost certainly not be doing this.

Using a known hashing algorithm with a large salt (to defeat rainbow tables) is a much better idea.

35

Seems like the increasing use of password managers could itself be a security problem; how does the end user know that the basket into which they have placed all of their eggs is actually safe and secure? Sure, with the open source offerings, it’s possible for individuals to check and verify the integrity of the thing, but has anyone reading this actually done that? I imagine it’s a rarity.

And we are encouraged to put all our eggs in the basket - not only the passwords, but all of the other related security credentials.

36

Right.

I’ll take it a step further: you should not use a hashing function directly. You should use a key key derivation function such as bcrypt or scrypt. They actually solve the problems Terr thinks he’s solving.

37

Also, what happens if you use several computers and you aren’t allowed to install stuff in some of them? (My current client stops certain programs, others directly didn’t give us any kind of admin privileges). Should I keep my password manager in a USB drive? Doesn’t seem particularly safe, somehow. Online only? OK, soooo… I have to log in to a webpage before I can log in to my work computer… is anybody else seeing a contradiction in terms there?

38

I’ll go with that. I almost mentioned “If you really want, you can iterate your hash function N times”, but you’re right–the answer is to just use scrypt, etc.

Not only has the algorithm itself been better analyzed than some homebrew thing, but standard implementations exist which are much less likely to be buggy than the homebrew implementation.

39

I think demanding complex passwords is a complete waste of time. All of the money and effort should be spent on making sure that list can’t leak.

What would be cheaper for a large IT endeavor - paying several people to perpetually reset passwords, etc, or buying dedicated hardware to store the hashes on that can’t be cracked.

By can’t, I mean a system that uses dedicated logic circuits and is mathematically proven to not be leakable. It’s in a sealed box in the server room.

Then, all you need to do is limit the number of guesses allowed, and then any old password can work. Just prohibit the 1000 or so most common passwords and you’re done.

40

That’s certainly possible to do, but would also be a lot more expensive and less scalable solution. The “magic password box”, even if it functioned perfectly would become a network bottleneck, which could not be replicated to ameliorate this bottleneck. An MPB would be a specialized, expensive component, and would be harder to set up in the case where you don’t control the server room (e.g. with an AWS deployment). What’s more, if the MPB is found to be vulnerable in some way, it is a lot more costly to replace than software.

The more common strategy is to make the leaked list of password hashes useless through salting, appropriate hash algorithms, and password complexity requirements. I’m sure there are situations where the security/cost trade-offs favour a MPB solution, but they are not the most common ones.