HN2new | past | comments | ask | show | jobs | submitlogin

I'll play along. How do you know that they didn't store the password in an encrypted format using e.g. DSA? For argument's sake, let's say this happens:

1. You create your password ("ABCDEF").

2. Their system stores it to the database encrypted ("a;kdjfa;oisdurpoqiwur,m c3249um zxc,vmvsdflkgjad[fiualmdr23,4mo;icuzvlcm œ rtoqieuroier").

3. You click "I forgot my password".

4. Their system transforms the encrypted format to your original ("ABCDEF").

I think you mean to say "we know that they have not stored the password in a non-reversible format".

This is pedantic, but specifics matter when talking about security.



They may have indeed encrypted somthing with RSA-4096 or whatever. But that's irrelevant security theater once they decrypt it and send it to you in-the-clear over email. Not only is the email plain text on the wire, an unknown number of email servers will handle it along the way and many of them will log it.

It also means they have the decryption key available to online systems. It's almost certainly exposed to the very same vulnerabilities that the rest of the database has.

A cipher is simply a means of converting a plaintext secrecy problem into a key distribution problem.


And for the folks who didn't request their passwords via email, the passwords are stored encrypted on a disk, like their credit cards. That's not security theater. What you mean to say is that "this system has a downstream vulnerability for some use cases." That's a lot more accurate; why not say that instead of leaning on the trope of "security theater"? Obviously that vulnerability is pretty severe, but it still pays to describe it accurately.

The reason precision matters with security is because taking the "conservative" approach (also known as the "chicken little approach") ensures that normal people will tune out and ignore security altogether. When making security claims, it pays to take 10 seconds and write what you mean. It's not hard in cases like this.


I can (and will) speak and write for hours about authentication if you get me in the right mood. (Luckily I need to go to bed now :-)

But if you think that there's a 10 second formulation to the multitude of subtleties involved here, well frankly that's dangerously simplistic.


The 10-second formulation: "these sites will email your password, meaning it can be used to compromise your account."

That's precise, short, and easily understandable. It's also verifiable. I'm sure you can come up with something that hits those marks just as quickly. It's really not hard, which makes the sloppiness of this site's claims more annoying.


With your formulation, a site can get itself off of the offender list by not sending certain emails. Yet in most of the password data breaches we've seen in the last year, the email was not actually the method by which the stored credentials were leaked. A simple web search https://www.google.com/q=plain+text+password+breach shows that plaintext (or improper hashing) of database-stored credentials is probably a more common factor.

Your formulation is "precise, short, and easily understandable" but it's also wrong. You're making the mistake of measuring the thing that's easiest to measure rather that the thing that's most important to improve.


And for the folks who didn't request their passwords via email

By definition, we don't know who has requested that the password be sent via plain text email because that party has not successfully authenticated as a known user.


Seems to me your example is like a bank storing things in a secure locked vault, then leaving the key in the vault door at all times. It's technically accurate to say the valuables are stored in a locked vault - but the actual security level is no better than being stored in an unlocked vault.

In other words, what is technically correct doesn't convey an accurate impression.

If you're dealing with a bank that keeps their vault key in their vault door, or a member of the public choosing a bank, they might not have the nuanced understanding of security to understand the problem if you use too much technical jargon.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: