Why passwords have never been weaker—and crackers have never been stronger

Thanks to real-world data, the keys to your digital kingdom are under assault.

In late 2010, Sean Brooks received three e-mails over a span of 30 hours warning that his accounts on LinkedIn, Battle.net, and other popular websites were at risk. He was tempted to dismiss them as hoaxes—until he noticed they included specifics that weren't typical of mass-produced phishing scams. The e-mails said that his login credentials for various Gawker websites had been exposed by hackers who rooted the sites' servers, then bragged about it online; if Brooks used the same e-mail and password for other accounts, they would be compromised too.

The warnings Brooks and millions of other people received that December weren't fabrications. Within hours of anonymous hackers penetrating Gawker servers and exposing cryptographically protected passwords for 1.3 million of its users, botnets were cracking the passwords and using them to commandeer Twitter accounts and send spam. Over the next few days, the sites advising or requiring their users to change passwords expanded to include Twitter, Amazon, and Yahoo.

"The danger of weak password habits is becoming increasingly well-recognized," said Brooks, who at the time blogged about the warnings as the Program Associate for the Center for Democracy and Technology. The warnings, he told me, "show [that] these companies understand how a security breach outside their systems can create a vulnerability within their networks."

The ancient art of password cracking has advanced further in the past five years than it did in the previous several decades combined. At the same time, the dangerous practice of password reuse has surged. The result: security provided by the average password in 2012 has never been weaker.

A new world

The average Web user maintains 25 separate accounts but uses just 6.5 passwords to protect them, according to a landmark study (PDF) from 2007. As the Gawker breach demonstrated, such password reuse, combined with the frequent use of e-mail addresses as user names, means that once hackers have plucked login credentials from one site, they often have the means to compromise dozens of other accounts, too.

Newer hardware and modern techniques have also helped to contribute to the rise in password cracking. Now used increasingly for computing, graphics processors allow password-cracking programs to work thousands of times faster than they did just a decade ago on similarly priced PCs that used traditional CPUs alone. A PC running a single AMD Radeon HD7970 GPU, for instance, can try on average an astounding 8.2 billion password combinations each second, depending on the algorithm used to scramble them. Only a decade ago, such speeds were possible only when using pricey supercomputers.

The advances don't stop there. PCs equipped with two or more $500 GPUs can achieve speeds two, three, or more times faster, and free password cracking programs such as oclHashcat-plus will run on many of them with little or no tinkering. Hackers running such gear also work in tandem in online forums, which allow them to pool resources and know-how to crack lists of 100,000 or more passwords in just hours.

Most importantly, a series of leaks over the past few years containing more than 100 million real-world passwords have provided crackers with important new insights about how people in different walks of life choose passwords on different sites or in different settings. The ever-growing list of leaked passwords allows programmers to write rules that make cracking algorithms faster and more accurate; password attacks have become cut-and-paste exercises that even script kiddies can perform with ease.

"It has been night and day, the amount of improvement," said Rick Redman, a penetration tester for security consultants KoreLogic and organizer of the Crack Me If You Can password contest at the past three Defcon hacker conferences. "It's been an exciting year for password crackers because of the amount of data. Cracking 16-character passwords is something I could not do four or five years ago, and it's not because I have more computers now."

Enlarge/ This $12,000 computer, dubbed Project Erebus v2.5 by creator d3ad0ne, contains eight AMD Radeon HD7970 GPU cards. Running version 0.10 of oclHashcat-lite, it requires just 12 hours to brute force the entire keyspace for any eight-character password containing upper- or lower-case letters, digits or symbols. It aided Team Hashcat in winning this year's Crack Me If You Can contest.

At any given time, Redman is likely to be running thousands of cryptographically hashed passwords though a PC containing four of Nvidia's GeForce GTX 480 graphics cards. It's an "older machine," he conceded, but it still gives him the ability to cycle through as many as 6.2 billion combinations every second. He typically uses a dictionary file containing about 26 million words, combined with programming rules that greatly extend its effectiveness by adding numbers, punctuation, and other characters to each list entry. Depending on the job, he sometimes uses a 60 million-strong word list and something known as "rainbow tables," which are described later in this article.

As a penetration tester who gets paid to pierce the defenses of Fortune 500 companies, Redman tries to spot weaknesses before criminal hackers exploit them on his customers' networks. One of the key ways he stays ahead is by downloading hash lists that are dumped almost every day on pastebin.com and other sites to see if any belong to the organizations he is contracted to protect.

