Our follow-up survey on encrypting logins shows moderate improvements.
In early March of 2017, we ran some basic tests that measure support for encryption on 1,215 logins used by 1,121 vendors for technology used in schools and by youth. This was a follow-up from work we began in October 2016.
Our results indicate that there has been measured improvement between October 2016 and March 2017. In October 2016, 52 percent of the 1,221 login URLs we surveyed required encryption, 25 percent did not support encryption at all, and an additional 20 percent did not require encryption. As of March 2017, 56.21 percent require encryption, 22.8 percent do not support encryption at all, and 18.11 percent support, but do not require, encryption. The results indicate a modest increase (4 percent) in the number of sites that require encryption at login and an ever larger decrease (13 percent) in the number of sites that fail to fully support encryption. There has been progress, even if 40 percent of education technology websites surveyed still do not enforce encryption.
As we observed in our original review, we are still seeing lack of support for encryption from vendors of all sizes, from small firms to early and middle-stage start-ups to privately held companies that have been used for years to enterprise vendors that are used in thousands of districts with millions of learners.
Our initial write-up describes our methodology, what this survey covers, and what is outside the scope of this survey. This methodology has not changed between the two surveys and provides important context for this work. As we describe in the first write-up, encryption is a basic requirement for applications that collect usernames, passwords, and other personally identifiable information. Using encryption to protect data in transit is widely recognized as a best practice and, in some cases, even a legal requirement to satisfy a "reasonable" standard of security.
As noted in our original write-up, we will continue to conduct this survey on a regular basis and document the trends we observe in the results. Support for encryption is one proxy for safe and secure practices across the educational technology industry.
A. Process
This survey performed three actions at each login location:
- Sent an https request to the login URL and checked the http status code (i.e., asked whether https was supported);
- sent an http request to access the login URL to see whether the site redirected to https (i.e., asked whether https was required);
- and inspected the site header for the presence of HTTP Strict Transport Security (HSTS) directives.
The results of the survey are an indicator -- not an absolute measure -- of how sites encrypt information passed during login. They provide an accurate representation of trends across the sites we surveyed, but an authoritative statement about any specific site requires a more detailed evaluation.
In evaluating the survey results, we paid specific attention to sites that met the following criteria:
- A. supported and required encryption and used HSTS directives in their headers;
- B. both supported and required encryption but didn't use HSTS directives in their headers;
- C. supported encryption but didn't require it;
- D. didn't use encryption at all.
Either "A" or "B" were considered passing.
B. Results
Our results are reported in three sections: Status Codes, Support for Encryption, and Support for HTTP Strict Transport Security (HSTS).
B1. Status Codes
The http status codes returned by an application provide an initial indication of how a service supports encryption. A status code of 200 is generally the most straightforward. A status of 0 is an indication of an issue with encryption and/or how a server is set up. The meanings of other status codes can vary based on the service and are useful as indicators to consider as part of a complete, non-automated evaluation. While status codes are not a comprehensive indicator on their own, they help provide an initial picture of if, or how, the service supports encryption. Often, a response code of "4xx" or "5xx" indicates issues such as an expired SSL certificate or problems with server configuration.
Results from March 2017:
When we compare them with the results from October 2016, we see moderate improvements.
The overall percentage of 0 responses has dropped, and the overall rate of 200 responses has increased. As rates of support for encryption increase, we should expect to see these trends continue.
As we noted in our original survey, a manual review of sites that return a 3xx code continues to indicate that, in some cases, the vendor is making an explicit choice to redirect a request for an encrypted connection to an unencrypted connection, which is precisely the opposite of what should happen. The good news is that the number of sites with these issues is decreasing; the bad news is that these issues still exist. The results of this survey continue to suggest that, in some cases, testing for the presence or absence of encryption can be used to find indications of other issues in addition to issues related to encryption. For people who want to look more deeply at any individual site, we strongly recommend using Observatory.
B2. Support for Encryption
In our follow-up survey, we saw moderate improvement in support for encryption:
- 56.21 percent of sites require encryption (up from 51.8 percent);
- 18.11 percent of sites support, but do not require, encryption (down from 19.9 percent);
- 22.8 percent of sites do not support encryption (down from 25.4 percent);
- and 2.88 percent of sites need additional review (virtually unchanged from 2.88 percent).
Between October 2016 and March 2017, we observed a 4.4 percent improvement in the number of sites that encrypt their logins. However, even with this improvement, over 40 percent of the sites we surveyed do not support encryption at login. It's also worth noting here that our survey -- by design -- didn't examine the level of encryption, so -- potentially -- a site could have passed our survey and be using outdated methods of encryption. We designed this intentionally low bar for this survey to avoid the more nuanced conversations around what constitutes "safe" encryption, but we need to highlight that the bar we are setting here tilts low.
B3. Support for HTTP Strict Transport Security (HSTS)
We also surveyed how many sites used HSTS directives in their headers. The percentage of sites using HSTS increased slightly, from 13.6 percent in October 2016 to 13.91 percent in March 2017. However, because the number of sites supporting encryption increased, the percentage of HSTS use among sites that support encryption fell slightly, from 26.3 percent in October 2016 to 24.74 percent in March 2017. One possible explanation for this is that, as vendors update their security, they are focusing on supporting encryption first and leaving other security-related details such as HSTS for later. As we continue to track support for encryption, we will watch for trends in supporting HSTS directives.
C. Conclusions
Between October 2016 and March 2017, we observed a moderate increase in support for encryption. As we discussed in the fall of 2016, encryption is a basic step that sites need to take. If a site does not support encryption, many schools and districts won't even consider using it. We strongly encourage people to check how sites support encryption. If you're a vendor, developer, or other interested party, please use our freely available toolkit.
The need for strong encryption to protect information passed to a site is broadly accepted. Both Firefox and Chrome are giving stronger warnings when sites don't support encryption, and the use of strong encryption of data in transit is widely recognized as part of what constitutes "reasonable security." Ideally, when we ran these tests, we would see failure rates of less that 5 percent, compared with the 40 percent we currently observe.
We also remain committed to highlighting good practice. Over the next few days, we will publish a list of websites that require encryption as we defined in this survey. When we publish the list of websites that require encryption, we will define clearly what the list means and what it doesn't mean. We will also include a mechanism for people to recommend a site to be included on the list. Stay tuned for our announcement, with additional details, coming later this week.
After we ran the first survey in October 2016, we faced a lot of pressure to publish a list of sites that did not pass this survey. While a lack of support for encryption is publicly visible, we don't see our role in supporting better privacy and security standards as calling people out. We talk with a lot of people working in education and technology, and the overwhelming majority want to do the right thing for the right reasons. At this point in time, based on our observations, a blacklist would be counterproductive to progress. We strongly urge vendors to review how their sites support encryption. We strongly urge people using sites to examine how these sites support encryption. Change can be difficult, but the transition to using encryption to protect educational data is essential and overdue.
