Could Facebook have prevented storing sensitive data in application logs?

Headlines recently showed millions of user passwords were stored without protection for years by Facebook. As per Facebook’s disclosure, this happened because application developers (inadvertently) logged passwords in clear in application logs. The same event happened at GitHub and Twitter in recent months. This happens more commonly than we think if we include enterprise software.

Image result for thumbs down facebook


Passwords happen to be super-sensitive data. As far as password logging goes, there are cryptographic protocols available today – such as SRP (Secure Remote Password) – that could have prevented this security event at Facebook. SRP is a zero-knowledge proof mechanism where the password is never transmitted on the wire. Instead, the client proves to the server that they know the password without sending the password itself nor any other information from which the password can be derived. While SRP is a useful defense against man-in-the-middle (MITM) attacks and weak passwords, it could have been also useful in Facebook’s case of logging passwords in clear. With SRP the password is never passed into the applications on user login, therefore, the application developers cannot inadvertently log it.

In addition to passwords, we often see other kinds of sensitive data getting entered in logging systems. For instance, we often see user Personally Identifiable Information (PII) getting logged. We need to enable and see application logs to troubleshoot bugs and performance issues, but generally the logs should never contain sensitive data. Logging systems are generally outside of secure enclaves and silos and storing sensitive data in them defies all the security that has been put in place to protect such sensitive data.

While one may argue that sensitive data logging happens primarily due to software bugs that must be rectified, practically speaking such bugs can always exist in software and may go undetected for years (Facebook being a case in point).

One way of remediating this issue is by adding a ‘dynamic data masking’ layer between the applications and the logging systems. Most logging systems such as SIEMs or cloud logging managed services ingest logs over standard protocols such as Syslog and REST APIs. The ‘dynamic data masking’ layer would intercept these protocols, scan log messages for sensitive data, and mask such data before it gets written to the logging systems.

Want to know more? Get in touch

*** This is a Security Bloggers Network syndicated blog from Blog – Protegrity authored by Raj Jain. Read the original post at: