Lessons to learn from Teensafe
Simon Wilcox, MD of Digital Craftsmen looks at the latest security breach surrounding Teensafe and shares his views on how this situation could have been avoided. If you’re not up to date with the story, catch up via TechRadar or ZDNet.
After reading about the latest security breach, I felt compelled to write a post to review the underlying reason of what had caused it, and then to look at what should have been done to avoid this happening in the first instance. The fault itself appears to be in a message queuing system called Celery (judging from the screenshots ZDNet have on their site). The poor design aspect here is that passwords were being passed around in plaintext. No regard for security about this appears to be have been factored into its design, at the very least they should be encrypted on the queue and only decrypted by the task requiring that information.
The Teensafe application itself has not been properly thought through in its design as it requires the user to downgrade stronger protections on their Apple ID to work properly. This should be a red flag for anybody contemplating use of any application, but that’s not the biggest issue from our point of view. As best practice, users should never trust their passwords to third party sites.
It looks like the data breach occurred because someone had set up a monitoring tool for Celery called Flower and then failed to secure it properly. This allowed anyone who could find it to read messages in the queues, including plain text passwords.
How could this be avoided ?
1. Design the app properly to protect data in transit
The breach would still be bad but at least the passwords would be protected. It’s hard to understand why nobody considered this in their dev team.
2. Have a no-fault process for identifying vulnerabilities
Security is everyone’s responsibility. Build systems that reward internal identification of vulnerabilities before they become critical.
Consider using an Ops team with a security mindset to help identify vulnerabilities that do make it through to production.
3. Ensure all production systems are managed centrally by an Ops team tasked with maintaining security
Production servers should be managed by configuration management software such as puppet, ansible or chef; and maintained by an Ops team tasked with thinking through the implications of change and rolling things out securely. That doesn’t need to slow things down, it can be a very responsive and agile process but unless it’s controlled this kind of breach will occur.
If you want to speak with an expert about the security of your online operations, then email or call one of the Digital Craftsmen team on +44 (0)20 3745 7706.