Encryption

In October 2010, Firesheep was publicly released. While the subject of encryption was not new at that time, Firesheep created a user interface that helped illustrate the problem. It took something that, to many of us, was abstract and made it real.

While the release of Firesheep helped raise awareness about the need for encryption, the lessons of Firesheep have yet to be fully realized. The technical shortcomings that Firesheep exploited -- a lack of encryption, and/or not requiring encryption, and not requiring that authentication cookies are sent only via an encrypted connection -- are still present on the web in large numbers. While creating secure software requires more than encryption, using encryption is a very accessible first step.

In 2016, sites that collect usernames and passwords need to be protected via encryption. This includes the registration process, login URL, and all areas accessible to logged-in users. If a person types in a URL that isn't encrypted, the site should redirect to an encrypted connection. If the site uses an authentication token that is stored via a cookie, that cookie should only be sent via an encrypted connection. Ideally, more sites will begin using HTTP Strict Transport Security (HSTS).

Checking for encryption on a website is easy to do for anyone who uses the web. In your browser's address bar, look at the URL, or site address. In very general terms, if the address of the site starts with "https://" then the website is using encryption. If you don't see "https://" or a green lock icon, then the website is not using encryption or has issues with encryption.

Image

A browser address bar showing an encrypted connection

For people who want a more technical look at different levels of encryption, head over to Observatory from Mozilla. Observatory allows people to enter the URL of a website and get a sense of how the site has set up basic security elements, including encryption.

For people who want to look at how their authentication with a particular website is protected, our information security primer has a chapter on checking the security of authentication tokens. For a visual demonstration of how an unprotected authentication token can lead to Very Bad Things, start this video at 30 seconds to get an overview, and then jump to 4:20 for a more detailed illustration.

If you are a vendor reading this post, you should be running these tests on all your services. They should be incorporated into your regular QA testing. Building secure software means you're paying more attention to detail, which generally correlates with building better software. We all want this. A competent developer can automate a range of focused checks so they're completed in seconds.

For people who are skeptical about the use of encryption, please don't take my word for it. This change is coming industry-wide, slowly but inevitably:

• Apple will be requiring encryption on all apps in its App Store.
• Google already prioritizes encrypted sites in its search results.
• Chrome will be ramping up warnings about sites that do not use encryption.
• Firefox already shows mixed content warnings on encrypted pages that attempt to serve elements that are unencrypted.
• Wired did some interesting work documenting their transition to implementing encryption.
• For people interested in seeing a site that collects a high-level overview of popular sites and their use of encryption, head over to HTTPSWatch.

The good news is that the clock is ticking on sites being able to avoid using encryption. The bad news is that a significant number of sites that collect user information still do not use encryption.

In our work running privacy evaluations, we have seen a significant number of sites that do not protect login information with encryption. However, we were discovering this on a case-by-case basis; while we saw lack of encryption relatively frequently, we didn't know if our experience and results were skewing high or low relative to general practice. We discover a lack of encryption as part of our triage process, and when we saw a lack of encryption, that in turn triggered a series of tests to verify the extent of the issue. While this process is informative and a necessary part of our evaluation process, doing this on a case-by-case basis is not as efficient as it could be.

In an effort to get a clear sense of the scope of the issue, we decided to automate a step in the process. It's one thing to say, "We see a lot of sites that don't use encryption." It's another to be able to say, "We surveyed over a thousand sites as part of an initial effort to document patterns of encryption use."

At the risk of stating the obvious, we'd much rather be able to make the second statement. To do this, we tested over 1,200 services for their use of encryption. Gathering the initial data set was time-consuming, as we needed to collect the login URLs to make sure we were testing the exact location where users entered their personal information. The results are interesting and allow us to make more precise observations about the use of encryption across the education technology landscape. It also allows us to focus our evaluation work in a more efficient way.

We are still going through the data set and running some additional verification on our results, but even these preliminary results have helped us get a sense of how encryption is -- and isn't -- being used within education technology. Over the next few weeks, we will be sharing some of these observations in this space.

Image credit: Untitled from Delaney Turner, released under a Creative Commons Attribution 2.0 license