Recently, he recovered a 13-character password that he had spent several months trying to crack. To protect the account holder, he declined to reveal the precise combination of characters and instead made up the imaginary passphrase "Sup3rThinkers" (minus the quotation marks) to illustrate his breakthrough. "Sup3rThinkers" follows a number of patterns that have become common: it opens with a common, five-letter word that begins with a capitalized letter and substitutes a 3 for an E, followed by a common, seven-letter word that also begins with a capital letter. While the speed of his system didn't hurt, cracking the password was largely the result of the collective codebreaking expertise developed online over the past few years.

The most important single contribution to cracking knowledge came in late 2009, when an SQL injection attack against online games service RockYou.com exposed 32 million plaintext passwords used by its members to log in to their accounts. The passcodes, which came to 14.3 million once duplicates were removed, were posted online; almost overnight, the unprecedented corpus of real-world credentials changed the way whitehat and blackhat hackers alike cracked passwords.

335 Reader Comments

Okay, so it can try 8.2 billion per second. All a website had to do to foil that is to deny an more tries after 10 or so, no?

What I want is sites to stop telling us how to do our passwords. I want spaces and phrases, not random letters and numbers. But most don't allow spaces, and often they demand they be fewer than 16 characters.

How about a sentence with spaces and punctuation? Then let people write something only they would know with a mnemonic word to remind them what it is?

I've been an advocate for a while now of creating a passwords from several words that otherwise have no association with each other. This results in a long password that's infinitely easier to type than alphabet soup (especially on mobile devices) and more importantly, easy to remember.

I was overjoyed to see that XKCD covered this a while back with his usual panache. It described it much more succinctly than I ever could.

Unfortunately, I've gotten to the point where I have far too many passwords to remember, and have taken to using a password manager for those that aren't so critical. Those tend to be complete gibberish that I don't have to remember and are as long as their respective services will allow.

Okay, so it can try 8.2 billion per second. All a website had to do to foil that is to deny an more tries after 10 or so, no?

This is after the password database has itself been compromised. Back in the old Unix days all you had to do is anonymous ftp into a site and grab the /etc/passwd file. Now it's SQL injection that's the real problem. I guess the idea is to get the passwords from a low risk site, and hope it's the same password on something that may contain CC info like Amazon.com

I'm glad to see Ars give a more in-depth overview of this, given the number of stories this year. Your headline and subtitle are silly hyperbole (a 20 character random password is just as strong now as it ever was), but overall the article itself covered the bases. I do take issue with a few parts though:

Quote:

No, SHA1 is not a secure hashing algorithm

There is a difference between an algorithm being cryptographically secure and being brute force resistant. They exist for different purposes (and adaptive hash algorithms build upon the foundation of a cryptographically secure hash). MD5 would be an example of a hash algorithm that is no longer considered secure after attacks were devised that dramatically reduced the complexity of a collision attack. SHA-1 isn't recommended anymore either but that's separate from what you outline.

Quote:

But the benefit in improved security largely outweighs the investment, many security experts argue. Had LinkedIn engineers used Bcrypt, for example, Gosney would have been able to make fewer than 1,750 guesses per second.

Adaptive hashes usually support arbitrary slowdown (number of rounds can be selected as an input). The user can make them as slow or as fast as they wish based on the application needs, so it's not quite right to attach a single number. They can be made slower to keep a constant time in the face of increasing computational power, or faster if the tradeoff makes sense for a given system.

Quote:

It's also important that a password not already be a part of the corpus of the hundreds of millions of codes already compiled in crackers' word lists, that it be randomly generated by a computer, and that it have a minimum of nine characters to make brute-force cracks infeasible. Since it's not uncommon for people to have dozens of accounts these days, the easiest way to put this advice into practice is to use program such as 1Password or PasswordSafe.

FWIW, I think a number of OSes do have built-in methods. The UIs aren't going to be as good but they can still generate strong passwords. The Keychain application on OS X for example can generate strong passwords based on a number of criteria, and ships with every machine. While lacking the integration, built-in options are free and universally available.

Ultimately I think a better solution would be use more multifactor systems combined with storage and interface standards to enable widespread automation. That would simultaneously give people more security while being more convenient (and in this case the two go hand in hand). I hope Ars does a survey of options relating to that in the future.

Okay, so it can try 8.2 billion per second. All a website had to do to foil that is to deny an more tries after 10 or so, no?

