Intentional Privacy

I had an interesting experience last week (my life seems to be full of them!). I signed up to take a class that purported to give me a better understanding of what I was looking for in a career.

The first day of class the instructor gave us the URL for an application that he had developed to collect a considerable amount of information about each of us: likes, desires, Myers-Briggs profile, and results from other assessment tests. During the class break, I asked him why the application was not using HTTPS. He said it did, but it used a referrer. I looked at the code of the web site. Hmm, not that I could see.

When I got home, I loaded up Wireshark so I could watch the interaction of the packets with the application. The application definitely did not use HTTPS. I emailed the instructor. Oh, he said, there was a mistake in the documentation, and he gave me the “real” secure URL.

Ok, so this application is sending his clients’ first and last names, email addresses, passwords, and usernames in clear text across the Internet. Not a big deal, you say?

It is a big deal, because many people use the same usernames and passwords on their accounts around the Web. Then add in their email address and their personal information is owned by anyone sniffing packets on any unsecured network they might be using, such as an unsecured wireless network in a coffee shop, an apartment building, a dorm room ….

So, next—because I now had their “secure” website URL—I checked their website against http://www.netcraft.com/, https://www.ssllabs.com/ssltest/, and some other sites—all public information. According to these tests, the application was running Apache version 2.2.22, which was released on January 31, 2012, WordPress 3.6.1 (released on September 11, 2013), as well as PHP 5.2.17 (released on January 6, 2011). It is never a good idea to run old software versions, but old WordPress versions are notoriously insecure.

Please note: I am not recommending either of these websites or their products; I merely used them as a method to find information about the application I was examining.

Not only that, but the app used SSL2 and SSL3, so the encryption technology is archaic. Qualys SSL Labs gave the app an “F” for their encryption, and that was after he gave me the HTTPS address.

(“It was harder to implement the security than we thought it would be,” he said.)

Although I did not find out the Linux version running on the web server, based on my previous findings—which I confirmed with the application owner—I would be willing to bet that the operating system was also not current.

So, then I tried creating a profile. I made up first and last names, user name, and a test email from example.net (https://www.advomatic.com/blog/what-to-use-for-test-email-addresses). I tried “test” for a password, which worked. So, the app does not test for password complexity or length.

He asked me on the second day of class if I now felt more comfortable about entering my information in his application since it was using HTTPS. I said no; I said that his application was so insecure that it was embarrassing, that it appeared to me that they had completely disregarded any considerations about securely coding an application.

He said that they never considered the necessity of securing someone’s information because they were not collecting credit card information.

I said that with the amount of data they collected, a thief could impersonate someone easily. I reminded him that some people use the same usernames and passwords for several accounts, and with that information and an email account, any hijacker was in business.

Then he said that he was depending on someone he trusted to write the code securely.

Although I believe in trust, if it were my application, I would verify any claims of security.

I told him he was lucky someone had not hacked his website to serve up malware. I said that I was not an application penetration tester, but that I could hack his website and own his database in less than 24 hours. I said the only reason it would take me that long is because I would have to read up on how to do it.

I told him I would never feel comfortable entering my information in his application because of the breach of trust between his application and his users. I said that while most people would not care even if I explained why they should care, I have to care. It is my job. If my information was stolen because I entered it in an application that I knew was insecure, I could never work in information security again.

So, what should you look for before you enter your information in an application?

1. Does the web site use HTTPS? HTTPS stands for Hypertext Transfer Protocol Secure; what that means is that the connection between you and the server is encrypted. If you cannot tell because the HTTPS part of the address is not showing, copy the web address into Notepad or Word, and look for HTTPS at the beginning of the address.
2. Netcraft.com –  gives some basic information about the website you’re checking. You do not need to install their toolbar, just put the website name into the box below “What’s that site running?” about midway down the right-hand side.
3.  Qualys SSL Labs tests the encryption (often known as SSL) configuration of a web server. I do not put my information in any web site that is not at least a “C.”
4. Another thing you should be concerned about is a site that serves up malware: Here are some sites that check for malware:

→ http://google.com/safebrowsing/diagnostic?site=<site name here>

→ http://hosts-file.net/ — be sure to read their site classifications here

→ http://safeweb.norton.com/

5. Do not enter any personal information in a site when using an insecure Wi-Fi connection, such as at a coffee shop or a hotel, just in case the site doesn’t have everything secured on its pages.