I agree with him - it's impossible to remember a unique high-entropy password for every account. I disagree that password managers are the solution. They are a huge single point of failure both for getting locked out of accounts and for security breaches.
I think passwords are fundamentally broken as a security mechanism, once you take human psychology into consideration. We've spent decades trying to teach people to pick better passwords. That didn't work; people still pick stuff that gets cracked in minutes. And now, as Randall Munroe said, it turns out that the "better" passwords we taught people to use are actually very bad. Great, let's spend the next 3 decades teaching people to use long passphrases, and watch that fail too. Then we can start teaching them to stop sharing and reusing passwords (good luck).
A security token (http://en.wikipedia.org/wiki/Security_token) is a fundamentally better solution to authentication. It's not perfect and it's not a panacea, as the RSA security leak/breach shows. But it's better than a completely broken paradigm. Once these tokens acquire enough compute power to perform challenge-response calculations internally, they will be very safe even at untrusted terminals. They've already become ubiquitous in places that really care about authentication on a large scale (like the military), and they should become ubiquitous everywhere. You can have several of them (one for banking sites, one for social...), to avoid single points of failure. They are reliable, and you know when you've lost one. A leaked password manager password, on the other hand, could have the attacker using your logins for months.
A technical solution is preferable to a solution which involves changing human behavior on a massive scale; that is just not going to happen.
"A leaked password manager password, on the other hand, could have the attacker using your logins for months"
That's only half the story as without the password keychain (in the 1Password example), the master password itself it useless. So now you've got to extract a human memory-bound password AND compromise their machine / device / Dropbox to gain access to the strongly encrypted passwords.
I'm with you in wanting a better alternative to passwords, but for now password managers are the best mousetrap we've got. But it's not as easy to exploit as simply obtaining one password.
And if their laptop (or smartphone - there are even worse security breaches possible with them) is rooted and keylogged, then both of these things will happen simultaneously. And they won't find out right away, either.
EDIT: the other problem (again, psychological) is that you can't require users to have a password manager, even if you think it's a good solution, which I personally don't. Your site is not aware if the password came from a manager or from a keyboard. But once you issue security tokens, they must be used. And often, it's not just the user's problem if someone has their password; once someone is in your network, privilege escalation is usually not far away.
if your laptop is rooted and keylogged, you are going to loose access to all accounts you actually use anyway, which probably means the most important ones: your email, your bank, your openid. Oh, and you won't find out right away, either.
Not precisely. Sure, with a session open on your computer and the token inserted, anyone controlling the computer controls the session. But once you close the laptop or take out the key, the access is gone (this is how it works with the most up-to-date challenge-response systems). And yes, you will find out soon, since the results of the recent active session will be all wrong. An attacker can't use the credentials at a later date. I am not saying this is perfect (no security will ever be), but it's stronger than long-term passwords, with or without a password manager.
Even for credentials for multiple sites stored on one token (which is less safe), you at least get the ability - even offline - to see what credentials have been provided to whom. It's just a fundamentally better authentication paradigm, although certainly not the solution to all the world's security ills.
If you're giving the computer, your cryptographic keys from your security token in order to start a session then a malicious program on a rooted machine will have access to them too.
Good tokens don't work that way. Normally your giving out a 5-10 digit code that is valid for 30 seconds and can be compared with a secure server somewhere. Physical devices plugged into the machine often work the same way, but use a longer code that you don't need to enter. In either case the token never gives up it's private key's.
No one is questioning that it's better, just whether it makes sense to conflate a still unfortunately hypothetical system with something immediately available. Until the US financial system starts taking security seriously, I can't force them to switch to token-based auth but I can start using a password manager.
I also find the distinction above almost meaningless for webapps: if an attacker has privileged access, you're screwed. Maybe they can't make actions while you're not logged in but they can hijaack the session and control everything you see each time you do login. Using a more trustworthy client is your only realistic option until banks start requiring one-time codes for every transaction.
Ah, this is true but you've just made a very big leap from simply obtaining a password to now successfully installing a rootkit and key logger and obtaining both the keychain and password. We could go back and forth about the likelihood of this on a patched, virus protected machine (ok, there are still zero days), but we're starting to greatly reduce the probability as it is.
I'd love to see two factor auth or at least the option of RSA style tokens and we're gradually seeing that in some places but unfortunately we're still stuck with the status quo for the vast majority of sites for the foreseeable future.
I don't disagree with that, but I am making a different point. Password systems, by their nature, require lots and lots of actions from users: making up passwords, resetting them when expired, making a keyfile and keeping it safe and backed up (if using a password manager), remembering a long and random master password, and the list goes on - e.g. remembering not to reuse passwords or use similar passwords. It's been proven over and over and over and over again that users will not do these things. It's not like password managers are new; they've been around for 15 years, and haven't made a dent. We can keep banging our heads against that wall, or we can give users a solution that doesn't depend on them doing and remembering dozens of technical actions. "This is the key to your bank account. Don't lose it, but if you do, call us." This can work.
And from a technical point of view, all password systems have a weakness of having long-term credentials - a stolen password can be used for months, at any time, until it expires. That part is not fixable.
So now we're carrying around 130 security tokens? Unless you're talking about this in conjunction with a password manager, all the OP's arguments apply to this too.
The token would either have to work with a single-sign-on authority that would authenticate you to other parties (like OpenID, but hopefully easier to use), or it would contain multiple "authentication slots" for the parties that issue credentials. Both things already exist today, although I don't think they are very widely deployed. But certainly companies that deploy something like the RSA tokens have a company-wide single sign in working with them, and there is no reason for that to stay within one company. Both solutions are technically very different from a password manager.
No. It's better. Because somebody can still your password by eavesdropping. But they can't still your token the same way. (Unless the cryptography used is seriously broken.)
I've tried a password manager. The fact that losing one password would mean losing all of my passwords really bothered me.
It's not commonly talked about, but it's possible to have multipassword encryption. I wonder if a password manager out there supports it. (I think GPG can, so if you consider a test file & gpg a password manager... ;) )
One scheme: There'd be the "normal" login, which would be rotated, then another ultra-high-entropy one written down and locked in a safe somewhere. That way when you spaced out your password, it'd not be "whoops, just blew my credentials... all of them".
Since it's only one password, and there's no maintenance overhead, write it down on a piece of paper, wrap it in tinfoil and seal it in an envelope. Stick the envelope in the bottom of your desk drawer. If you're afraid of losing the password in a fire simultaneously with you forgetting it, repeat for your mothers desk drawer.
Yes, if someone who knows you well physically targets you for your password, that person will likely succeed. But he would probably also succeed using this method: http://xkcd.com/538/
Export the saved passwords, print on paper, and put in a safe place.
Distribute encrypted versions of the passwords on various systems you use, with one very well known and recoverable password. Or encrypted against multiple passwords.
There's a risk, yes, but it's reasonable fungible.
> You can have several of them (one for banking sites, one for social...), to avoid single points of failure.
Carrying a bag of security tokens around with me doesn't sound like a lot of fun - and they're still a single point of failure if you happen to get mugged by an idiot or fall in a puddle.
I am not suggesting a bag of tokens. I think I would like some segmentation (e.g. a banking token that I wouldn't necessarily carry with me everywhere). But that's a personal preference - the more tokens, the more security and reliability. A single token can be used to sign on to many services. That's a technology that exists today - e.g. the US military, which deployed tokens to just about all service members and civilian DOD personnel, certainly doesn't give people a bag of tokens for all the services they need to access. They use a single sign-on system. I don't know if someone has already deployed this for general users (like OpenID) - but it's certainly doable if someone thinks there is a market for it.
You have a good point and I think tokens are very useful for anything were security matters, but of course if you are really concerned about security you will use multifactor authentication (password + token, or token + biometrics, etc).
related: wondering if anyone can offer feedback on an idea I've just implemented:
We're in the process of building a new app and I was giving serious thought to the whole password thing, account creation and lowering barriers to entry. What we've come up with is a means of enabling users to go pretty much password free if they so desire.
What we've done is taken the usual email verification/password reset link (something like /keys/65a8c7bc16e759f28d37950664a397d231c552f9) and instead of directing the user to an account setup or password reset page, we use this to authenticate the user and log them into the app. Currently the links expire but I'm toying with extending the length out to a month or more. Users are free to create and use passwords if they prefer.
Internally keys are treated like passwords (we use bcrypt) with the exception that a user can have multiple valid keys and keys expire.
Weaknesses I can see are - someone who has access to email (physical machine) can log in, will it be a pain to launch an app from an email link (for me, yes, but I've seen users do some very rube goldburgesque things to get to websites). Aside from the physical/email access I think it's probably more secure that the usual users' choice of password
A magic URL that will be recorded in plaintext in the logs every HTTP proxy and tcpdump between the user and your webserver, and in the history database of every browser they use?
At the risk of exposing my considerable ignorance, provided this is done over ssl, how is it different from a reset password link or any other information?
What happens when someone hits your app from a library computer? From behind a proxy? Have you thought about what happens when their IP changes?
Stop. You are inventing a crazy homebrew authentication system here. One great way to absolutely fuck your site's security is through crazy homebrew authentication/authorization/cryptography.
> Have you thought about what happens when their IP changes?
++. When I was walking this road, I answered that question with "I'll use the user-agent instead!" Then I checked that assumption, and the Internet told me that could vary between requests as well. That was the key insight (you can't trust anything) that put me on the road to a much more standard system. (But probably still insecure, since I was younger and working for someone with NIH syndrome.)
I previously did some work for an online poker service who had a financial incentive in knowing who was logging in as who and had a custom client with which they could do all sorts of nasty spyware-esque things to the client's machine. And they were still susceptible to hackers.
You have a browser for a client and HTTP. Please, don't end up on HN as sadly yet another cautionary tale for doing security wrong.
You'd have to also place a secret code on each page, and reject form data or user requests (e.g. to delete their data, etc.) if the secret code wasn't submitted.
I did this for some gold currency systems I wrote a while back (2002-2005), and it worked well. There were some differences. I only allowed one to be active at a time, and inactivated them as soon as they were used (in favor of a session token until the end of the session). Also, users could upload their public key (PGP, GnuPG) and we would then encrypt all email from our system, so between that and SSL-only, I think it was quite secure. I'm in agreement with other repliers that plain text email plus long-lived tokens is a recipe for trouble, though.
These URLs are exposed in all sorts of places; browser history, proxy servers, web server logs and ISP gateways to name just a few. Never put secrets in URLs and expect it to remain secret.
Here's an objective suggestion - put the proposal over on stackoverflow.com and see what response you get.
First, it's ssl only. Second, the alternative (which I'm trying to avoid and where this idea came from) is a user being prompted for a password and responding something like "er, um... Password123" or just using the same password they use for everything else
The idea was that this may give users a bit more time to think about passwords, and possibly be more secure than the usual passwords. Stating the idea here is giving me some good things to consider
Not that I'm advocating this as a good authentication solution, but the worst sorts of exposures you list (i.e. the ones that aren't restricted to the authicatee's device or the authenticator's server) don't apply if you use SSL. Which of course you do.
Replying to myself as it's too late to add an edit
Thanks for all the comments. Appreciate the "don't deviate from the norm" sentiment, but the norm is horribly broken for most users at the moment, and not deviating from it isn't going to make it better. We learn from our screw-ups, not from dong nothing.
That said, I think I may have a way of doing things that will allow for easier first-time entry to the app (no "create password" wall) when a user clicks on their email invite link - authenticate them by the email key and log them in, but make this key single use and display a notice visible within the app that they need to set a password at some point before they leave (if not, they'll need to hit the "forgot password" link next time)
>Appreciate the "don't deviate from the norm" sentiment, but the norm is horribly broken for most users at the moment, and not deviating from it isn't going to make it better.
I'd actually challenge this assertion a bit.
Password management isn't as hard as it should be. I think Bruce Schneier is absolutely right when he encourages users to write down their passwords and store that paper securely -- in a wallet, purse, etc.
The problem, IMO, is that we've told users for years to "never write down passwords!" -- when, in reality, we should've been saying "write down a strong password and keep it safe."
>We learn from our screw-ups, not from dong nothing.
You're braver than I. Screwing up is expected, but security/privacy breaches tend to be among the least tolerated and most remembered screw-ups you can make.
If you do decide to pursue some sort of alternative credential system, it's in your best interest to get a consultation from an experienced security professional, as it could save you black eyes down the road.
I did this with a site of mine a couple years ago, and it worked great.
BUT -- because of the site's nature, 1) a hacked/compromised account would have been a minor annoyance at worst, and 2) users weren't expected to log on more than once every month or so.
I think it depends very much on your site's profile.
I've been looking at this for a while and there really isn't a good solution, in my opinion. So, inspired by a Bruce Schneier post about writing down passwords, my solution is to keep site passwords in a bcrypt encrypted text file, which I print from time to time.
(I chose bcrypt because it works in the command line, which I favor, and it runs in Linux, BSD, or Windows. I would have chosen scrypt but there isn't a Windows binary for it yet.)
You are poorly duplicating a password manager, which is an encrypted DB of passwords plus some UX goodness (autotype, file storage, notes, URLs, folders etc)
Simplicity is good. He knows how his system works, and can extract passwords even if the password manager company goes out of business and the program would no longer work with OS/hardware update. Using a very simple (~1000 lines of code) open source cross-platform tool and plain text is future-proof.
The first part is interesting, if you had been less verbose an ALL the different accounts you had it would have been a more interesting read.
There are still undeniable issues of using a password manager if you lose the data (or your master password is compromised but lets not get into that).
The problem with password managers (or any scheme that creates unique, non-memorable passwords) is that should you need to access a particular service when you don't have your manager available, you're SOL. Being able to pull things out of dropbox and whatever on your phone are nice, but it's another thing to have to rely on.
I've thought a bit about this in the past, mostly relating to setting remote shhd to disable passwords entirely, and only accept PKI logins - what if you need to get in, and don't have your key?
The google 2-factor with optional 'emergency 1-time use codes' that you can print and carry in your wallet is a nice solution to half of the problem (the other half being, if you're not using a computer you control, how do you securely access your password manager?)
I don't really have a solution, other than "remember to take your phone with you", and possibly "ensure that at least your primary email is accessible via 1-time codes or a memorable (and strong) password."
I agree this is an issue, and one I've come across a couple of times. I use 1Password for OS X and iOS. I have the database synced with my Dropbox and backed up locally too. I have two strong passwords that I remember. One is to open up 1Password, and the other is for my personal email address. Now's the time people start yelling at me telling me I should use 1Password for my personal email login too, but that proved, many times, extremely inconvenient.
I use the Chrome and Safari 1Password extensions for 1-click logins, and it's a setup I'm extremely happy with. On the few occasions I've needed to access an account without access to my 1Password, I've reset my password via my personal email address and changed the password when I next have access to 1Password. I'm not going to pretend password managers solve all problems, but they certainly help.
I have three long and complex passwords memorized: my private key passphrase, my 1Password master password and my email password. Everything else is generated by 1Password and kept there. Because I still know my email password, even when 1Password is unavailable I can request a password reset.
This guy's problem seems to be mostly that he can't help himself smearing his sensitive PI all over the Internet, everywhere he goes.
And he's right, if that's your handicap, a password manager is probably the right crutch.
Not saying a password manager isn't a very useful, convenient and most definitely secure tool otherwise, but wow. Doesn't he realize you don't need to give every website every little tidbit of information they ask you? Or that if they do require it, you're allowed to lie your tits off? And that you really don't need to re-use the same account over and over again if you buy at the same place?
And finally, that if some business does require all this information about you, as well as requires it to be true and unique, you probably shouldn't just suck it and bend over, unless, possibly it's your bank and you really don't have choice?
This is just bad personal information hygiene, yuck.
Unfortunately having your PI spread over the internet is now an inevitability, if not through your banking then through your shopping or through your social interactions. We all have our PI smeared out over the web to varying degrees, just look at how many sources of information can be used to start profiling someone with a unique username they reuse: http://www.google.com.au/search?sourceid=chrome&ie=UTF-8...
So we protect our online interests as best we can because we have accounts on Hacker News / Twitter / Stack Overflow / You Tube etc. and even if not exposing PI via the registration process, we expose it via our activities and we want to retain control over that important aspect of our lives. But really, how much information you divulge about yourself is a parallel discussion; I want to protect ANY accounts I create onlne, regardless of how little information I provide.
The main issue I have with password managers aside of being inconvenient and missing when you most need them: They are a bad single point of failure.
Using a local password manager, the file could get corrupted or it's not there when I need in in an emergency. Using a remote one, like LastPass, I risk my passwords getting compromised all at once (though maybe not in LastPass' case due to how their architecture works) or, again, not having access to them when I need them.
I have too many machines I'm using for various kind of work where I need different types of passwords. Too many to sync over my passwords and some not even my own, so I don't even want to sync anything there.
Now I have 4 strong passwords I use. One for banking/financial stuff only, one for work, one for "valuable" private accounts bound to my identity (this account here for example) and one for crappy sites I have to give a password to and I don't care if they lose it.
This way I'm not dependent on that password manager being available at a bad time.
The thought of not being able to log into some server people need me fix just because there's no 3g access in the data center or because an update to the password app on the phone didn't re-import the old data correctly is absolutely daunting to me.
Especially because these kind of failures feel more likely to me than one of my more secure passwords leaking out.
You are afraid that you won't have access to a strong password in case of emergency and therefore you choose to use a weak password? That doesn't make sense to me.
Wouldn't a better solution be to use a password manager and always have a current and working copy on you when you go out? I'm pretty sure it's doable and can be automated. Keepass + Dropbox being one possibility but you can make it more robust if you feel the need to.
Reuse of passwords is a much worse alternative than not being able to fix someone's server on the spot.
>
The main issue I have with password managers aside of being inconvenient and missing when you most need them: They are a bad single point of failure.
Your password manager is only a single point of failure if you only have one copy of the database. You do take backups, right?
Of course then the points of failure become the authentication credentials for that database, in the case of my keepass DB that is the key file and passphrase. The key file I have more than one copy of ferreted away (though obviously not stored anywhere connected to where the keepass DB is stored - keeping a backup of the key file in the same place as the DB would be silly). That leaves the passphrase, which is a set of random words that I do remember.
Using a set of four passwords for all your stuff does not solve one of the main reasons for keeping a password store. The main reason I have different passwords in keepass for every site/account/whatever (aside from one or two things that I might need to gain access to when I don't have keepass available) isn't that I want all my passwords so long and random that I won't remember them: it is that I don't want one hacked site to result in someone getting access to many of my accounts if said hacked account was on a system stupid enough to store passwords in plain text (or some easily compromised format, like SHA1 without a salt or with a salt that the attacker has also gained access to - see http://codahale.com/how-to-safely-store-a-password/ for why). You have no idea how your credentials are stored at the other end, so I err on the side of caution and assume it might not be secure.
That's pretty much my strategy but I have about 30 passwords I reuse for different things. Like you I have 1 for "my weekend project" signups, 3 or 4 for social or other information type accounts, 1 or 2 for non-banking financial stuff eg. PayPal 1 for each main bank account or credit card, one for each main email, then a couple for communications services, the onto unix machines, root passwords, passphrases, SSL certificates, each of those has a pool of 3 or 4 passwords I re-use regularly.
I probably couldn't list them all but the idea is that they each have a common "threat level" and I'm generally able to get the password right for things I use every week first go, then it might take 3 or 4 tries to get it right for services I use less frequently but I rarely have to use the forgotten password link.
I've seen bots try thousands of passwords for a single account on services that I've had access to the logs for. I can't name any instance when a password has been found by brute force rather than human engineering (or by bypassing authentication completely due to exploiting a software bug), and I've not seen it often, but there is code out there actively trying.
Tools like fail2ban help a little here, but can't do much against a large botnet. Adding artificial delays into the authentication process can slow down a brute-force attempt without inconveniencing real users at all, but that botnet has a lot of time on its hands. It might not happen often, but attempts are made often enough (i.e. more than never) for keeping strong passwords to be worthwhile.
Thanks, that is interesting and kind of matches my reasoning.
I have a feeling the debate is a bit colored by leftover paranoia from the times when several users shared one computer and the password database was easy to get hold of.
Unless the attacker somehow manages to grab your password database (and not your content, which would be an interesting setup in itself) he won't be able to brute force you. He will only be able to lucky-guess you. And you don't need 24 random characters to block a lucky guess scheme. :)
My strategy for passwords (that's been working well so far) has been to have an easily mentally appliable password function that I use to generate/remember passwords and change that every year.
For example, if it's my google account, the sites name is 'google'. I take the first two characters 'g' and 'o' and think of the first animals that come to mind, (for me it's giraffe and ostrich) then replace all obviously changeable vowels with numbers (so they become g1r4ff3 and 0str1ch). I then concatenate them with a % symbol, prefix with a _ and suffix with a #, giving me a password of:
_g1r4ff3%0str1ch#
Which I think is a fairly strong password. It also means I have a unique password for every site I jave an account with. Of course if you figure out my function then you know all my passwords, which is the reason I change it every year or so.
No, it's not a strong password just because it looks like it (which is the point of the latest articles). You choose from a small group of words (animals) and do a naive character substitution that specialized programs can (and do) anticipate.
1Password on the Mac is great. I actually also have the iPhone application, and I can't imagine what I'd do without it now. Well, especially since now all of my passwords are random for the most part. I'd definitely recommend it.
The only downside is that they don't have a version for Linux. Oh well.
Unfortunately, DropBox doesn't work in China. I have resulted to using a USB thumbdrive, but that's not as elegant. Can't use VPN at work, either, which sucks.
This is far and away not the best solution, but it works for me, and I can use it with only mild annoyance from a computer where I haven't "installed" it, by using an online sha256 generator. On a mac, replace "sha256sum" with "shasum -a 256".
I also suggest that if you have multiple accounts on a single site, you run "mypass user@domain.com" instead of just domain. It works fine either way, just be sure you are consistent across all sites, lest you forget your scheme.
Dropbox + Keepass portable works well for me. I use the password plus a key file which is never in dropbox also, just in case dropbox gets compromised.
My biggest problem with passwords? That so many sites aren't up front with what's allowed in their passwords. Sites should tell you how long your password can be, and what characters you can use in it.
I just know that since I started using a password manager, I don't even know most my passwords, they're about twenty characters long, a jumble of characters (letters, numbers, and symbols,) and I'm happy with that.
I don't even think Google's password length is known, is it? I get that this means others don't know how long it could be either, but, that doesn't seem vitally worthwhile. Maybe I'm wrong.
> That so many sites aren't up front with what's allowed in their passwords.
This makes complete sense... they feel that obscurity will aid in defending attacks (esp. if they have some ridiculously small password-space like 6 digits).
Considering it's a small inconvenience when you first create your user password, then from a cost/ben point of view, I can see why they wouldn't advertise this info.
The problem with password managers is they you need to have it with you. With a phone app that becomes more likely, but smartphones run out of battery all the time. What about when I'm visiting someone, the phone is out of battery and I want to check my email on their computer? Or when I'm on a trip, the phone is dead again because I haven't found a socket for a while, and I want to book a ticket somewhere?
Use Dropbox, sync the DB to a flash drive aka use a more robust solution than a smartphone, or get used to it that encrypted passwords may mean there will be situations where you wont have access to them.
The takeaway from this article is actually, to me, quite amusing: Have fewer accounts. From online banking (he does online banking! laughing-girls.jpg) to shopping to eighteen social media accounts -- this is too much!
Admittedly, I don't do Netflix, or iTunes; I use passwords like "I bet shittyforums.example.com uses plaintext" for shitty one-off forums; when I don't care about a site, but want to see its content, I participate in BugMeNot. I actively work to reduce the number of things I'm signed up for.
The alternatives are a local password manager (a refrigerator) or a remote password manager (a guy with a truck who will cart your food around for you.) You can't take the former with you, and you can't trust the latter.
Things like shopping and social media add up before you know it and it's only once you actually start tracking them do you realise how many you have. Think of just the really globally common shopping stuff (eBay, Amazon, Go Daddy), then add some local services (pizza delivery, online tech stores, magazine subscription) and you're more than halfway there already. You'd be surprised!
Follow Randall's advice, but take the first letter of each word in your sentence. You don't even have to come up with a particularly random phrase, take a song lyric. Doesn't match any common password pattern (i.e. 'someRealWord[digits]'), and it's still very easy to remember.
Your method is vastly different from Randall's method, each word there gets 11 bits of entropy because it's randomly chosen.
In properly formed English sentences, each character only has about 1 to 1.5 bits of entropy, and I'm not certain that taking the first letters of words in a sentence would have much higher per-character entropy than that, as the first letters of words are not very randomly distributed.
I think passwords are fundamentally broken as a security mechanism, once you take human psychology into consideration. We've spent decades trying to teach people to pick better passwords. That didn't work; people still pick stuff that gets cracked in minutes. And now, as Randall Munroe said, it turns out that the "better" passwords we taught people to use are actually very bad. Great, let's spend the next 3 decades teaching people to use long passphrases, and watch that fail too. Then we can start teaching them to stop sharing and reusing passwords (good luck).
A security token (http://en.wikipedia.org/wiki/Security_token) is a fundamentally better solution to authentication. It's not perfect and it's not a panacea, as the RSA security leak/breach shows. But it's better than a completely broken paradigm. Once these tokens acquire enough compute power to perform challenge-response calculations internally, they will be very safe even at untrusted terminals. They've already become ubiquitous in places that really care about authentication on a large scale (like the military), and they should become ubiquitous everywhere. You can have several of them (one for banking sites, one for social...), to avoid single points of failure. They are reliable, and you know when you've lost one. A leaked password manager password, on the other hand, could have the attacker using your logins for months.
A technical solution is preferable to a solution which involves changing human behavior on a massive scale; that is just not going to happen.