In this post I’ll discuss my observations of the security of Schoolmessenger’s secure document delivery service. Schoolmessenger is a signatory of the Student Privacy Pledge.
[Update: May 5, 2015, I received word last week of the following security improvements from Schoolmessenger, summarized here and updated inline below. Thanks to Schoolmessenger for their responsiveness and work toward a more secure service!]
- Forced HTTPS
- A return to 256-bit SSL
- Reduction of Personally Identifiable Information in the notification email and the body of the page
Email TLS is on the roadmap for future work.
[Update: this post was updated on March 20th to add observations of the password-protected document delivery method]
Overview of the service
The Schoolmessenger Secure Document Delivery service can be used by schools to deliver documents to parents. Parents receive an email with a link to the document, which is served using SSL/HTTPS when the parent clicks the link. The document can be configured by the school district to be served with or without password protection. Schoolmessenger’s description of the service can be found at this link.
Summary of observations
The notification email from Schoolmessenger to the parent is sent from Schoolmessenger’s servers without Transport Layer Security (TLS). (Email TLS provides encryption and authentication of email as it traverses the shared network between companies’ mail servers. I wrote a detailed post on TLS for email last week.). Though the document itself is not stored in the browser cache, the URL providing access to it is, and the URL is also stored in the browser history. Files sent with passwords reveal the name of the student, school, and contact info of the school administrator who sent the file before checking the password. If the URL is modified to http instead of https, the document is served without SSL. Company materials describe the service as using 256-bit SSL but the server hosting the document exclusively uses 128-bit SSL.
I would like to thank and acknowledge the contributions of a colleague who works at a large school district, who collaborated on this analysis.
Notification and response
In early March I requested information about which domain was used to host documents from the Secure Document service and asked for a copy of their Specification Sheet, using the contact form here. On March 16th I notified the company of the findings included in this report, by mailing it to email@example.com, at the advice of a Schoolmessenger call center agent. I sent a follow up mail on March 18th to the same address. Schoolmessenger has not responded to my inquiries.
TLS on outgoing mail
Email TLS is used to encrypt and authenticate mail as it traverses the shared network between email servers (see my previous post on email TLS for more details). The Google Safer Email page shows that none of the mail Schoolmessenger sends (via swiftwavenetwork) to gmail recipients uses email TLS. (Note that Google’s data lags by about 5 days – today’s snapshot shows observations from March 14th.)
Google’s data is consistent with the headers of the mail I received in my gmail account, which do not indicate that TLS was used.
URL contains sensitive information and is stored in browser history and cache
The URL for the secure document contains unique keys that identify a document. In the links I received, there was an 11-character code that appeared to be base64 and a 64 character hexadecimal code.
h t t p s://msg.schoolmessenger.com/m/?s=&mal=
This is counter to OWASP ASVS requirement 9.3
One reason for this is that the URL can be stored in the browser history, as shown below. It can be viewed in the history or accessed by using the back arrow.
The optional password protection largely mitigates this risk. If it is not enabled by the school district, then the URL in the history gives direct access to the file stored at this URL. Though this could be stored in server or proxy logs, it is a concern primarily if the service is used from a shared computer where history could be viewed by other users.
The secure document is transferred as the response to a POST request and is not cached by the browser. However the response to the initial URL GET is cached in the browser’s disk cache and results in the URL being stored in the browser’s disk cache.
As with history logging, this is mitigated for files that are configured by the school to require passwords for viewing and is primarily a concern only if the document is viewed from a shared computer.
Documents sent with passwords reveal information before the password is entered by the user, with limited controls on brute force password attacks [Update: this section was added on March 20th, after the original report was posted]
[Update 5/5/2015 – Schoolmessenger has notified me that there is now less PII in notification emails and page text]
If a document is distributed with the optional password enabled, the page served by the link sent to the parent reveals information before the password is entered or verified. The page includes the full name of the student, the name of the school district, and the name and email address of the school official who sent the document.
In a quick check of protections against brute force attempts on the document password I observed no rate limiting between requests. After about 1000 attempts the site rejected new attempts for under a minute then started accepting them again. According to the company’s literature the password can be chosen from fields of the document – this knowledge could be used to constrain the set of passwords used in a brute force attempt. For example, 1000 attempts is about 3 years’ worth of birthdates.
Site allows the document to be served with http/no encryption if the url is modified to http.
[Update 5/5/2015 – Schoolmessenger has notified me that the site now forces HTTPS]
If the url is modified to use “http” instead of “https”, the document is served using http, without encryption. The proxy log below shows the PDF file being transferred using http. Redirecting http requests to https, and the use of HTTP Strict Transport Security (HSTS) would prevent this from happening.
[Update 5/5/2015 – Schoolmessenger has notified me that the site has returned to 256-bit SSL]
Though this is not a significant security risk, it is worth noting that the SSL implemented by the service does not appear to match the product description on the company website. One example of this is shown in the screenshot below, from the document at this link.
Qualys SSL Labs TLS check shows that the msg.schoolmessenger.com domain’s SSL is configured to exclusively use 128-bit encryption
For reference, the summary of the Qualys SSL Labs TLS check is shown below