Breach Notifications: Adobe

Adobe has issued an important alert for all customers of Adobe. Adobe says they have issued a mass reset of user accounts but many people I’ve spoke with haven’t received a notification via email at this time. The customer alert contains the steps users should take to reset their password without waiting, and it’s strongly recommended that all users that have Adobe accounts do exactly that. The puzzling part about this notification is that Adobe indicates that they store encrypted credit or debit card numbers and expiration dates. This is an audit-failing practice that should not have been implemented and should have been addressed by Adobe as part of a routine PCI/DSS assessment.

Worst Practices

No vendor that uses credit card data is to store credit card numbers, regardless of them being encrypted. It is not needed by the merchant to store the numbers at all, because they are authorized by a payment processing company and the merchant can safely store a token that acts as a reference to a transaction only and does not decrypt into a valid credit card number. Adobe has several products and services that use the Adobe account information, one of which is Business Catalyst; and in the course of some searching I did find one particularly interesting discussion on their support website titled PCI Compliance where a customer is asking about this service in particular and an Adobe rep informs the customer that Business Catalyst is certified as PCI Level 11.

Without knowing more details about their required assessments to maintain that certification, it’s hard to say how they were able to pass an audit and simultaneously engage in this practice of storing credit card numbers. In the case of Business Catalyst, which is a content management service for vendors, it seems very unlikely that the Adobe account system would be out-of-scope for purposes of PCI/DSS. The method used to breach Adobe’s systems and gain access to this data are also important, as Adobe is also required to follow very stringent access controls over information like this. Over the next few days and weeks it seems likely that Adobe will have to further provide additional information At this point it seems very likely that Adobe will be assessed a very large fine in the aftermath of this breach, and can lose their ability to handle credit card payments with subsequent breaches. It’s a very serious issue for them that they will need to tackle sooner rather than later. Breach notification laws exist in 46 out of 50 states in the United States, and Adobe’s status as a publicly traded company means that even more details will have to be released to the SEC. While the consumer side of this incident is terrible enough, Adobe also has reportedly had the sourcecode to their entire product offering taken as well, which can be leveraged by people to write zero-day exploits against previously-unknown vulnerabilities in their software. This is arguably far more serious than millions of encrypted credit card numbers being stolen.

Possible Dangers

Considering that Adobe’s technology is so prevalent in web browsers (Adobe Flash) and in handling forms and documents (Adobe Acrobat) not to mention the dozens of other tools and applications in their portfolio — having access to vulnerabilities that have not yet been broadly discovered will enable malicious actors to tailor their attacks to exploits Adobe and vendors like Microsoft and Symantec aren’t even aware of. These are especially important in so-called “APT” (advanced persistent threat) attacks where an organization is specifically targeted. The next few days are going to involve a lot of nail-biting for Adobe, their customers, and end-users of their products.


  • Change account credentials with Adobe immediately
  • Make use of the credit monitoring service that Adobe will be providing you
  • Monitor accounts more vigorously for fraudulent transactions
  • Report incidents of identity theft to the Federal Trade Commission2
  • Change your passwords for any website, service, or software that uses the same userID, email address, or password 3
  • Weigh the inconvenience of canceling your cards used with Adobe now versus later should it be compromised. In most cases it’s best for you in terms of level of frustration to cancel and request new cards now rather than discovering unauthorized use later when you need to use your credit card and discover that you no longer have an available line of credit.

  1. This means that Adobe handles more than 300,000 transactions annually. Level 2 vendors are anything less than that. 

  2. Currently the FTC is closed following the Congressional Republican shutdown of the United States government. 

  3. Stop doing this! You should never use the same pair of usernames and passwords for any reason! 

1Password 4 now available on OS X

My favorite password manager recently received an update for iOS, but as of today Agile’s 1Password for OS X is now also sporting numerous refinements and updates in addition to new features to delight and amaze you. My favorite item in the long list of new features that Agile has added has to be this one:
Multiple and Shared Vaults – create separate vaults to share with business or family members that each get their own sync preferences and locations

Agile Blog

Google’s Application Passwords: Credential Corralling

Keeping your single-serving passwords under control.

If you have a Google Apps account, or even a regular Gmail account that you use for email and watching the colorful tumbleweeds on Google+, you should activate their two-factor authentication service.

Google calls this 2-step verification and other folks in the industry usually call it two-factor authentication or multi-factor authentication (MFA) 1.

When you setup multi-factor authentication like this, it works great for applications and services on the web. But what happens when you want to use a mobile device or desktop email client to access your Google account in something other than a browser? Not all applications support an additional authentication method or can even prompt you for a one-time code. Do you use iMessage, Beejive or Verbs for instant messaging? Do you need to configure your CalDAV account for your calendar software? Google allows you to create an application-specific password so that you can let that application or service communicate with Google and login using a strong password designed to allow access to your account without trusting them with your account password and bypassing the requirement for 2-step verification.

