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.

SSL/Encryption

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,”

Raz-kids *does* collect student personal information.

In my next post I’ll have more to say about security problems I’ve observed with Raz-Kids, but first I want to start with their recent statements that they don’t collect students’ personal information.  It’s important to document what information they do collect, and it’s relevant to the discussion of how their data security practices have put student personal information at risk.

In an article published February 8th in the New York Times about data security problems in ed-tech apps, a representative for Cambium Learning Group, the developer of Raz-Kids was quoted as saying that Raz-Kids does not store “sensitive” personal information about students like addresses or phone numbers.   Later on twitter, a company representative took it further, stating “Raz-Kids holds no personal data.”

Screen Shot 2015-03-03 at 11.15.32 PM

One of my kids has a Raz-Kids account and I have seen first-hand what information the service collects.

From the FTC COPPA FAQ Page, here is a summary of what qualifies as children’s personal information under COPPA. Though COPPA does not always apply in educational settings, I view this list as a very good yardstick for what defines student personal information. I’ve highlighted the line items most relevant to Raz-Kids.

What is Personal Information?

The amended Rule defines personal information to include:

  • First and last name;
  • A home or other physical address including street name and name of a city or town;
  • Online contact information;
  • A screen or user name that functions as online contact information;
  • A telephone number;
  • A social security number;
  • A persistent identifier that can be used to recognize a user over time and across different websites or online services;
  • A photograph, video, or audio file, where such file contains a child’s image or voice;
  • Geolocation information sufficient to identify street name and name of a city or town; or
  • Information concerning the child or the parents of that child that the operator collects online from the child and combines with an identifier described above.

Here’s a summary of what raz-kids collects, all of which is covered by the list above.  I believe common sense also tells us that the information below is personal information about a student, and that all of this information is worthy of data security protections.

Screen Shot 2015-03-03 at 10.33.40 PM

  • Raz-kids generates reading level assessments and other metrics of a child’s reading proficiency.  This falls under the last bullet above, information concerning the child that the operator collects online from the child and combines with one of the other identifiers.   Screen shots of the reading level progress chart (annotated) and a quiz result showing skills to work on are shown below.

Screen Shot 2015-03-03 at 10.56.13 PM

Screen Shot 2015-03-03 at 10.45.42 PM

More soon on data security.

A Starting Point: A Web App Security Test Plan for End Users

In an earlier post I discussed why we need security standards for education-related web apps.  Today we really don’t have any. Student privacy legislation typically requires “reasonable” security.  (This is due in part to the fact that legislation moves at a slower pace than technology and today’s requirements might not outlast the legislative cycle.) Industry-driven student privacy standards also tend to speak of “reasonable” security with few specifics. TRUST-e’s definition of kids privacy does not require protection of students’ personal information and academic activity, just their credit cards and SSNs.  Nobody has really specified what reasonable security means.   In this post I’ll share a starting point, based on the OWASP Application Security Verification Standard (ASVS) and my own observations of web app security problems.

Securing web applications takes effort, and attack methods grow more sophisticated all the time.  But the blueprint for providing a baseline of strong security is well defined.  The OWASP ASVS spells out a comprehensive list of requirements for designing and verifying a secure web application and defines different levels of verification.  A security standard appropriate for apps collecting students’ personal information and academic activities should incorporate most of the requirements from the ASVS ‘Standard’ level of verification.   Many requirements for the Standard level of verification require access to the inner workings of a web service’s operations.    The test plan I’m presenting here focuses on the ‘Opportunistic’ level of verification that can be observed by end-users of the web application.   My outlook is that the rigor of the practices we *can* observe is an indicator of the practices we *can’t* observe as end users.  So by assessing the health of a service against the observable security practices we can create a yardstick to compare sites and make decisions about whether to use them.

To perform the tests in this plan, no special access is needed beyond an account with the service, and no special equipment is needed beyond a computer and some free software programs.   Every item on the test presents some level of security risk. Many of them are minor but as a whole they paint a picture that’s often more important than the individual weaknesses cataloged in the test.  Having said that, if every education-related web app met this test standard, it would be a big leap forward from where we are today.

It’s my hope that this test plan might be adopted by parents, administrators and teachers as a yardstick or minimum set of requirements for apps that collect our children’s and students’ information.   It’s embedded below for viewing and downloading.

Web-App-Security-Test-Form-Feb15 (downloadable PDF)

O’Reilly Fluent Conference: Web App Testing For Everyone

I’m happy to announce here that I’ll be speaking about web app security testing at this year’s O’Reilly Fluent Conference (April 20-22, SF) .

Web applications are under constant attack and intrusions and data breaches are on the rise. Though attacks can be complex and sophisticated, many of the most common vulnerabilities are straightforward to observe and exploit.

In this presentation, Tony Porterfield will describe ways for users without extensive security experience to test for common vulnerabilities in web applications using only a browser and free software tools. These techniques will be illustrated with examples of actual vulnerabilities that he has observed while testing educational web applications. He will present a test plan that can be used to survey a site’s security in a short amount of time, and describe how it relates to the OWASP ASVSand Top 10 list.