The other day, I heard that some classes at our school were considering using an online service to share updates and photos about what happens at school during the day. I took a look at the site and the first thing I noticed was that the site was not using SSL at all. In fact, the site’s developers seemed to have spent more effort on protecting against disclosing parents’ email addresses to each other than to protecting against unauthorized access by outsiders.
Uh oh. This means that the site transmits usernames and passwords, links to photos, comments, and personal information unencrypted – visible to anyone who is able to see the network traffic. This also means the site is vulnerable to session hijacking, where an attacker can take full control of a victim’s account. More on that in an upcoming post.
I sent a note to the company and got a quick (and a bit indignant) response from the CEO, saying that SSL was coming within days but had not been implemented yet because the site was not collecting any “highly sensitive” information such as credit cards or home addresses, and thus did not need SSL.
Really? The site collects students’ first and last names, parent emails, and allows photos to be uploaded and shared. Though COPPA does not apply here, I view the list of COPPA-protected personal information as one good yardstick for what sorts of student information requires secure handling, and all of these are on that list.
However, there is no real standard for data security in educational technology. Laws such as COPPA and California’s SOPIPA require “reasonable” security, but do not define what “reasonable security” is. The edtech industry has not come forward with a meaningful standard. Without a standard, edtech implementors don’t have a clear target to aim for and educators and parents don’t have visibility in to the security practices of the companies that collect their children’s information.
In upcoming posts I’ll share thoughts on what the standards might look like and examples of why it’s important to have them.
OWASP (Open Web Application Security Project) has lots of information about securing web applications. Here’s a link to their Transport Layer Security cheat-sheet, which includes the following about using SSL/TLS for login and authenticated pages.
Rule – Use TLS for All Login Pages and All Authenticated Pages
The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the “login landing page”, must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user’s credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user’s authenticated session.