Last week, it was revealed that over 500 million Yahoo! accounts were breached. At first blush, a great many IT personnel are likely to overlook the recent breach as having little or no impact on their organizations. But that is not the case and it is particularly important for just about any organization -- especially those that are currently providing APIs -- to take action immediately.

While the account-holders' passwords themselves were only retrieved in encrypted form, it appears as though some if not all the password hints (questions about something private to the account holder and the answers) were retrieved in clear text, unencrypted. According to USA Today's account of the breach, Yahoo! said the "theft may have included names, email addresses, telephone numbers, dates of birth, and in some cases, encrypted or unencrypted security questions and answers." So, why is this a problem for every organization (API provider or not) and what must you do about it? One only needs to look at industry history to understand the extent to which hackers will go to exploit such information.

The Yahoo! breach isn't the first breach to result in implications for organizations that run APIs. Back in Oct 2013, Adobe experienced a nearly identical compromise in which the hackers obtained the encrypted passwords and password hints (in clear text) for over 38 million of its users. One year later, when the social media company Buffer suffered a major API-related breach, it was relatively confident that at least part of the attack on its infrastructure was inspired by data gathered during the Adobe breach.

At the root of the issue is a problem every Internet user knows about (but also doesn't do much about): shared passwords. I'm guilty. Your guilty. We're all guilty.

Back in the 1980s, when I was an IT guy, there were only two systems that required me to input a user ID and password. One of them was our PC-based email system (anyone remember Network Courier, the great grandfather of Microsoft Exchange?). The other was Profs running on an IBM mainframe. With only two user ID/password combinations in my life, they weren't hard to remember. Today, there are easily over 100 different systems into which I must enter user IDs and/or passwords -- everything from my phone to eBay -- and I would have gone completely insane by now had it not been for the way I use the exact same credentials ("shared passwords" if you will) for many of them. I'm not alone.

But the shared password problem also poses a major security risk to the Internet because once the hackers uncover the password that goes with a user ID, there's a strong possibility that the same combination will work elsewhere. What makes the Yahoo! and Adobe breaches special is how certain patterns emerge when password hints are available to the hackers. For example, Grateful Dead fans are so passionate about the Dead that they have passwords like "JerryGarcia" and password hints like "Grateful Dead guitarist." Even if the hacker is a millenial in Siberia who doesn't know the Dead from Maroon 5, it wouldn't take long to crack thousands of user ID/password combinations. What's even worse is when multiple accounts having the same password also have the same encrypted password because of the chosen method of encryption. Anybody who knows how to work a spreadsheet could sort those accounts in such a way that a quick scan of all the hints would be enough to intuit their common password.

In Buffer's case, the belief is that the hackers broke into its code repository after discovering shared credentials that belonged to one or more of its developers. The attack snow-balled into a discovery of tens of thousands of Twitter and Facebook Oauth tokens belonging to Buffers users -- tokens that were used like master keys to breach those users' Twitter and Facebook accounts via APIs.

Likewise, when the Apple iCloud accounts belonging to several celebrities including Jennifer Lawrence were breached, the word on the street was that the hackers conducted a brute force attack on the API for Apple's Find My iPhone service. The API, like most of Apple's iCloud, required only a user's ID and password to authenticate and did not have a rate limiter in place that would have squelched attempts by a software robot to rifle through thousands of user ID/password combinations before scoring a hit. Apple never acknowledged that version of the breach. But the hackers published the source code they used to breach the API, source code that stopped working within about 24 hours because a rate limiter suddenly appeared on the API (no doubt a swift response from Apple's engineering team). More importantly, such brute force attacks are often backed by databases containing thousands of users IDs and passwords that have historically been known to work elsewhere. The infamous RockYou database breach that resulted in the exposure of over 14 million user IDs and passwords was rumored to have played a role in the brute force attack against Apple's API.