IXL Security Observations

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.

Testing notes

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.

Detailed Observations

Sample reports
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.

Student account

Screen Shot 2015-03-03 at 12.42.16 AM

Screen Shot 2015-03-03 at 12.43.39 AM

Teacher Account

Screen Shot 2015-03-03 at 12.50.30 AM

Screen Shot 2015-03-03 at 12.52.02 AM

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.

Screen Shot 2015-03-03 at 12.54.15 AM

Screen Shot 2015-03-03 at 12.56.24 AM

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.

Screen Shot 2015-03-03 at 1.06.57 AM

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

Screen Shot 2015-03-03 at 1.17.06 AM

Screen Shot 2015-03-03 at 1.21.27 AM

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).

Screen Shot 2015-03-08 at 11.04.55 PM

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.

Screen Shot 2015-03-12 at 10.06.42 AM

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.

Screen Shot 2015-03-03 at 1.37.59 AM

(Updated after posting to reorder the sections – no content changed)

Raz-Kids email to teachers

Today Raz-kids sent an email to its updates@learninga-z.com mailer list for users of its service.  The full text of the email is at the end of this post.  In this post I’ll address statements that are counter to my observations, with screen shots showing why.

“SSL encryption,…has always been used on Raz-Kids’ teacher-facing accounts”

I have proxy session files and screen shots taken as recently as March 4th that show teacher credentials sent without SSL, and authenticated teacher account sessions served without SSL.  The current SSL certificate on http://www.raz-kids.com was issued on February 11th of this year.  I observed certificate errors flagged by the browser when attempting to force HTTPS/SSL on http://www.raz-kids.com during January of this year.   The certificate information with validity date is shown below.

Screen Shot 2015-03-06 at 4.59.22 PM

My March 4th blog post on raz-kids security problems includes a screen shot of a teacher login page, including the code for the login form, served without SSL, and the credentials sent without SSL.  It was captured on March 4th and I’ve included it again here. The ‘world’ icon on the URL bar shows that the page including the code for the login form was served with http.

Screen Shot 2015-03-06 at 4.23.41 PM

Here is a new screenshot taken today. Notice that today the lock icon indicates this page was served with https.  I confirmed that the credentials are posted with https today as well and that is also a change from yesterday.

Screen Shot 2015-03-06 at 4.22.21 PM

The following screenshot was captured on March 2 and shows a logged-in teacher session served with http.

Screen Shot 2015-03-07 at 7.14.58 PM

A copy of the page cached by Google yesterday shows that as recently as yesterday the link embedded in the teacher login button was http, meaning at a minimum that http was the default.  This is consistent with my observations.

Screen Shot 2015-03-06 at 9.02.25 PM

Older cached copies of this same page on the Wayback Machine show the same thing.

“SSL encryption.. has now been added to the student-facing side of Raz‑Kids and its mobile applications. It is recommended that users of a previous mobile app download the latest update to utilize this enhancement.”

Correct but there is one important detail. The older version of the app still works, and users who have not updated still transmit full class rosters with plain text passwords without encryption every time a student logs in.  The underlying interface can also still be exploited from a browser, using a teacher username to extract the names and passwords of an entire class. Raz-kids could disable this interface and force users to upgrade the apps but thus far has not done so.  Details of this were included in my March 4th post and a screen shot of the response including student passwords in plain text is shown below. This screen shot was captured on March 2 but I have confirmed today that this interface is still active.

Screen Shot 2015-03-04 at 1.19.05 AM

“This additional encryption provides a comparable level of security found on various eCommerce sites.”

e-Commerce sites must adhere to the Payment Card Industry Data Security Spec (PCIDSS), a rigorous set of security requirements, including around encryption and overall transport layer security.  As I reported yesterday, the Qualys SSLLABs SSL checker gives http://www.raz-kids.com a score of ‘F’ because of an unpatched vulnerability to POODLE TLS.  (You can check the current status here.).  Though not directly related to encryption, there are numerous other security flaws with the raz-kids site that would cause a failed PCIDSS audit.

A screen shot of the Qualys SSLLABS report is shown below

Screen Shot 2015-03-06 at 4.47.55 PM