Nope. They aren't sending 8.2 billion passwords a second to the website to try logging in. They've got a copy of the database that contains all the passwords converted into a hash (gibberish) using an algorithm. They repeat that conversion process on their own computer and compare the result of their conversion to the copy that was stored in the database. When they've got a match they've recovered your password.

The article didn't mention it but I assume the easiest way to determine what algorithm they used is by testing against a known password. As long as they can sign up for an account then it only takes seconds to determine what hash was used. Run your known password for your account through all the common hashes and find the one that matches.

If you're interested in playing with rainbow tables without having to download them, https://webtables.cryptohaze.com/ has a number web-accessible - you can access them without needing to pull down 1.5TB of data first (you do the computation locally, and the table searching remotely).

Quote:

The article didn't mention it but I assume the easiest way to determine what algorithm they used is by testing against a known password. As long as they can sign up for an account then it only takes seconds to determine what hash was used.

In many cases, the password "in position" tells you a lot about it. If it's 40 characters long, it's probably SHA1. If it's got a $P$ prefix, or a $H$ prefix, or other common prefixes, you know the algorithm and the details. In most cases, a 32 character hex string is MD5 (at least out on the web). And, yes, as noted, if you can register an account, you can petty quickly figure out what they're using.

Quote:

Ultimately I think a better solution would be use more multifactor systems combined with storage and interface standards to enable widespread automation.

Multifactor is good, as long as you don't have your storage systems for that hacked (see RSA).

I'm a big fan of the Google Multifactor auth system - it seems to be quite solidly done, and has a bit of a tech giant behind it (though that alone isn't proof that it's done right, Google seems to be pretty good with their security stuff lately, especially when integrated with Chrome).

intense stuff, great read. I'm glad i've switched to a 20+ character/symbol password, but it's a shame some sites don't let you use such long passwords...

The problem is that I'm betting you don't use a unique one for each site. No matter how secure your password is against brute force hacking all it takes is one site that you use that password on storing that stores that password in plain text to get hacked for your password to end up in a dictionary. Once it's in the dictionary it's not really any more secure than 1234.

Realistically, the only way to actually be secure is to use a password safe program and make sure your password to that program is secure.

I've been using KeePass for several years now. I know very, very few passwords; the rest are randomly, uniquely generated and as long as the client will allow.

I would like to see a unified second-factor worked out. Multiple second-factors are a considerable physical inconvenience (where available at all), and frankly using my phone as a second factor is nearly as inconvenient; I like to ROM my phone, and every time I did with Blizzard I had to deauth my app, ROM it, reath, etc. It would be really nice to be able to have a single hardware token from a third party that all of the login sites (can) use.

What I want is sites to stop telling us how to do our passwords. I want spaces and phrases, not random letters and numbers. But most don't allow spaces, and often they demand they be fewer than 16 characters.

As a bare minimum this would be a reasonable place to start. There is no reason in 2012 (or years ago for that matter) to not accept effectively arbitrary UTF-8.

evan_s wrote:

The article didn't mention it but I assume the easiest way to determine what algorithm they used is by testing against a known password. As long as they can sign up for an account then it only takes seconds to determine what hash was used. Run your known password for your account through all the common hashes and find the one that matches.

Beyond that and what Bitweasil said, if attackers gain access to a password database it's often true that they'll also have been able to see the business logic. Algorithms aren't meant to be secret anyway so there's no point in wasting resources or adding complexity trying to hide it.

Honestly, if you aren't using a password manager at this point, you either have very few logins (unlikely) or you are reusing passwords somewhere. I'd personally get LastPass over 1Password as it's web-based and lets you log into your account from anywhere. And since you are giving them money every month, they have extra incentive to not let their security lapse.

Ultimately I think a better solution would be use more multifactor systems combined with storage and interface standards to enable widespread automation.

Multifactor is good, as long as you don't have your storage systems for that hacked (see RSA).

I'm a big fan of the Google Multifactor auth system - it seems to be quite solidly done, and has a bit of a tech giant behind it (though that alone isn't proof that it's done right, Google seems to be pretty good with their security stuff lately, especially when integrated with Chrome).

Multifactor authentication is definitely a good way to go but I sure don't want to have a bunch of hardware tokens that I have to carry around to sign into different sites. I signed up for the Google system recently and it seemed decent. A text message to a phone is a pretty reasonable option that many people can use that doesn't require carrying anything extra. I wonder how much the cost is for google for the infrastructure to handle this and the cost of actually sending the text msgs. Sadly the only hardware token I have is from blizzard for their b-net system and I'm sure I'm not that unusual.

