Plain-Text Offenders Hits 1000 | Hacker News Reader

Plain-Text Offenders Hits 1000

plaintextoffenders.com

28 pointsomervk56 comments

The pedantry in some of the comments have me practically smashing my head into my desk. The semantic arguments about whether the actual password storage mechanism is encrypted, encoded, etc, are wholly irrelevant.

If a web site can sent you a "I forgot my password" reminder email which includes your plaintext password then the site operator is storing the password in a plaintext-equivalent format. If the password is stored as a plaintext-equivalent then attackers can steal your plaintext password when they "own" the site.

To address the encryption pedantry: If a site is using encryption to store the password but the key to decrypt the password is available in the site's servers then, arguably, the encryption just amounts to an encoding. Symmetric encryption requires that the key be kept secret. Keeping the key on the servers means that it's not secret and means that it's not really encryption.

Edit:

I see that the discussion is heading this way so I'll head it off at the pass: I would argue that there is no reason that any site operator ever needs the plaintext of a user's password to be stored persistently for any reason. There is no valid reason passwords should be stored in a reversible manner.

(Somebody is going to bring up storing credit card numbers with symmetric encryption, too. That's a broken system and, arguably, needs to be replaced with something based on asymmetric encryption instead of "secret numbers" that we have to transmit between quasi-trusted parties.)

Granted, a lot of this discussion is pedantic.

Devil's advocate: why is it pedantry to ask for security alarms to be precise? We ask for e.g. the TSA to be precise about what it needs, should not computer security professionals be held to the same bar? Making bogus claims about a system's vulnerability (be it shoes at airports or passwords) damages the credibility of the next security alarm.

Note: I'm not defending the practice of sending passwords in the clear. But I don't think it's too much to ask for security professionals to make precise claims, when doing so is a 5-second op.

The pedantry that's irritating me is this argument about there somehow being a "safe" way to store the plaintext-equivalent version of a password (there isn't) or even that there is somehow a need to do so (there isn't).

I agree that the Plain-Text Offenders site should state this plainly.

We are. http://plaintextoffenders.com/about

That's a nice little write-up, I think it would be great on the main page.

I didn't look for it under "About" because I'm used to that being for personal details about the project's people rather than intro or summary info.

Don't smash your head. :-) Issues of authentication are inherently difficult for us humans to think about. Look at an issue one way and it's obvious, from a slightly different perspective it's extremely subtle.

Omer here, one of the two guys behind this website. I'd like to thank the Hacker News community, who are in part the reason for our site's popularity. Thanks, everyone. Please keep spreading the word! :)

Since we have an interesting discussion going on, would you care to share a bit about the methodology?

How do you determine by external observation that a site's password handling is sufficiently bad to merit the Plain Text Offender title?