“An inaccuracy was recently discovered in Learning A‑Z’s Student Data Security and Confidentiality Statement. Despite what was stated there, Learning A‑Z does not require teachers or parents to add a student’s first name, last name, or identification number. All that is required is a student login handle. This statement has been revised.”

My observation is that student accounts set up prior to February 11 do not have such a “login handle” and use the students full names as the “login handle”, or username.  This seems to indicate that the change noted to the Student Data Security and Confidentiality Statement corresponds to a material change in the service.

On February 11th and before, I observed that the “Add Student” page had entry fields for First Name and Last Name with no option for “login handle/class chart name” or other identifier for the student other than first name and last name. The screenshot below was taken on February 11th.

Screen Shot 2015-03-06 at 5.05.24 PM

Today the same page looks like this (red boxes are mine).  “Class Chart Name” is the “login handle” referenced in the email.

Screen Shot 2015-03-06 at 5.03.17 PM

Prior to February 11th, it appears that teachers had no option to add a “class chart name”, only a student’s first and last name.  Today I opened an existing teacher trial account and added a new student, “Iwas Addedtoday” with “class chart name” of “iwasadded”.  Here is how the class roster looks. Notice that the new student Iwas has (iwasadded) below the first and last name and that Betsy and Robbie, set up prior to Feb 11th do not.  This situation is hard to explain if the “login handle/class chart name” had always been a required field.

Screen Shot 2015-03-06 at 1.13.22 PM

The “login handle” for each of the two pre-Feb-11th students is in fact the first and last name as shown here. Only the new student has a “login handle” of “iwasadded”. Robbie and Betsy’s login handles are their full names.

Screen Shot 2015-03-06 at 5.14.08 PM

I believe that any teacher using Raz-Kids can confirm this by logging in and going to the Class Roster page under Manage Students.  If a class was set up prior to Feb 11th I expect that the students won’t have “class chart names”, and that there is no way to add one to an existing student.  This seems to show that “class chart name” was not a field, required or otherwise, when the class was created.

“Learning A-Z believes all student data is important and needs to be protected. This includes student voice recordings, reading level information, and student login handles, which Raz‑Kids does collect for educational use.”

Company representatives have publicly stated in the NYTimes that raz-kids doesn’t collect “Sensitive” personal information and on twitter that Raz-Kids “holds no personal information”.   This statement discussing student information collected by Raz-Kids seems to contradict those public statements.

The full text of the mail sent today from Raz-Kids to teachers is below.

Learning A-Z’s Raz-Kids reading product has received even more security enhancements to protect student data. Learning A‑Z’s mission to empower teachers to help students succeed will not be impacted and product functionality will not be compromised.
Privacy and data security are core values of Learning A‑Z. As such, after proactively seeking out and then successfully completing a third-party audit to verify Family Educational Rights and Privacy Act (FERPA) compliance in December 2014, it was found that Cambium Learning and its products “successfully addressed the various applicable FERPA requirements.” The audit did make some suggestions for additional enhancements and those enhancements are detailed below.
Additional enhancements to Raz-Kids and Learning A-Z’s other student-facing technology products include:
Parent access to a student’s Raz-Kids account now requires teacher approval. This preventative step is designed to add additional security to the student account from people posing as parents.
SSL encryption, which has always been used on Raz-Kids’ teacher-facing accounts and Learning A‑Z’s eCommerce site, has now been added to the student-facing side of Raz‑Kids and its mobile applications. This additional encryption provides a comparable level of security found on various eCommerce sites. It is recommended that users of a previous mobile app download the latest updateto utilize this enhancement.
An inaccuracy was recently discovered in Learning A‑Z’s Student Data Security and Confidentiality Statement. Despite what was stated there, Learning A‑Z does not require teachers or parents to add a student’s first name, last name, or identification number. All that is required is a student login handle. This statement has been revised.
Learning A-Z believes all student data is important and needs to be protected. This includes student voice recordings, reading level information, and student login handles, which Raz‑Kids does collect for educational use. Raz‑Kids has never stored or required student email addresses, physical addresses, or Social Security Numbers. Any other student information, like first and last name, is not required, though teachers could choose to add this information to best support their educational objectives.
Learning A-Z will continue to address ever-changing issues brought up by parents and educators. As part of an ongoing security effort, Learning A‑Z and Cambium Learning’s other business units have already signed the Student Data Privacy Pledge recently promulgated by the Future of Privacy Forum and the Software and Information Industry Association.
As the issue of data security and student privacy continues to evolve, Learning A‑Z encourages curious or concerned educators or parents to contact John Jorgenson, SVP, Marketing at any time to learn more(520-232-5070 / john.jorgenson@learninga-z.com).

Update 3/7/15:

I noticed an error in the screen shot from 3/2/15 showing a logged-in teacher session using http.  I have replaced it with a correct screen shot also taken on 3/2/15.

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]

End-user web app test plan results for Raz-Kids

As a follow up to yesterday’s post, I have applied the end-user test plan I’ve posted on this blog to RazKids based on their latest web site and mobile app as of this morning.  Many items on this list need work.

It took me about 30 minutes to complete the “Objective Test” section of the test plan, using a laptop, a browser with cookie editor extension and a free proxy program.   Though I was already familiar with this application, that is typical of the time it takes me to perform these tests on a site I’m seeing for the first time.

Raz-kids and data security

In this post I’ll be describing my recent observations of the data security of the Raz-Kids/LearningA-Z online reading instruction application. These problems were described in a NY Times article by Natasha Singer on February 8th.

Before jumping in, a few words about disclosure:  I first reported lack of SSL to LearningA-Z in October 2013. I got an acknowledgement of my inquiry but no further correspondence from the company.  On Feb 2 of this year I sent the detailed information spelled out below.  I’ve had some contact with the company since then and waited to disclose until now as they worked on fixes.  A month later, a number of serious problems remain open, and the company has left an insecure API open after releasing updated mobile apps that no longer need it to function properly.

As described in my previous post, Raz-kids collects information about students and their reading level and progress.  Some of this is visible from student accounts and all of it is visible from teacher and parent accounts.

My observations in early February included the following problems:

  • No SSL used for teacher, student or parent website access, or with the mobile apps
  • Passwords stored in plain text, not hashed at the server
  • Presenting teacher username to mobile app caused full class roster with plaintext passwords to be transmitted without encryption
    • This interface could also be exercised from the browser
  • Option to set up student accounts with no password required to enter the account
  • Once in a student account, it was possible to register as a parent with no verification needed by the teacher before access was granted to student reading assessment information

Since then, SSL has been added to student accounts but not teacher or parent accounts, teacher approval is now required before parent accounts can access student assessments, and new Android and iOS apps have been released that no longer transmit plain text passwords for an entire class (though this API is still functional and in use by older versions of the apps).

In the remainder of this post I’ll describe details of the problems that remain open.


The student website and latest mobile apps now use SSL to encrypt credentials and data. (More on mobile below).  However the teacher and parent accounts do not.  Since the teacher account has access to many students’ assessment information and voice recordings, and the parent account has access to student assessment information, there is more risk of data exposure from these accounts than from the student accounts that are now encrypted.  The SSL configuration is also flawed. It receives Qualys SSLLABS score of ‘F’ for vulnerability to POODLE TLS attack, a TLS variant of the original POODLE SSLv3 attack.

The following screen shots show teacher and parent logins served without encryption, and a proxy log showing the username/passwords being sent without encryption for a teacher account.

Screen Shot 2015-03-04 at 12.30.34 AMScreen Shot 2015-03-04 at 12.38.42 AMWhen a parent account login is started from an HTTPS page, the browser actually notifies the user that the credentials are being sent without encryption. The proxy log  confirms this, and the rest of the parent session is served without SSL/HTTPS.

Screen Shot 2015-03-04 at 12.32.34 AM

Screen Shot 2015-03-04 at 1.24.09 AM

Here is a summary of the SSL report

Screen Shot 2015-03-04 at 12.50.11 AM

Passwords stored in plain text

The following screen capture shows a trial teacher account displaying a roster page with student names (redacted) and passwords. This establishes that Raz-Kids is not following the best practice of hashing passwords at the server.  Teacher and parent passwords are treated similarly. Notice also that the page has been served with HTTP, meaning no encryption as these are transmitted across the network.

Screen Shot 2015-03-04 at 12.57.39 AM

Class roster with plaintext passwords transmitted without encryption

