[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.