[sporksmith]

I agree this is a major issue, and in fact was specifically covered in an earlier xkcd (http://xkcd.com/792/) than the one cited (http://xkcd.com/936/).

It might be a good idea to enforce non-password reuse, but the proposed solutions seem fairly aggravating. In particular the 'webmaster' solution of requiring inclusion of a fixed string is extremely annoying (oops, sorry users who use cryptographically derived passwords (http://passwordmaker.org/)), and doesn't solve the problem since someone with your "main" password can probably guess the "derived" password (e.g., the main password with the mandatory substring appended to the end).

My solution as a user is to just use a password manager. I use clipperz(http://clipperz.com/), but there's plenty others out there.

* Edited to remove markdown-style links. Forgot it wasn't supported here.

[diego]

The point is that the mandatory substring is random and unique to you. The problem with using a password manager is that it implies that you're already savvy enough about the issue. Most people have no idea such thing exists. How could you enforce the usage of a password manager?

[dohko]

Well.. why not do it half client-side and half in the cloud? For example, why not build an pwd-management application which sits in the cloud.

Have the application store in a secureDB in the cloud your encrypted list of passwords. These would be encrypted with a master pwd stored in the local pwd repository of your (mobile) browser.

The idea would be to have the browser do all the leg work for you and have the pwd management service available form anywhere.

The browser would automatically generate a new complex pwd for each new website you subscribe to, then encrypt it and send it over to the pwd mgmt app in the cloud. When you authenticate to the website, the browser queries the pwd mgmt app for the pwd of the site. The app sends it to the client.

In this whole process the whole encryption/decrpytion happens locally, thus limiting the attack surface. It would be easy to use and overall seamlessly integrated with any device you own that has access to the internet.

[sporksmith]

That's exactly what Clipperz does :).

The main weak point is there's no way for the user to know if the javascript they're downloading is the correct Clipperz javascript, or a trojan'd version that will send my master password and decrypted database off somewhere. So, pretty much all is still lost if someone is able to break into Clipperz and modify the javascript without being noticed for a while.

A possible solution to that is to implement a browser extension to hash the javascript (and perhaps display it as a visual hash) so the user can at least easily check whether it's changed. This has been on my "possible side-project" list for a while...

[sporksmith]

> The point is that the mandatory substring is random and unique to you.

Ah, that's a little better. I still think the security gained is not enough to justify how much of a usability problem this could be, though. Assuming the per-user fixed substring is a secret, you're basically assigning the user's password (though giving them an option to strengthen it with their own 'root' password). If it's not secret then not much security is gained.

> How could you enforce the usage of a password manager?

I don't know of a good way. Although if every site starting assigning (part of) the password, as above, I suppose that would do it.

[georgemcbay]

Even if the substring is random and unique to a user it'll still be easy for an attacker to guess which part of the password that is, just like it is usually obvious which of the recaptcha words are the known and which is the unknown.

eg: mysillypasssoqpword Yeah, I think I can guess what happened there.