Update Aug 2012: dropbox has implemented multi-factor auth! Read more…

Well, the cat is out of the bag. Dropbox has announced that they accidentally introduced (and then quickly remediated) a bug that had disabled authentication. This left the front door wide open to all of their 25+ million accounts for a few hours. Certainly a big mistake, but this makes me wonder. Is this the sort of thing that could only happen to Dropbox? I mean development happens at breakneck speed these days. With the common mindset of “release early and release often” a bug making its way into production is not surprising to me at all.

This got me thinking. Could this whole thing have been avoided? If development moves at a pace which makes it difficult to QA every detail, perhaps redundancy is the answer. What if, instead of relying solely on a username and password, additional factors were verified when users attempt to authenticate? Had this been the case, things could have played out much differently for Dropbox.

Thinking Outside the Password:

IP addresses If a user is trying to log in from an IP address that isn’t recognized, require them to verify their secret phrase, or to verify via e-mail, etc.

Cookies Similar to the IP address, if a user hasn’t logged in before from their current computer, browser, app, whatever, have them jump through hoops to verify their identity.

External Authentication Services There are many sites out there pushing their own auth services. Openid, google, and facebook, to name a few. Why not link the local account to one of these services to implement multi-factor auth, requiring both valid local and external credentials before permitting entrance.

Text Message When users register accounts, have them enter a mobile phone number. Then when they authenticate, text them a random number and require them to type it in.

Strange Behavior If you see a user trying to log in simultaneously from many different places make them, verify their account. If you see a single IP trying to reach into many different user accounts, block the IP and require those accounts to be verified. Etc.

All in all, I think this temporary security hole could have been avoided. Not by expecting developers to never make mistakes, but instead by embracing human error as a fact of life and implementing a layered authentication and security methodology.