They are not necessarily storing the password in plaintext. However, they are:
1. Storing it in a recoverable format, instead of a format that only allows verification.
2. Emailing them in plain text.
Both of which are bad.
1. Storing it in a recoverable format, instead of a format that only allows verification.
2. Emailing them in plain text.
Both of which are bad.
"In a recoverable form" means that a) there's a single key with which to decrypt the passwords. If I can get the password list, the key isn't far away. And it might not be worth the effort to track it down, since it's practically equivalent to have the (two-way) encrypted passwords and to have the plaintext.
But it gets better! If you have access to the encrypted passwords, but not the key, then they're safer than hashes, since the attacker cannot try to bruteforce them (he could try bruteforcing a very very long encryption key of course...)
If an attacker gets access to the database, chances are very very good they can get access to the key as well. Very few services correctly separate privileges well enough that an attacker can not gain more access once they have database access.
However ... for the sake of argument, just pretend there's only a 50% chance the attacker can get access to the key. Would you rather there be a 50% chance that you leak EVERY password in the database (regardless of strength) or would you rather lose the people who pick passwords in the 5% because you've used bcrypt?
The key should be provided to your application on startup.
Or sometimes, the key can be in the wallet and that wallet can open only during startup of the application: application should prompt admin to enter password needed to open the wallet.
At least that how I design my systems... Maybe I'm wrong...
Anyway application which need to be secure are not the one you also would like to be restarted automatically or unattended: automatically restart can in many cases just make situation worse (i.e., data corruption)
You can always pay big bucks and use Oracle Database with Transparent Data Encryption: in that case, you need to enter password to open the wallet only on startup of a database.
But in the meantime, I'm curious about what web-based attacks relevant to password storage reversably encrypted passwords protect against. Were you thinking SQLI? Because I do not believe this to be the case.
Don't store reversably encrypted passwords.
Update: from other posts, I'm guessing you're assuming that anyone with sqli has other problems too, and that's why you don't think it's safe from sqli?
Edit: Of course you did say 128 bits, which is pretty good. But if you do manage to break it, you do have the master key, which can't happen with hashed passwords.
Why would you assume this? It's entirely possible that a compromise will allow file system access, which will give the DB and the key. As for memory storage, you've got to have the key somewhere so that the machine can restore itself after a reboot. An in-memory-only key isn't a very practical solution. It's also entirely possible that you memory-only key will find its way to the swap file, again vulnerable if FS access is gained.
> But it gets better! If you have access to the encrypted passwords, but not the key, then they're safer than hashes, since the attacker cannot try to bruteforce them (he could try bruteforcing a very very long encryption key of course...)
This isn't necessarily true. Hashes are not intrinsically easier to break than encryption. Some hashes (such as bcrypt) are based on an encryption anyway.
In many very secure systems, this "somewhere" is in the brains/completely secondary data stores of a group of admins who enter that key when a reboot occus.
I agree it's possible for high security situations where passwords need reversibility, though. e.g. I wouldn't be surprised if Intuit used a system like this when they store passwords for external services. (They should still be hashing users' primary passwords, though.)
In most companies, the database is significantly more accessible than any encryption keys. For goodness sake, marketers typically have query access to the DB.
And the issue of emailing a password is different. The problem there is that if I gain access to your email account, I can quickly search "password" to discover your private passwords that a company, not you, chose to drop into your email account.
But to be clear, user-created passwords should be stored one-way hashed and never emailed.
That's a bit of a straw man, don't you think? Even if marketers have access to the database, they shouldn't have read access to the passwords table in a properly configured system. If they do, it's time to fire your DBA.
> The problem there is that if I gain access to your email account, I can quickly search "password" to discover your private passwords
Sometimes it's worse than that. I recently had to do a password recovery on a site, and they sent the password not only in plain text but also as the very beginning of the email. As such, gmail helpfully showed "example.com" as the sender, with "Password: P@ssword1" right in the body preview snippet. You could see it without even having to open the email.
It may not be a common exploit, but if I was checking my gmail at work, a coworker that knew I had an account on this website could just send a recovery request and glance over my shoulder at just the right time and grab my password without my knowledge. Not good.
I wish Google would implement some sort of algorithm that could determine password-looking text and a) not show it in the preview, and b) require user interaction to display it when viewing the actual email body.
I can guarantee that it happens. A lot. And firing the DBA is a poor solution.
What you do is make a view that does not include the password column, and give them access to the view, but not the table.
(Still shitty, though)
If I can pull a list of two-way encrypted passwords, breaking that is way faster than extracting passwords from a properly crypted list. Essentially it's a huge list of short (almost known plaintext) messages. If you know a cryptosystem that will resist attack in that circumstance, please share.
Properly crypted, passwords admit to local brute forcing, which is bad for any particular account.
"Recoverable" passwords, the whole list admits to statistical attacks that break the whole list.
How would one go about securing such a system where there is no option but storing encrypted passwords that are reversible?!
Change the system.
What makes you think the key isn't far away?
I have no reason to believe the above is true, but there is also no reason to automatically believe there is a mechanism available to attackers of a compromised machine to decrypt all encoded materials on the machine.
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.
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.
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.
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 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.
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.
If the encryption is done by the DB layer, which it often isn't.
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.
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.
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.
Even if the password were irreversibly encrypted, if I can read your e-mail, I can still access your account in most systems. I can reset your password, and either follow the link they e-mail you, or see the random password they generated for you.
I think #2 is more on you for accessing your e-mail securely, and less on Pingdom. Pingdom is only saving a hacker a little bit of time.
You can 1) Email the password or 2) Email a unique link which lets them reset the password for their account.
If you do #1 the person likely used that password on other accounts. Now you've not only compromised access to your service, but any other that has the same password.
IF you do #2 the user sets a new password and gets into his account. No record of the new password is left anywhere. An attacker with access to the email account can still compromise your service, but now he has no idea what the old password was.
Secondly, the link can expire after a certain amount of time.