[dexen]

Please correct me if I'm wrong, but... storing password hashes (actually key derived from password) is only meant to secure up password re-use. If there is any other reason, please disregard the text below and just correct me ;-)

Isn't password re-use a social problem rather than technical one? Perhaps we ought to use a different -- social -- measure to prevent password reuse. Throwing technical solutions onto social problems doesn't seem to work.

Proposal: let's store all passwords plaintext and force users not to re-use passwords, ever. Let's have every password-using service and system make available hashes (derived keys, to be exact, bcrypt() style) of the passwords completely public; when a person tries to create a new account, the service would check a good bunch other services against password hash matches. If the new password (used upon registration) hashes to the same value as on any checked service, the user is rejected and publicly shamed for endangering the service and his account. More checks cound be performed after the registration in background, to lessen the delay on registration.

That's it. Social problem, social solution.

[kogir]

You're wrong. I use hashes so that if somehow the hashes and salts leak the attacker can't now log in as any user with no additional effort. While it's true that a hash compromise typically means you're owned, not having plaintext passwords available still makes further exploitation slightly harder. For instance, read only SQL injection that leaks hashes won't let the attacker write anything.

[pavpanchekha]

Social problems can get technical solutions. That distinction in bullshit and should be educated out of the Hacker populace. Password reuse (which, BTW, is not why we hash passwords) can be solved otherwise; for example, you can hash passwords client-side and then again server-side, both times salting with a unique salt. That way, the password itself is uniquified in a non-reversible way by your salt (which is presumably not used elsewhere). Your client-side hash can be very expensive, since it's done on the client, and the password you recieve (the hash, that is), is guaranteed unique.

[AlexandrB]

For most people the social solution creates a worse usability problem than the one Hover is trying to fix. With unique passwords, the user is now responsible for maintaining (and securing) a list of passwords. Password managers can help here, but this assumes that the password manager doesn't have exploitable vulnerabilities of its own. In addition the password manager may not be accessible when not using the "home" computer.

[Uchikoma]

If someone gets read-access to this database he can log into my account independently of me reusing passwords (which I don't) or not. The problem is not on my side.