Two-Step Verification (2SV) is not Two-Factor Authentication (2FA)

This week, Twitter became the most recent online service to move to 2-Step Verification (2SV). One high-profile intrusion recently sent stocks spiraling when an attacker posted false news of a White House bombing after gaining access to the Associated Press Twitter account (@AP) through a successful phishing attack. While Twitter had been reportedly working on a new authentication solution, the AP event likely accelerated those efforts.

Following Twitter's announcement, the media and supposed security industry pros once again continued to perpetuate confusion over what constitutes "Authentication" versus what constitutes "Verification." Bloggers over at CNET provide two fine examples of this confusion just yesterday in response to the Twitter news. First, at 2:44 PM PDT on May 23 (time stamped as of 5:00 AM PDT on May 24), Jason Cipriani posted, How to use Google Voice with two-step authentication. Shortly thereafter, at 5:29 PST (time stamped as of 5:00 AM PDT on May 24), Seth Rosenblatt posted, Two-factor authentication: What you need to know (FAQ). Jim Fenton, the Chief Security Officer for OneID, a company that doesn't even address either 2FA or 2SV, has the industry credentials to seem reputable, but fails to effectively convey the difference between the two methods in his recent posting, Two-factor authentication is a false sense of security.

Look around a little deeper at the companies that are implementing similar solutions, and the vocabulary remains a bit inconsistent. 

The (Mis)Perception of Safety

Yesterday, I was fascinated by the fact that my kids were so enthralled by the athleticism and spirit shown by the runners in the Boston Marathon that once they returned home from watching the race, they hosted their own "marathon" in our back yard, complete with number sheets taped to their shirts. They were oblivious to the tragedy that had occurred, innocence retained despite it's loss elsewhere. I tend to think my fascination humanizes me a little.

Being a security professional during catastrophic human events such as the Boston Marathon Bombing is a sobering position. At times manic with grief and disbelief, and at others a bit calculating and analytical, I can probably come off as standoffish at best, inhumane at worst. I accept the perception that others have of me but I would argue coming from a reasonable perspective is the best way to counter irrational acts of violence.

Cloud Computing Dangers: Just Forget About It

This is the final posting (Part 10) of the Case Study in Cloud Computing Dangers.

By the end May 15, Day 7 of our outgoing mail Denial-of-Service on Office 365, on May 15, 2012, everything returned to normal. I was thrilled to find my VA email address flooded with test messages from over the preceding week.

Relief. And then, nothing.

We received no update from Microsoft, no communication from senderbase.org/Cisco, no satisfactory closure of any help desk tickets. Nothing, except for business as usual.

Cloud Computing Dangers: Stand By and Wait

This posting is Part 9 of the Case Study in Cloud Computing Dangers.

It took six days after I detected an outgoing mail Denial-of-Service for Microsoft to publish a public admission that a problem did truly exist. In the contemporary fast-paced IT world, for any problem to take six days to recognize is like waiting to be taken across the river Styx. But, I doubt that Microsoft was working on it's obituary.

Cause

Currently Office 365 outbound email servers have a SenderBase reputation of neutral and a score of 0. As a result any policy set to throttle or reject mail from a server rated neutral or with a score of less than or equal to 0 may impact delivery of the mail from Office 365 customers.  

Microsoft currently believes this is due to an instance where a large number of bulk mail messages were sent to a user via a server that contributes reputation information. This mail did not get classified as spam by us, the sender is reputable, but the volumes, combined with Cisco’s rating system, have temporarily reduced our email servers' reputation in their SenderBase service. According to Cisco, it will take time and additional mail flowing through their system to retrain it and restore our email servers’ reputation.

Cloud Computing Dangers: A Case of the Mondays

This posting is Part 8 of the Case Study in Cloud Computing Dangers.

We started the business day on May 14, 2012 finally able to send email to the primary contractor on our VA project, but not to the VA email accounts. This development was not an indication that Day 5 represented the end of our outgoing mail Denial-of-Service between our Office 365 cloud service and just about any mail gateway using Cisco devices or any other devices that used senderbase.org to receive SPAM reputation scoring. The organization had simply been shamed (either within or without) into lowering its SPAM blocking threshold to allow any email through that was rated Neutral. Not only was the organization the victim of being unable to receive legitimate email from business partners and clients, it was forced into a making a business decision that would allow more malicious messages to pass through the gateway. It was not a good sign.

Cloud Computing Dangers: Blame When Things Go Wrong

This posting is Part 7 of the Case Study in Cloud Computing Dangers.

When technology problems occur, IT folks will typically focus first on finding a technical solution. It's in our nature because solving technical problems is what we've been trained to do. Waking up on Sunday, May 13 to find ourselves still suffering from an outgoing mail Denial-of-Service on our Office 365 business platform, we were in disbelief that the technical problem still had not been solved. Our challenge was to move past our confidence in understanding the problem's technical nature and to recognize that we were falling victim to a broader issue of being unable to assign responsibility in a massively distributed communications system.

Cloud Computing Dangers: False Hope

This posting is Part 6 of the Case Study in Cloud Computing Dangers.

On Saturday, May 12, as my company continued to suffer from an Office 365 outgoing mail Denial-of-Service, I woke up to an email a colleague sent me from the primary contractor that we were unable to communicate with. A test message that I had sent at 3:33 PM on Thursday, May 10 had been received at 2:24 AM Saturday morning. Despite a transit time of just under 36 hours, I was elated to discover that a message had gotten through. Perhaps Microsoft was really true to its word and we could expect to have the problem resolved soon so that we could move on with our lives. Or, perhaps it was just a fluke since I hadn't seen any other messages get through.