[tptacek]

Trenchant, but ultimately orthogonal.

The Big Problem here isn't that Hover has decided that user convenience warrants storing passwords insecurely. That is a problem, of course, but it is not as big a problem as The Big Problem here.

The Big Problem is the grafs spent defending the soundness of Hover's password storage strategy. Hover does not appear to understand that they have conceded user security. They believe that a combination of their network security and physical security† mitigates these flaws. If you're going to sell out user security to minimize customer support costs, I'd at least like to know that you know that's what you're doing.

That Hover does not appear to know what they are doing suggests that there is much more badness to be had in their systems, which is a problem that will burn them much more painfully than password hashes.

† Notably, not application security --- no external auditor would let "user passwords appear in plaintext in a database column" slide.

[raganwald]

I see were going to argue about whether to ascribe to malice, that which can be explained by stupidity. I'm going to go against the aphorism and say "malice." I suspect they know exactly what they're doing, and they also know that their strategy of "security be damned, let's sell some more domain names" requires a plausible explanation of security, thus they come out and tell us something that you and I know to be false.

But the audience for this blatant nonsense are the people who want Hover.com to mail their password to them, so they think they can get away with telling us that "a combination of their network security and physical security† mitigates these flaws." You know this to be false, I know it to be false, and I suggest they know it as well.

[tptacek]

I think it's slightly more likely that they think it might be true, and they want it to be true, so they're going to be incurious. Either way, my only real point is: there's probably going to be SQLI somewhere in that app too. And if they take file uploads anywhere, my guess is you'll be able to run code remotely.

(I know neither of these things to be true for a fact and am just making a rhetorical point.)

[geon]

> They believe that a combination of their network security and physical security† mitigates these flaws.

That is not how I read it. You could argue the other way:

If they have to send password reset URL:s anyway, they can just as well send the password itself.

That makes sense. It's just that by storing the passwords at all, you risk losing them if someone gains access to your database.

[pavpanchekha]

The URLs are usually time-linked, one-time, and service-specific, as opposed to the password, which 1) is permanent, 2) can be used without the user knowing, and 3) is likely to be used on other services as well.

[eru]

Also a legitimate user will notice when somebody resets their password, because their old password won't work any more.

[sbierwagen]

You appear to not understand how password hashing works. A well designed hashing function is one-way, it cannot practically be reversed. With a large salt, even very weak passwords ("cat") cannot be reversed.

https://secure.wikimedia.org/wikipedia/en/wiki/Password_hash...

[Dylan16807]

Salts only protect against rainbow tables. If you want to stop brute forcing you need a very slow hash like bcrypt.

And you'll still be able to brute force "cat" in under a day.

[tptacek]

Not only that, but the size of the "salt" has nothing to do with how long it takes to brute force a password. We should stop saying "salt" and start saying "randomizer" so at least people understand what that thing is doing; I think everyone understands intuitively that a hash can be "randomized enough" so that further randomization isn't a win.