This has a couple of benefits, namely that should your account be compromised in this way you’ll have a pretty good idea of how the intruder gained access. Google makes some recommendation for naming these application-specific passwords, but I have to say that using their recommendations may make it harder to dig it up later if you’re anything like me and regularly replace/re-image or rebuild devices and systems.

Because I’m smart, I use 1Password for OS X and iOS so that my passwords, software licenses and account details are safely stored2. When I create an application password at Google I always store it in 1Password so that I can recall it later if I need to put the password in again. You can very easily end up with a mile-long list of passwords if you’re not careful, so in general I recommend the following practice:

How to 2-step like a champion


Name your application-specific passwords by device name or application name, followed by a forward slash ‘/’ and the account that it’s associated with. You’ll thank me later.

$device/[email protected]

What your Application-Specific Passwords List Might Look Like
What your Application-Specific Passwords List Might Look Like

Here in this list you’ll see a list of ‘$computer’ or ‘$device’ names, and one example of a ‘$service’ account: ‘altomail/’, for the beta of AOL’s new webmail client, which can access my Gmail account using the username and that single-serving password.

Device or Computer sounds unsafe. Why do that?

It’s certainly better to have different passwords for every application that needs to access your account, but not always necessary. I’d suggest using a similar strategy for naming them; $app/$device/$account. The drawback to this is that it’s disproportionately a hassle and it’s more effort to revoke them later when you really need to because you have a higher chance of nuking the wrong one, or missing one. Having a consistant naming convention helps a great deal with this, so it’s really up to you to weigh the benefits and level of effort.

Why would you want to revoke them?

Well, because if your iPhone, iPad, or iPod is stolen, it’s easy to revoke the access that device has to your accounts by nuking it with Google and bam, the person that has my device can’t impersonate me or rifle through my online accounts using that password. I always have device-level encryption on my devices, and I can just wipe the device remotely (and I will) but if they can’t use the device, it may not ever get on a network, and therefore it may not ever get my remote wipe command. At that point, I’m concerned about an offline attack to recover data, so I need to make sure those details aren’t useful anymore and I don’t want to have to re-key every single application and device I own unless I have to. You don’t either.

One big benefit to individually authorizing and provisioning using the $application/$device method is that it somewhat isolates other services and devices when one set of credentials is compromised. Given that many apps and services for mobile devices utilize push notifications and maintain persistant connections to do so, it’s often to your advantage to create a dedicated password for those services3

What about 1Password then?

When I set up my Gmail account, Google+, Verbs, Google Voice, Reeder and a bunch of other apps on my iPhone, I can just use the same application-specific ($device) password on all of those apps: the one marked ‘annyong/’. Since I use a clever naming convention on my two-step it’s wicked easy to search and recover that password every time I need it. I can then Copy-Paste it from 1Password into the other app. I can search for my device or computer name, and it comes right up.

Obviously any trusted password manager you use will work for this, but 1Password is the best-in-class so that’s the one I use. It’s mine; I’m a fancy boy.

Don’t make it too hard

There are many people that don’t bother with two-step auth on their Google account because it’s too much hassle, or tedious to get these application passwords set up. This method I’ve outlined should make two-step authentication tolerable and still give you enough protection and isolation that if a device is missing/lost/stolen or your computer needs to get re-imaged or replaced, it’s a lot easier to get back up and running without having to replace a dozen passwords every time.

  1. I previously wrote a little bit about the technology Google uses for this when writing about Dropbox’s two-factor option. If you are using iOS and Authy it’s easy to add your Google Account(s) to Authy in addition to your Dropbox account and any other service you subscribe to that allows you use a TOTP token. If you use Duo Security which lets you do sweet multi-factor access via push notifications, SMS, and voice calls, you can also add TOTP tokens for Google, Dropbox, and other services! 

  2. 1Password also makes it trivial to export a list of items tagged ‘household’ for your partner to import into their 1Password database, which is a real sanity saver. 

  3. In particular IM+ and Beejive messengers maintain lengthy connections to IM servers on your behalf so that they can send notifications to your device without requiring the app to be running. 

Enable two factor on Dropbox

If you are a user of Dropbox, you should enable two-factor authentication on your account. Dropbox joins Amazon, Google, and LastPass as service providers offering strong authentication for account access

Dropbox opted for TOTP, which is the Time-based One-time Password Algorithm. For end users, this means you can use Google Authenticator or other apps that support that; Personally I use Authy for iOS as my weapon of choice in managing my software tokens.1

I can understand why Dropbox decided to go with TOTP but would have preferred they went with Duo Security instead, even if it was just for paid customers. Duo is much more convenient! But the bottom line is that at least they offer multi-factor authentication at all for a service that stores important data for millions of users.

  1. Edit 2013-02-18: Duo Security now allows you to add TOTP tokens in their mobile app. This means that you can use the fantastic multi-factor authentication via the Duo service and also store your tokens for services like Google Apps, Dropbox, and others in one place. There are advantages to using Authy too, and I’ll write more about that another time.