That attack isn't unique to a system with reversible encryption. If I can change the e-mail column, I can do this on any system with one-way password hashing too.
No you can't (or rather, it's not very useful). Sure, you can set someone's password to something you know that way - but since you've already got write access to the database, you might as well do it directly.
This is a flaw of any system that sends your password back to you in plain text, that is not shared by systems that don't.
If I can change your e-mail in the database and have it send me your password reset e-mail, I'm in. Write access to the database is a huge issue in that case whether or not passwords are hashed, encrypted, or plain text.
Not always. For example, in case of website with open registration, an active attacker may exploit SQL injection and register new accounts (with arbitrarily chosen passwords), observing new records in DB.
Which, with proper encryption, likely won't get you anywhere. If the encrypted password is hashed with the username (or something else unique/random to the record) as an add-on salt, you won't even be able to find out which users are using one of the 500 most common passwords this way.
You can see why it's not particularly useful arguing about encryption with you; for instance, the way you'd encrypt passwords, you'd need an "add-on salt" to keep password ciphertexts from being directly comparable.
The likelihood of me personally explaining why that's broken is low, because my sense is that you would immediately adopt some variant (but not exactly that) as part of "what you meant by proper encryption", and then mint another counterfactual from that.
64 comment-thread go-rounds later, you have indeed come up with a reasonably strong password storage system. Of course, you did it by cadging free consulting from the thread, missing the point that virtually nobody who builds these systems would even know that they needed that consulting in the first place.
We could play a similarly fun game by arguing about how an attacker would coerce a shell out of an SQLI flaw. Or: better yet, we can not do that, and just assume you're mostly wrong.
The worst part of this attitude --- and it's not unique to you, it's a nerd trait, and I certainly have it in spades myself --- is that it strongly suggests my best incentives are to be as un- informative as possible, so as not to have to waste time refuting further counterfactuals that you invent post-facto.
> 64 comment-thread go-rounds later, you have indeed come up with a reasonably strong password storage system.
The reasonably strong password storage system is a one-way hashing with bcrypt. That'd be the way I store them, grumpy asides like "the way you'd encrypt passwords" not withstanding. No need for "free consulting", thanks, especially when delivered in such a manner.
My point is not "you should use reversible encryption". My point is "reversible encryption is not the same as plaintext storage", a point borne out by people using HTTPS, PGP, etc.
I don't like getting a plaintext password sent to me via e-mail any more than you do. That's completely besides the point.
If the encryption is done by the DB layer, which it often isn't.