There's absolutely a distinction. Reversibly encrypted passwords aren't ideal, but it does at least make a database dump less useful to someone who manages a SQL injection exploit.
No, it means that getting the actual raw passwords is now a fun little puzzle for anyone who gets SQLI.
News flash for the (hopefully small) collection of people who may be kidding themselves on this point: unless you've gone to significant lengths to mitigate this specific problem, if you give up the SQL for your website, you've probably given up the box, too.
How likely is it that you're THAT company, the one that hardened their database server and app architecture so that it can survive someone who compromises SQL, and that you actually have SQLI? And, if you're THAT company, how likely is it that you're storing reversably encrypted passwords? And if you're THAT company, how likely is it that you're simply mailing them back to customers on request? It's not likely.
One would hope that the encryption key wouldn't be in the database.
The point remains - there is a benefit to reversibly encrypted passwords versus plaintext ones. It's certainly not ideal, but it's better than nothing.
Respectfully, who gives a shit if it's in the database? If you lose the database, you lose the box. You're done. Whatever information you were storing reversably anywhere in your data center, you are going to lose.
Don't store reversably encrypted passwords: full stop.
Hardly. The SQL injection may have occurred with a limited-access SQL user. The encryption algorithm might be strong enough to give you years or decades of protection against brute forcing. etc. etc. etc.
> Don't store reversably encrypted passwords: full stop.
Absolutely. I'm just pointing out that "there's no difference between plaintext and reversibly encrypted passwords" is a blatant lie.
You already responded to the comment where I said it's possible to rig up a database so that your app server might survive SQLI, so let me just wrap this unproductive little thread up by saying: I don't believe you. If I see you mailing user passwords back to users, I will bet on SQLI losing all those passwords every time, at any odds.
Nerds like us are always going to come up with some twister counterfactual scenario where someone somewhere could do something unexpected. I don't care. None of this is relevant to the issue at hand. This company probably isn't even encrypting passwords, but whether they do or they don't: if they get owned up, they're losing all of them.
If your email provider supports CRAM-MD5 or DIGEST-MD5 authentication (on SMTP, POP3 or IMAP) — they're storing your password either in plaintext or reversibly encrypted.
If your ISP provides PPPoE, PPTP or IPsec-less L2TP connectivity and support CHAP, MS-CHAPv2 or PEAPv0/EAP-MSCHAPv2 authentication — they're probably storing your password in plaintext.
And while the email providers'd better start dropping this practice (as most mobile phones nowadays support SSL/TLS) and use TLS, ISPs are better stay with plaintext passwords. Wiretapping Ethernet, DSL line or open WiFi hotspot is orders of magnitude easier than hacking into the database. Obviously, that's only until the day majority of SOHO routers and other client hardware would support EAP-TLS.
CRAM-MD5 and DIGEST-MD5 are terrible for exactly this reason; a similar argument is part of the reason nobody uses HTTP digest auth. Mitigating this vulnerability is part of the motivation for SRP, which is computationally hard to brute force and non-reversable.
An active attacker having access to the DB, may use encryption to his heart contents.
If encryption's badly implemented (for example, using algorithm prone to chosen-plaintext attacks, or encrypting without salting so same plaintext are always encrypted to same ciphertext) no knowledge of key material is required to gain access to fairly significant number of accounts.
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.