It depends on the evidence the submitters send us. If it's a Forgot Password or Password Reminder (or sometimes being told what your password is by a CS rep), that's evidence enough. We also allow for Here Are Your Details emails after registration as evidence, though the probability is small that passwords are stored in plaintext/reversible encryption (but we still believe it's an offense since the password is both sent over an insecure medium and is stored on the email server).

Isn't there also the chance that they only send plain text at the time of storage? Would you still consider that a plain text offender?

Yes. We have talked about this in the past and all of the links are in the about page: http://plaintextoffenders.com/about

I wonder how they can be sure that a website stores their website in plain text? Just because a website sends an email confirmation with the password doesn't mean they store it in plain text. The developer could just send the email before hashing the password.

Not saying it's a good practice to send the password by email but it seems the website stretches the truth a bit.

The majority of the items on the website are password reminder emails. This is after the initial sign up, which means the do indeed store it in plain text.

Either that, or they store it in encrypted format. Encryption typically implies that decryption is possible. Encrypted text is not plain text. These terms do have real meanings.

You mean to say "the sites do not store the text in non-reversible format."

Encrypted text is equivalent to plain text to anyone who has the ability to decrypt it.

What passwords need is a secure password hashing method. It's a very special purpose sort of thing, different from ordinary hashing, encrypting, and key derivation. It's unfortunate that it doesn't have a proper name.

Neither "PBKDF2", B-"crypt", nor S-"crypt" are helping much with this terminology.

>> "Encrypted text is equivalent to plain text to anyone who has the ability to decrypt it."

This is a vastly different claim than "these websites store passwords as plaintext." There are a lot of differences in assumptions and attack vectors, etc.

It usually pays for security alarms to be precise, and this site almost goes out of its way to be imprecise (and likely inaccurate). In this case, your verbiage would work great for the site in question. Why not say these are sites that don't use "secure password hashing methods" instead of making bogus unverifiable claims?

This is an objection without much substance. The main thing that you're worried about with a plain text password is that it will be obtained by a third party.

These are sites which are sending emails with passwords in the clear. They are also storing your password near the decryption key (if any), so a single security breach can compromise many passwords. That is to say: even if the rest of their infrastructure is NSA-level paranoid, whichever server(s) are sending out these password reminder emails are prime targets.

Please do not defend this behavior.

Please read my comments: I'm not defending the sending of plaintext passwords.

But please do not defend sloppy claims of security vulnerabilities.

I gently agree. To be fair to the site, they do mention (admittedly on the bottom of the about page)

> More reading on why even _just sending the password_ via email without storing it in plain text is bad.

Which has a hyperlink to

(http://plaintextoffenders.com/post/7006690494/whats-so-wrong...)

> What's so wrong about sending a new password in plaintext? It doesn't mean that the password is saved in plaintext...

Ironically enough, I went to log in to HN specifically to upvote comments in this thread, forgot my password and had to use the 'email yourself a new password' function.

Granted, it sends a randomly generated password. And granted: it's probably meant for one-time use only (I presume). However, logging in with the new password does not automatically prompt (or even force) to change it to something of my own choosing. Result: hit 'remember password' in Chrome and forget about it. Now my active HN password is in my inbox, in plain text.

It doesn't matter how you spin the verbiage. It's all just as bad.

Being accurate is not spinning. Accuracy matters, especially in matters of security. It's really not too much to ask for security alarmists to make precise claims.

Would something like this satisfy you:

The system provides functionality for (password reset via email|sending plaintext password reminder emails|other password-based credential recovery|other delegation or retention of password-based credentials) which strongly suggests that an attacker who succeeded in (cross site scripting (XSS)|cross site request forgery (XSRF)|obtaining production server access|obtaining production database access|obtaining back-up meda|observeing network traffic|actively injecting network traffic) would then be subsequently capable of (logging into this site with a targeted user's password-based credentials|mounting on-line attacks against (a specific user's|all users') password-based credentials|mounting (dictionary|non-dictionary) off-line brute-force attacks against (a specific user's|all users') password-based credentials)|passive decryption attacks|active man-in-the-middile attacks) (with little or no work factor).

This (is|is not) recommended for (urgent) remediation. It (is likely|is not) sufficient to meet Payment Card Industry (PCI) standards or other adequate standards of care in the industry.

Check all that apply.

Also see http://cwe.mitre.org/data/definitions/719.html , for example http://capec.mitre.org/data/definitions/55.html .

Websites sending passwords in email should be alarming. You are trying to spin it as not necessarily alarming, which is false.

ciphertext + key = plaintext

I will agree with you, however, that this site is being a bit sloppy with its claims and I am going along with it because it suits my purposes (i.e., errs on the side of being conservative). But this is how security needs to work. Those claiming a system is secure should usually end up with a healthy burden of proof, whereas those claiming it's probably not should be listened to carefully.

By being vague about their claims, they are also being unclear on what should be done to fix the issue. Maybe in some cases, the offending websites even feel they don't need to do anything. I can already imagine some reactions:

- "I'm not storing the password in plain text, I'm hashing it after sending the email confirmation"

- "I'm not storing it in plain text, I'm encrypting it."

And of course, they would entirely miss the point that the real issue is that they are sending the password by email.

In other contexts of society it's perfectly reasonable (if not expected) to point out "offenders" (those who are increasing risk of harm to the public) without being obligated to at the same time to educate and reform the offender.

Just to be sure, I had a look at the first 20 websites - 50% of them are password reminders, the rest are registration confirmation emails so it's not the majority of them.

In any case, sending a password by email is always bad, no doubt about it, but my point is that they claim these websites store passwords as plain text when, half of the time, they don't actually know. Although this is a useful website, they lose a bit in credibility by being more sensationalist than they need to be.

You're entirely correct; an outsider cannot determine whether a password is stored in encrypted format or not.

I agree that sending passwords by email is a bad idea, but I also believe that the folks behind this site should learn what it means to say "website storing a password in plain text" (from their about page). They're right, but for the wrong reasons.

If at some later time you can click a button that says "I forgot my password", and they email you the plain text password, then we know that they have stored the plain text password.

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.

For the purpose of getting your password, reversible encryption means the same as plain-text.

Sending passwords in plain-text over email is bad enough in itself, and it also tells a lot about how they think about plain-text passwords in general.

I like the idea of this site, but found it very frustrating trying to look at the list of offending web sites.

With a little help of Python and the Tumblr API, here's a (dirty) list of the domains: http://paste.debian.net/222440/

Mind sharing the code? :)

It's ugly because it was hacked on the (ipython) REPL, but here it is:

  import requests, re, json
  get_captions = lambda content: [post['caption'] for post in content['response']['posts'] if 'caption' in post]
  get_domains = lambda captions: map(lambda caption: re.sub('<.*?>', '', caption.split('</p>')[0]), captions)

  def process(url):
    offset = 0
    domains = []
    while True:
      resp = requests.get(url.format(offset))
      if resp.status_code == 404:
        return domains
      domains.extend(get_domains(get_captions(json.loads(resp.content))))
      offset += 20

  
  domains = process('http://api.tumblr.com/v2/blog/plaintextoffenders.com/posts?notes_info=true&api_key=<mykey>&offset={0}')
  with open('/tmp/domains', 'w') as dfile:
    dfile.write('\n'.join(domains))

Yeah... We're working on a "proper" site (with proper API). It will be up soon, but it's taking its time :(

Apparently, George Mason University is still on the list... two years after I sent them multiple emails and phone calls complaining about such a big security issue. It's kind of sad that you can't even depend on educational institutions to follow the security guidelines they probably teach to hundreds of students (even if that part of their website was done by a contractor).

My site would fall under this and I use two layer sha-2 512 keys with unique salts... just because I send you one email does not mean I know your password (and for that matter somehow you have to be given an initial password in a lot of systems)

I'm unclear what you mean when you say "and I use two layer sha-2 512 keys with unique salts".

The Plain-Text Offenders site is concerned with web sites that can email you back your original password in plain text. Personally, I'd be most concerned when these emails are in response to an "I forgot my password" request. (Initial registration emails that send you back your plaintext password are dumb, but don't necessarily indicate that the site operator can reconstruct your plaintext password.)

If you are physically incapable of reconstructing the user's plaintext password and emailing it back to them then I'd say you're in good shape. If you have enough information to reconstruct the plaintext password then you're doing it wrong.

Does that mean that if/when an attacker uses a SQL injection vulnerability to obtain the contents of your database, will he then have a password equivalent that allows him to login as the users?

Will it enable him to mount brute-force attacks against the users' plaintext passwords?

> Does that mean that if/when an attacker uses a SQL injection vulnerability to obtain the contents of your database,

More pedantry: if you have a decent RDBMS like Postgres and connect to the DB always as some user A (using a Pg function with SECURITY DEFINER defined by a superuser to compare passwords with a delay, hashed or not) and use column-level permissions that disallow access to the password (or hash) column to non-superusers, they can sql inject all they want (any attempt to dump/select the password column will fail, unless they also manage to reconnect to the database as superuser).

I like RDBMS security (and I think it needs to be employed more frequently), but there's still no valid reason to ever store a plaintext (or plaintext-equivalent) password. Storing something toxic in a "safe" way doesn't make what's being stored any less toxic. The effort to create and maintain a "secure" one-off credential storage system seems like a waste given the availability of well-tested, accepted methods of credential hashing and storage.

> The effort to create and maintain a "secure" one-off credential storage system seems like a waste given the availability of well-tested, accepted methods of credential hashing and storage.

I disagree, because what seems safe today might be unsafe tomorrow or in 10 years. Does anyone still remember Unix versions without a shadow passwd file? I do ... But why do we use that even today when modern Linux installations use SHA variants by default?

Because 50% of typical users will choose one of the top 10,000 most-common passwords and no practical amount of work factor will save them if the hashes become known.

Consequently, DB column permissions are also worth it because they hide the hashes, while such people are not protected at all by current hashing schemes.

The Postgres function written to compare passwords/hashes can also limit the number of checks per time unit to prevent brute-forcing.

People keep using this word 'pedantry'.

I think I posed a very real-world and relevant concrete scenario with considerations that are usually worth thinking about.

You should never be able to retrieve the original password.

And why use a custom scheme when there's quite a few very good methods like bcrypt et al that we mention on the website?

Reply on news.ycombinator.com