That doesn't necessarily mean that the password
is stored as plain-text.
Sorta, but the difference is probably only one of magnitude. "Dump DB" is larger but not really remarkably different than "Change customer's e-mail addy to my e-mail addy; email password reminder to 'customer' (now my addy); change customer's e-mail addy back". It's still pretty clear-text-y.
How is that different than most systems that do hash your password and then email you a reset link? The process is slightly different, but the results would be the same. Am I missing something?
Yes. That person would then have access to your account on that service, but would not have the password that you used. Since people often use the same passwords across multiple services, that password being exposed would mean that their accounts on multiple services is theoretically exposed.
While I don't condone anyone using the same password on multiple services, it happens. Given that hashing a password and providing a reset link is "novice" level easy, it should be a standard practice.
You can always save a hash, change the password, and then restore the hash. Basically, if you have direct access the the DB you can loin to someones account without them knowing or permanently changing the password. Granted, there are some minor issues with salting passwords etc, but protecting an account from someone with long term RW access to a DB and reasonable understanding of the system is next to impossible.
Ah, yes, that makes sense. I was considering the case where the attacker simply wants access to your account on 'compromised system x' -- not where they're simply using 'compromised system x' as a conduit for obtaining your password (in the hopes that it's used elsewhere across the web).
The other issue is that the former can be done without the affected user knowing it. If a attacker resets your password, you're going to know right away when you can't log in.
