Designing Applications for Compromise

Tuesday, January 24, 2012

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

Thinking Ahead to a Data Breach - Designing Applications for Compromise

I was catching up on data breach news from the last few weeks and the Dark Reading article on the Care2 data breach caught my attention. One of the things that nearly every site that's been breached, that also has user accounts, is forced to do is re-set all their user's accounts. 

With the Care2 breach and I'm sure with many many others I began to think about the ramifications of a massive breach, password re-use (recently discussed, partially in jest, here on my blog) and having to re-set passwords for your users.  Then as I'm reading the Dark Reading piece this caught my attention...

From the Care2 site's disclosure: "To protect Care2 members we are resetting access to all Care2 accounts. The next time you login to Care2, you will be automatically emailed a new password, which will enable you to access your Care2 account as usual."

Now, I don't think it's a stretch to think that thanks to what we know about password re-use (people are very, very likely to re-use their passwords) we can say attackers who have pillages a person's username, password, and email contact address will obviously try and get into that email address fairly quickly. 

This creates a problem. If an attacker has compromised your site, and they have hints and a head start to compromise your email as well - how do you get your customers a new password to your site? 

You must consider the email potentially compromised... so simply relying on the method of "email a new password" (it sounds like this will be in plain-text, which is bad enough in and of itself!) is compromised an insufficient.  I bet these are things most organizations don't think of in their application designs - but they should.

So what is a more secure, more sane way of re-setting access to a compromised set of accounts on your site?  Perhaps you could let customers send a temporary one-time-use authentication token to their mobile devices so that the real user can take that token and log into the site and create a new pass-phrase.  Presumably everyone has mobile phone these days, right?

The problem comes with these older applications that have been around for a while, before we started accepting that applications and sites will be compromised and started planning for it.  Back in the age of innocence when passwords were still OK and relevant to account safety and security, as front-line protection from hacking. 

Back in those days a password re-set simply involved sending someone a new password to their email address of record because, heck, it's not like some attacker was going to compromise both your email and site account right?  Too bad those days never really existed, except in the minds of the naive... and not we're paying the price with poorly designed applications.

For those old apps - all we can do is re-design as we do our cloud transformation.  If you're not re-designing post-breach, then you're in for an even bigger pain so I feel for you. 

For new applications, make sure you're thinking ahead and designing applications to be resilient in the face of a complete compromise - including the information therein and connected accounts - so that your users can still get back to the application even after it's been ravaged by hackers.

Cross-posted from Following the White Rabbit

Possibly Related Articles:
13859
Webappsec->General
Information Security
Passwords Application Security Access Control Web Application Security hackers Software Security Assurance breach Resilience Rafal Los Care2
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.