Are you securing my kids’ data?

The following is a guest post by Catheryne Nicholson.

If you’re an educator or a developer building and using cool technology to help teachers, children and parents, I’d like to give you a Momma Bear’s piece of advice: if you collect or store information about my kids, secure it. The minute you start gathering data about them, my spidey sense starts tingling. No matter how innocuous the data may seem to you, remember: these are my kids.

Much of the promise behind technology’s ability to help students is premised on collecting and analyzing student data. But if you haven’t seen the recent articles “Data Security is a Classroom Worry, Too” and “How Shutterfly and Other Social Sites Leave Your Kids Vulnerable to Hackers,” or heard what happened to inBloom, or know the revised COPPA rules took effect July 1st, pay close attention. With headlines like these, it’s hard not to question the ability of our schools to protect students’ privacy.

Everyone-educators, parents, and developers-needs to understand the fundamentals of data security and privacy. Before you use or build technology systems which contain information about kids, there are four basic areas to look out for: your browser, the network transmission, the application servers and the database.

1. Protect your web browser

Educators and parents: Do you use web applications to send videos, links or share information to a lot of kids? If so, you could be victimized bycross-site scripting (XSS). Fifty-seven percent of cyberattacks in the last quarter of 2012 were due to XSS, which occurs when malevolent HTML or Javascript code is inserted in a regular text field. What this means for kids, teachers, and parents is that an attacker can, without your knowledge, gain privileged access to content on the page, session cookies, and a variety of other information. How do you prevent this? Ask the developer who built the web application if they have protected their site against XSS.

Developers: Almost all web libraries escape data inputs when you use them properly. For example, in jQuery, use the text() and val() function instead of html(). This is only for values inserted in the HTML DOM. You will need to escape properly depending on context: HTML, script tag, event handler attribute (like onload) or in a URL. Protecting yourself against SQL injection is very similar, so do that as well.

2. Protect your transmission

Educators and parents: The next time you’re on a website which stores kids’ information, look at the address bar. Check if there’s a little lock icon or if the address starts with https://. The ‘S’ after the ‘http’ stands for ‘secure’ and indicates that SSL (Secure Socket Layer), a technology that encrypts all communications going over the Internet, is being used. If the ‘S’ and lock are not there, the site is not secure. Sometimes a web application will have the lock on the login page but not on others. If the site contains kids’ data, every page in the entire application needs to be SSL secured. It’s very easy to get a cookie that has been established on a private page from a public one visited afterwards.

Some schools block SSL in order to monitor what’s transiting through their network. School administrators: this is horribly misguided and you’re putting everyone at risk at your school.

Developers: SSL is cheap and there’s no reason why you shouldn’t use it throughout your site. If your SSL app is getting blocked by a school, explain to them why they should change their ways. If they won’t, provide an alternate insecure subdomain using distinct sessions. A common misconception is that the communication between your computer and a website is private. It’s not. Everyone on your network can see your traffic. Play with Cookie Cadger in a coffee shop if you’re unconvinced.

3. Protect your servers

Educators and parents: It only takes one server intrusion to get your kids’ data and hardening servers requires serious expertise. Ask the developer what measures have been put in place. The answer should be detailed, thorough, and address the areas of intrusion in this article. Beware if the answer sounds evasive or too simple, and ask someone who is more knowledgeable to check it.

Developers: You should understand the following: ssh setup and usage, strong password policies, minimal Linux distributions (remove X windows and all extraneous packages), how to keep server software up to date, disabling root login, iptables, how to set-up centralized authentication (like openldap), and the details of logging and auditing. Hardening servers isn’t trivial so if you’ve never heard of iptables, develop on cloud services such as Heroku and Google App Engine because they have done the hard work for you.

4. Protect your database

You may not be big enough to be the target of a high profile attack, but you may inadvertently expose your information in other ways.

Educators and parents, here are a few very common examples:

• An application you register for sends your password in an email or mails it to you in a letter. No one, not even your school, should ever have your unencrypted password. If you lose or forget your password, the application should send you a reset link and never the password itself.
• A common password is used with other teachers or students to access an information site. Never share a password. Period.
• You keep a student directory copy on your hard drive or laptop. What happens if you lose your laptop or it’s stolen? This information should be stored in a secured place (e.g. Google Drive or MommaZoo).

Developers: Avoid keeping database exports on your hard drive, it’s too easy to lose. Salt your users’ passwords and hash them using robust functions, like SHA-2 or even better bcrypt (not MD5). Advanced crypto math is not required. Use common libraries such as jBCrypt in Java, bcrypt-ruby in Ruby, and bcrypt.js in Node.js, or even better, use a third-party sign-in like Google.

Conclusion

Protecting users’ privacy and security is a balancing act. Too much paranoia compromises user experience and is very time-consuming. But wanton carelessness jeopardizes our kids. Educators and parents, be proactive: don’t use unsecured systems and hold the technology company accountable to help protect our kids’ data.

Catheryne Nicholson is Co-Founder and CEO at MommaZoo, a “village of help for school parents” startup in the Bay Area. MommaZoo provides a local parent network to discover and share help in transporting, caring, and educating kids. Between her multiple jobs and motherhood, she’s always multi-tasking. Back when she had the luxury to concentrate on single tasks, she built energy and emissions management, CRM, and defense software for C3, Siebel Systems, and Northrop-Grumman. She holds a Bachelor of Science in Aerospace Engineering, a Master of Science in Environmental Engineering, an MBA and is a registered Professional Engineer in Mechanical Engineering. She can be found at @mztweet.