Are You Securing My Kids' Data?
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 spider senses start 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
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
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.
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.