I'm hoping that one day, we'll have an authentication system that won't require the equivalent of a one-time pad for every blog, forum, and online retailer I'm registered with, because a unique, randomly-generated password for every single site and service sounds awfully like generating (very short) one time pads to me.

Part of the problem is the balance between user-friendly (AKA minimising support costs) and security usually leans too strongly towards making things easy to use. There are far too many sites that let you enter pathetically weak passwords; there are too many organisations that implement useless password policies.

I'm afraid this is one case where porn is way ahead. Length is, indeed, everything.

I would like to see a unified second-factor worked out. Multiple second-factors are a considerable physical inconvenience (where available at all), and frankly using my phone as a second factor is nearly as inconvenient; I like to ROM my phone, and every time I did with Blizzard I had to deauth my app, ROM it, reath, etc. It would be really nice to be able to have a single hardware token from a third party that all of the login sites (can) use.

I'm wary of password managers; What happens if my harddrive crashes, or that webservice goes down? All of a sudden I'm locked out of everything.

My compromise has been using a few, not very strong passwords for the dozens of webfora and such I am on, that don't have money involved. Then unique, long, hard to remember passwords for anything that remembers my credit card, involves money or my identify.

Okay, so it can try 8.2 billion per second. All a website had to do to foil that is to deny an more tries after 10 or so, no?

As others have mentioned, you're misunderstanding the relationship here. The brute force approach isn't used to try to directly access the service or website in question; it's used to crack a hashed password after that information has been made available via other means (eg. database hacks).

In very general terms;

1. Database of popular service is hacked, login and password info for a gazillion users is available1a. If the passwords are stored in plaintext, gg. Proceed directly to step 3.

2. Brute force / dictionary / etc. attack hashes 8.2 billion words per second and finds any recorded hashes which match the word2a. For unsalted password hashes, you now have the passwords for a majority of users of the service. In other words, only marginally more secure than plaintext.2b. For salted password hashes, you'd need to repeat the process separately for each user

3. You now have the login and password for a large number of users. You can either use this in a number of ways;3a. Access the account directly3b. Try the same login credentials for other more valuable services3c. Add all the passwords to your dictionary and make step 2 much more efficient.

It's 3c that this article is mostly concerned with. The large number of website hacks over the last few years have vastly improved the dictionaries used by crackers.

Okay, so it can try 8.2 billion per second. All a website had to do to foil that is to deny an more tries after 10 or so, no?

What I want is sites to stop telling us how to do our passwords. I want spaces and phrases, not random letters and numbers. But most don't allow spaces, and often they demand they be fewer than 16 characters.

How about a sentence with spaces and punctuation? Then let people write something only they would know with a mnemonic word to remind them what it is?

I have this problem with so many sites - particularly certain online banking sites/apps which should allow us to create the absolute longest passwords with as much entropy as possible (ie allow ALL letters/numbers/symbols) but instead they're holding us to 8 - 16 character passwords with no symbols allowed.

The problem now is not solely in the hands of the people creating their passwords too weakly. With the social aspect of our culture encouraging everyone to "share" everything openly online, it only takes someone with enough time and patience and determination to compromise some accounts. Aside from the Ars community, think of all the elderly people and uninformed/lazy/stupid people who are bound to use a weak password, reuse that password across many sites, use the same name for all of their usenames and email addresses, and perhaps post their "pet name" or other revealing information to say Facebook or some other public profile and then also use that same "pet name" as the response for password recovery...even if it is as low as 1 in 1000 that are this insecure, or higher, the end result is a significant number of accounts that can be fairly easily compromised.

Adding to the pain are the weak server security implementations plaguing sites and companies that have absolutely no excuse for it. All it takes is some small server holding usernames and passwords and email addresses (and possibly other sensitive data) to be hacked and those databases copied for the whole process to get started. I say small because they could fail to implement best practices with security due to lack of experience and perhaps resources. For companies like Sony, LinkedIn, and Blizzard there really is no excuse. Having viewed some of the password lists compiled from many of the hacks in the last year or two it is blatantly obvious that some people out there just don't get it at all, but even with a moderate to good password strength, the hackers cracking those database dumps have all the time they need with the actual file locally accessible and once they unlock them it is only a matter of trial and error. Personally I would start with the simplest passwords and look at the email address and other information associated with those and pretty much assume that if they used "password", "love", or "12345" then chances are they would reuse that password and email combination for many other services. Social Engineering using stolen accounts is a great way to then spread malware to or compromise other accounts of relatives/friends/co-workers of that person's account.

