Student Privacy Pledge Signatories With Unencrypted Logins

On February 11th Natasha Singer reported in the NY Times that many companies that collect student information had signed the Student Privacy Pledge, while having logins that were not encrypted, exposing usernames and passwords — and the associated accounts — to unauthorized access.   The Student Privacy Pledge signatories promise to: (highlights are mine)

Maintain a comprehensive security program that is reasonably designed to protect the security, privacy, confidentiality, and integrity of student personal information against risks – such as unauthorized access or use, or unintended or inappropriate disclosure – through the use of administrative, technological, and physical safeguards appropriate to the sensitivity of the information.

The OWASP guideline and widely accepted best practice is to encrypt login forms, transfer of credentials and all subsequent authenticated transfers during the login session.  (This one of the things that SSL/HTTPS does).   It is one of the most elementary security measures a web service can implement.   Any form of student information is sensitive enough to be reasonably afforded this basic level of protection.

Today, I counted eight Student Privacy Pledge signatories that appear to hold personal information about students, yet do not encrypt the transmission of their users’ login credentials.  Seven of them had already signed when the story ran on February 11th and have not made changes, and one (Cambium Learning Group, covered in earlier posts) signed the pledge while having unencrypted logins, among many other security problems.

My method was the following:

  1. Visit the website of the signatory
  2. Decide if it appears to collect student information (has a student login, for example)
  3. If so, do a login attempt and confirm in a proxy that the username and password are sent plain text without encryption

Since I don’t have login accounts for most of these services I did not do further checks about what happens after login.

The sites I observed to still be sending usernames and passwords without encryption were:

[Updated 3/25/15 to show results of doing the same check, after I was contacted by a couple of services letting me know they’d added SSL]

brainhive  [No login encryption on 3/25]

code.org [No login encryption on 3/25]

edgenuity [No login encryption on 3/25]

writerkey [Encrypted login on 3/25]

myon [Encrypted login on 3/25]

orglib [Encrypted login on 3/25]

readorium [Encrypted login on 3/25]

raz-kids (Cambium Learning Group) [Encrypted login on 3/25]

Session cookies

We all know that we need to protect our usernames and passwords.  Session cookies are nearly as valuable to a hacker.  I’ll explain why, and how an end user can check to see if session cookies are being protected properly by a web site.

When we log in to websites we give our usernames and passwords once, then the site “remembers” that we are logged in for the requests that come later, until we log out.   Session cookies are what makes this work.  On the initial login the server returns a “session ID” in a cookie, and this ID is associated with the current login session on the server side.  The browser stores this cookie and sends it with the transactions that follow.  The server recognizes it and uses it to allow access and to return the information associated with that account.

If an intruder gets the session ID he can install it in his browser and “impersonate” the user it belongs to.  Some sites defend against this but in many cases, when the server gets the hacker’s requests it will behave the same way as it would if the account owner had logged in to the site.  Our intruder now has full control of the account and can browse its pages at will.  This type of attack is called “session hijacking”.  To make matters worse, many sites don’t invalidate session cookies when a user logs out.  In that case logging out will not stop someone from accessing your account with a stolen cookie.

In May, 2013 I worked with Dana Liebelson on a story in Mother Jones about lack of SSL on popular team sharing sites.  As part of that we made a video demonstrating how a hacker could use a free software program called CookieCadger to automate the process of stealing session cookies and using them to access other users’ accounts. You can watch that here.  This problem was also covered for education-related web sites by Natasha Singer in NY Times in June of 2013.  Before CookieCadger, a browser extension called Firesheep first called widespread attention to the problem.

Now that we see why session cookies are important, how can an end user check to see how well they are protected by a web site?  The first thing is to know how to look at them. There are a number of browser extensions that allow users to examine cookies, such as EditThisCookie for Chrome.  Session IDs have different names on different sites but usually the name indicates it’s a session cookie – ‘sessid’, ‘phpsessid’, ‘sid’ are some examples.  Here are some other things you can look for.

  1. Check whether the site is using SSL/https the whole time you’re logged in.  The first step to protecting the session cookies is encrypting them as they travel between your browser and the website. A URL starting with ‘https’ is your sign that the site is using encryption.  Some sites will use https for the page that collects the username and password and then switch back to http. THIS IS NOT ENOUGH! If the site switches back to http it’s sending your session cookies back and forth without encryption, ready to be stolen by anyone who can monitor the network traffic.  (Such as an open wifi network).  If the site is not using https at all, this is even worse – your username and password are also being sent in a way that others can see it.
  2. Check to see if the session cookie’s flags are set correctly.  Cookies have security-related flags that can be set by the website.  The ‘secure’ flag prevents the cookie from being sent over an unencrypted connection. For a site that uses https, this protects against unintended transmission over http.  A common example of this is when a user enters the site’s name in a new tab while already logged in — browsers typically default to http, and if the secure flag is not set, cookies will be sent and exposed over http during the redirect from http to https.  The ‘httpOnly’ flag prevents the cookie from being read by a script embedded in the page. This protects against an attack called XSS or Cross-Site Scripting, that can read a session cookie and send it to an attacker.  There are occasions when a website’s implementation prevents setting these flags but you’re always safer if they are set (and most of the time it’s an oversight if they are not).  Here’s an example of a google session ID that has both flags set.                                                                                         Screen Shot 2014-11-25 at 3.50.17 PM
  3. Look for the session ID in the url.  A URL can be logged in a server log or browser history even if sent with encryption.  If the website puts your session ID in the URL, it gets stored with the URL.  From there it could be read and used by an attacker to gain access to your account.