In this post I’ll discuss my observations of the security practices of IXL.com. IXL is a signatory of the Student Privacy Pledge. The Student Privacy Pledge website does not publish the dates that companies signed the pledge but I observed that IXL was added to the Student Privacy Pledge signatory page after February 11th.
Overview of the service
IXL.com is a math and English “adaptive learning” web service that also offers iOS and Android apps. Students play educational ‘games’ and extensive metrics are compiled to assess the students’ level and progress in math and english.
Summary of observations
The web site is served almost exclusively in HTTP. Usernames and passwords are sent with an HTTPS POST but the rest of the traffic is HTTP. Though the login credentials are protected, this still poses a significant risk of session hijack and data snooping attacks which could expose students’ names, affiliations and their assessment metrics as collected by the service. The risk is heightened by the fact that the teacher account has a roster page that displays the names and current passwords of all the students in a given class. This roster is sent across the network without encryption if a teacher accesses it, and could be also be viewed by an attacker who has hijacked a teacher login session by sniffing the teacher’s authentication cookies off the network.
The mobile apps appear to have only a student-facing functionality. The lack of encryption for all but the the transaction that posts the username and password is consistent with that of the web app.
Authentication controls were in place to prevent remote attacks through enumeration of student or teacher IDs. Authentication tokens were invalidated when a user logged out of the session.
Notification and response
I notified the company of these observations on March 5th. They got back to me a couple of days ago and have been very responsive since then. I am including the company’s response to the observations I’d sent, with their permission:
As you noted, HTTPS is currently only used on IXL to protect login credentials and credit card data. Any risk created by using HTTP on the rest of the site is mitigated by the fact that, while technically possible, it is difficult for a determined hacker to “sniff” a user’s cookie value off of a modern network and navigate as if signed in as that user. However, we have been working to move our entire site over to HTTPS to eliminate this vulnerability. Though the vast majority of sites still use HTTP to serve up their content, we want to take every step we can to keep our site and our users secure.
Student passwords are intentionally stored in a reversible format to allow instructors to view them from their rosters. This allows instructors to retrieve them without making changes but, as you mentioned, makes them less secure when transmitted over HTTP. As we move to serve all IXL content over HTTPS, this risk will be eliminated, but it is worth noting that passwords for instructor-created students are the only passwords stored this way. Passwords for teachers, administrators, and parents who purchase their own accounts are all securely hashed when stored.
Thank you for pointing out that user credentials are included in the URL of the POST transaction when signing in on our Android app. Our engineering team has written a fix to remove this vulnerability, and we will patch it in once the update has been thoroughly tested by our Quality Assurance team.
I will add three thoughts of my own:
Sniffing cookies: For a determined hacker, sniffing cookies from a modern network and navigating a site as another user is not difficult at all. In 2011 a firefox plugin called “Firesheep” automated the process. Today, a free program called “Cookie Cadger” automates the process and can be used with a stock Macbook Pro to execute this attack, called “Session Hijacking”. In 2013 I worked on a story with Dana Liebelson of Mother Jones describing the problem and the short embedded video below, from that article, shows a demonstration.
The vast majority of sites still use HTTP to serve content: Certainly true but it’s a flawed comparison. The vast majority of sites don’t have usernames and passwords to create authenticated sessions, and don’t collect personal information from students. The correct general use comparison here is social media or web-email sites, which typically do use encryption (well, since Firesheep anyway). The OWASP Transport Security Layer (TLS) cheat sheet includes a rule to use TLS (another name for SSL) for all login pages and all authenticated pages.
Plaintext passwords: Storing passwords in reversible formats is clearly counter to best practices for general use and transmitting them unencrypted makes it worse. But, coupled with SSL perhaps it could be considered as a defined exception for classroom apps, so long as SSL+(HSTS required and secure flag if load balancers allow it) was there, and if personal information collected by the service was restricted to a less-sensitive subset. There is a practical reason behind it in this case. This is the sort of thing that might be in an edtech-specific security standard, if there was consensus that it is acceptable practice in defined circumstances.
I have access to my child’s paid student account, and also set up demo teacher and student accounts. Screen shots in this document are from the demo teacher and student accounts but all of the student account observations have been confirmed in the paid student account.
Screen shots of student assessment reports are shown below. In my demo accounts the data is sparse but the categories of data can be seen in these captures.
Lack of encryption
The login form is served with HTTP, as are authenticated sessions. The username and password are sent with an HTTPS POST transaction. Though the login credentials are protected at login, this still poses a significant risk of session hijack and data snooping attacks which could expose students’ names, affiliations and their assessment metrics collected and compiled by the service. (See my previous post on session cookies to read more about the risk of session hijacks posed by transmitting session cookies without encryption.)
Screen shots below show the login form and authenticated session, with URL indicating HTTP. The session shown is a student account, but the teacher account I set up had the same behavior, as I will show later in the post.
A sample of the transactions is shown below. In the lower pane, the HTTPS POST of credentials and some HTTP responses from ixl.com are shown. The transaction selected in the proxy shows an HTTP GET, with user cookies sent without encryption.
Transmission of plain text passwords without encryption
From a teacher account, a the ‘roster’ page loads a class roster and displays each student’s current password in plain text. This reveals that the passwords are not hashed at the server, and since the transfer is HTTP, it poses a risk that an attacker could obtain these passwords through direct observation of traffic or session hijack of a teacher account. An additional observation is that encrypting usernames and passwords when users log in shows a recognition by the company that this information should be protected, but sending entire class rosters with plaintext passwords is a much larger risk than exposing a single user’s credentials.
The screen shots below show the class roster page in the browser, and the class roster data in the proxy
Notice also that the usernames contain the full first and last names of the students. These are assigned by the service when the classroom is set up so there is no option for the teacher to make usernames that don’t include the students’ full names.
Mobile app transmits username and password in URL
When a user logs in from the mobile app, the username and password are included in the URL of the POST transaction used to authenticate the session. Though this information is encrypted in transit, best practice is to send all sensitive data in the HTTP message body, not in the URL.
This is documented in OWASP Application Security Verification Standard requirement 9.3, which is part of the lowest specified set of verification requirements, (Opportunistic).
The OWASP Application Security FAQ has more information. Consider that since the student usernames contain their full first and last names, logging as described below would capture the usernames and passwords, and the full names of the students.
The proxy log below shows the HTTPS POST with credentials in URL, and that transactions after authentication are sent with HTTP, in a manner similar to the behavior of the web app.
(Updated after posting to reorder the sections – no content changed)