Finally, the fact that Ars ran an article today stating the breakthroughs with quantum computing just shows that the state of cryptography and password entropy is in for some serious shifts. The article spoke of using quantum computing technology to solve protein-folding problems much faster than traditional computers and analysis. Its only a matter of time until this same technology will be used by governments and/or criminal organizations to start cracking passwords and current cryptography implementations.

I'm wary of password managers; What happens if my harddrive crashes, or that webservice goes down? All of a sudden I'm locked out of everything.

My compromise has been using a few, not very strong passwords for the dozens of webfora and such I am on, that don't have money involved. Then unique, long, hard to remember passwords for anything that remembers my credit card, involves money or my identify.

Is this a bad idea, or an ok compromise?

If you look into some of the good ones like LastPass, they are pretty bullet proof. Your entire encrypted archive of passwords is stored on your computer, and in the cloud. You can also download it to anywhere for safekeeping (though it won't always be up to date).

So if the cloud goes down, you have a local copy, and if you lose your local copy, you have the cloud.

Also most websites have some sort of password reset mechanism, so even in the absolute worst case scenario, you could reset them.

Password managers are really the only solution here. You need one great password and it takes care of the rest.

I apologize if I missed it in the article, but is there a best practice for a site to store passwords given all this new information?

I'm about to launch a new site which will allow both user registrations and Facebook/Twitter sign-ups. Obviously I don't have to do anything with the third-party authentication, but for users who choose a new registration, if I'm running PHP and planning on storing an email address and password in a database what would be the best practice?

That allowed him to recover the password in question by appending each word in his list to every other word in the list. The technique is simple enough to do, although it increases the number of required guesses dramatically—from about 26 million, assuming the dictionary Redman uses most often, to about 676 million.

It seems to me that there are other significant issues that are often overlooked in password security. For example, at Ars Technica, your login name is visible to all users. Thus, if the password for a user becomes known, the login name needed to access that user's account is also already known. This also makes it easier to identify targets: because Ars users are identified by public login name AND whether or not they are active subscribers, hackers looking for financial details can limit their attack to the set of usernames as published on the site with the subscriber tag.

Protecting one's login name ought to be just as important as protecting a password, allowing for different login and password combinations for each site. That way, if a login/password combination for one site is compromised, the particular combination fails to work on any other site; furthermore, the attempt to brute-force all possible passwords (or possibly starting with similar configurations as explained in this article) for that login name will fail, because the login name for the secondary target is unknown.

Another unsafe practice seems to be that more and more sites use an email address as the login name, not only making it more difficult for users to obfuscate their login as many have a limited number of email addresses but also giving a potential attacker another vector of attack: the user's email account.

Should any of these issues receive the same detailed examination as the password itself?

Should any of these issues receive the same detailed examination as the password itself?

No. Trying to keep the username secret essentially amounts to increasing the entropy of the password that is used. You'd run into the same common problem, i.e., users that still re-use them across sites.

I did a password cracking exercise back in 2001 against 5,500 passwords, on a Windows server's NTLM store, and cracked 99.9% in a 'few days'. With this new tech, it would have been the work of a few minutes.

Now if only I could use 'random gibberish' to logon with initially [artificial restrictions, not able to use USB-key or other two-factor (something you own + something you know) solutions.]

For me, it's the accuracy of typing (which is hopeless) which prevents me from regularly using 'long passwords' on key systems (i.e my initial home computer logon and my initial work computer logon).

Keepass is an excellent freeware password manager, I'm using it more and more. After reading this article, I'm going to switch all my various game accounts to using some manic Keepass generated password I can keep the Keepass database in the cloud if I need to have access to it 'somewhere else'.

I tend to generate passwords by taking the first letter from each word in a somewhat nonsense sentence (i.e., rather than famous quotes) - it seems like that would also be a good way to get into the uncracked percentage in these major breaches.

I'm sure there are also other rules/techniques/strategies for generating a password that you have to remember that would reduce crackability, and I think it would be helpful to share those since it's more likely to get Joe Blow from accounting to remember correcthorsebatterystaple than it is to get him to a use a password program.

I apologize if I missed it in the article, but is there a best practice for a site to store passwords given all this new information?

I'm about to launch a new site which will allow both user registrations and Facebook/Twitter sign-ups. Obviously I don't have to do anything with the third-party authentication, but for users who choose a new registration, if I'm running PHP and planning on storing an email address and password in a database what would be the best practice?

Here is my suggestions as a synopsis of a recent Security Now! podcast:

Have a password strength meter right on the page in Javascript. It would be kind of cool if it included the top 100 bad passwords too, or you could just reject them.Have any password requirements listed on the page where people have to create their accounts. Don't force people to use complex passwords though. If you have the strength meter then it is their decision to secure their account.

Hash using a good function like SHA256 or SHA512.

Use something like bcrypt, or something with a Key Derivation Function You want multiple passes, but you don't want it to take TOO long. Still it can likely be done all client side so there shouldn't be much work on your server end.

Use Salt. Unique salt per account. Store that with the password.

An additional layer of system wide salt not stored with the password would add some extra strenght if (when) the database is stolen because it would not be stored with the passwords, but it would be known to you.

Do lots of research! These are just some tips, but there are many smart people out there who know way more about this than me.

Password managers are really the only solution here. You need one great password and it takes care of the rest.

No, password managers are not the solution: if someone gets the master file and able to crack it, then they will be able to access all of your passwords.

You should NOT store passwords on your local file, but store very strong random numbers and combine that with your weak password and submit those to the website. This way an attacker cannot run brute force tests without working through the site where the password would be useful.

Unfortunately the password managers are providing convenience (you do not have to type in passwords for various websites), instead they should improve security (you still have to type in your password, but that can be week and will be combined with something strong).

Well, you need to make sure to warn after 3 to 5 failures, make users wait a period of time, and when a successful login occurs alert the user, demanding that they change their password or else reset it for them and maybe demand identification for the return of the account (since email can be hijacked).

I tend to generate passwords by taking the first letter from each word in a somewhat nonsense sentence (i.e., rather than famous quotes) - it seems like that would also be a good way to get into the uncracked percentage in these major breaches.

I'm sure there are also other rules/techniques/strategies for generating a password that you have to remember that would reduce crackability, and I think it would be helpful to share those since it's more likely to get Joe Blow from accounting to remember correcthorsebatterystaple than it is to get him to a use a password program.

Basically, once you get past the (now huge) dictionary attacks by avoiding those types of passwords, the best thing you have is password length. Padding your password with your own unique combination is a great way to add length to a password, but sitll make it easy to remember.

So D0g..1..1..1..1..1 is a great password. At one hundred trillion guesses per second, it would take 1.28 trillion centuries to crack.

I'm not saying you should use that one, but make up your own padding and add it to easier to remember passwords. It is best to have upper, lower, number, and special character but with a long enough password, it is not essential.

Ultimately I think a better solution would be use more multifactor systems combined with storage and interface standards to enable widespread automation. That would simultaneously give people more security while being more convenient (and in this case the two go hand in hand). I hope Ars does a survey of options relating to that in the future.

Multifactor isn't that helpful against this - it's primarily a defense against MITM/keylogger etc style threats - eg even if someone knows your password, it's not enough to login because they don't have the token/whatever. While that might still sound relevant, it depends on how the particular token works (or it's random seed etc) being a secret and remember these password leaks are *server compromises*. Two factor authenication in the one recent leak it was being employed in (blizzard) was only partly helpful - their servers were storing enough information to validate - and hence *replicate* - at least a couple of their authenticator types (and given how bad their response has been, who knows on the others).

Designing a system that works with users having 25+ different accounts and needing passwords (that are probably logged into from multiple devices including small touchscreen keyboards) that resist attack even when companies (regularly) screw up and leak their entire authentication database may not even be practical I suspect.

Password managers are really the only solution here. You need one great password and it takes care of the rest.

No, password managers are not the solution: if someone gets the master file and able to crack it, then they will be able to access all of your passwords.

You should NOT store passwords on your local file, but store very strong random numbers and combine that with your weak password and submit those to the website. This way an attacker cannot run brute force tests without working through the site where the password would be useful.

Unfortunately the password managers are providing convenience (you do not have to type in passwords for various websites), instead they should improve security (you still have to type in your password, but that can be week and will be combined with something strong).

You obviously have no idea what you are talking about.

The day someone comes along with a crack for AES256 then I will give up LastPass. But if AES gets cracked we are in a world of hurt.

Good password managers ARE the answer. Secure it with a good long password (12-15 characters is likely enough even for any offline attack) and you will have no worries.