Previous versions of the Android and iOS apps transmit entire class rosters with plaintext passwords, unencrypted, when presented with a teacher username, and rely on this interface to function.  Raz-Kids has chosen to leave this API functional even after releasing updated apps that don’t rely on this interface. This means that users are not forced to update, and if they still have the older versions they are still causing this information to be transferred.  The interface could also still be exploited by an attacker.  User agent filtering was added in mid-February, but it is straightforward to change a browser’s user agent string to match one of the mobile apps and exercise the interface from a browser.

A portion of this response structure, from a trial account, is shown below

Screen Shot 2015-03-04 at 1.19.05 AM

I’ll close this post with a quote from the company that develops Raz-Kids, as reported in the NY Times:

“We are confident that we have taken the necessary steps to protect all student and teacher data at all times and comply with all federal and state laws,”

DirectoryBurst – XSS and caching.

First a word about disclosure and vendor response.  I sent a couple of emails to DirectoryBurst about the problems in this post.  Though I never heard back from them, I observed that they fixed the XSS problem described below.  I describe the other less serious ones here too, in part so that users who see this can be aware and take steps to protect their information.

DirectoryBurst is an online school directory service.  It stores lots of personal information including full name, address, phone numbers, and parent email addresses.  I took a look at the site and saw a few problems.

The first one, now fixed, is that they were storing unvalidated user input for later display on their website.  Entering a directory name (to a demo admin account) that included the string “<script>alert(document.cookie);</script>” caused the following window to pop up each time this directory was viewed.  I’ve redacted the cookie values but kept the cookie names in the screen shot.

Screen Shot 2014-11-25 at 8.59.48 PM

This means that the script included in the directory name was executed in the browser when the page was viewed.  Popping the cookies up in an alert window is innocuous but a different script could forward these cookies to an attacker’s server, which could pose a real risk.  The defense against this attack is to inspect all user input and convert any code or scripts to printable, not executable formats.  For instance, the script text above was converted as follows for display on this blog post. (I’ve highlighted the converted characters).


Notice that there are two JSESSIONID cookies on the list of cookies?  Those are session IDs that could be used in a “session hijack” attack to take control of the user’s account.   The reason the script could read them is that the httpOnly flags were not set to protect them from this sort of attack.  I describe this problem in more detail in my post on session cookies.

Screen Shot 2014-11-25 at 9.08.03 PM

Another thing an attacker could do with this vulnerability is include malicious HTML in the page sent to users who load the directory.  As an illustrative example, entering a directory name including the HTML for a link to sfgate.com results in this HTML being served to the user.

Screen Shot 2014-11-25 at 9.16.09 PM

Which looks like this on the page – the text ‘click’ is a live link.  An attacker could set such a link to point to a malicious site or otherwise change the content of the page.

Screen Shot 2014-11-25 at 9.31.24 PM

Finally, DirectoryBurst is not preventing directory information from being stored in the browser’s disk cache. This means that someone can view them in a browser even if the browser has been closed and restarted. It also means that someone can hit the ‘back’ or ‘history’ buttons and view the directory details loaded by a user even after a user has logged out of the site.   (The fix is to include the “Cache-control: no-cache, no-store, must-revalidate” directives in response headers to prevent disk caching of sensitive data).  If your school uses DirectoryBurst, you should be careful about accessing it from a shared computer, and should clear the browser’s history and cache if you do use it on a shared computer.

Transparency and disclosure

I see lots of security problems with educational web sites and apps.

Sometimes problems like these get reported in the press.  For example in the past couple of years, Shutterfly, Schoology and Edmdodo have been in the press for not using SSL to protect user accounts and the information that they contain about kids.  Often, even if they are fixed, the companies don’t report that their users were exposed to security vulnerabilities.   This sort of thing is not as serious as an actual data breach, but parents and educators can’t make informed decisions without transparency and information about the security practices of the sites they are considering.  Many companies and sectors do make a practice of disclosing their security problems responsibly.  But this is not something I’ve seen in the ed-tech space.

Talking about things that are already fixed adds transparency and openness.  There are differing opinions about the best way to disclose security problems that have not yet been fixed.     This post by Troy Hunt lays out a good set of guidelines for when it makes sense to publicly disclose security problems.  He weighs the consequences to the site’s operators and users. It’s worth a read, and Troy’s blog, www.troyhunt.com is a great resource for those who’d like to learn more about security.