Every website compromise and password breach puts your website at risk even if your business is completely unrelated to the compromised site.

  

Which major website was compromised this week? How many user details and passwords were stolen?

Over the past few weeks the news was littered with stories of Adobe’s compromise of millions of user records, MacRumors theft of 860,000 username and passwords and the compromise of numerous user passwords at Vbulletin.com.

Attackers Data Mine Compromised Passwords

Every time a major password breach occurs the compromised emails addresses and passwords are available for hackers or criminal enterprises to download and analyze. Unfortunately, the breached companies often improperly protect their passwords and as a result it is easy for hackers to obtain the original password for each user. Attackers will collect and store these compromised credentials and then use this information to take over the user’s account anywhere else on the web where the user has reused the username and password.

Account Take Over is Distributed and Automated via Botnets

Armed with millions of email addresses and passwords from the breached website, attackers use these credentials to programmatically attempt to login to websites all over the web. This activity is not conducted by a single individual sitting at their computer and manually entering usernames and passwords. Instead criminal enterprises will leverage scripts, automation, and botnets to distribute the attack across many computers all around the world. This automation allows the attacker to cover their tracks by initiating the login attempts from real machines all over the world.

This type of attack is known as credential stuffing also called account takeover 

A real world example – How Facebook Is Protecting Their Users

Facebook was not compromised in any of these recent attacks; however, as a large target and an organization that is accurately aware of the risk of third party breaches, their security group took immediate action. Facebook mined the compromised data from the adobe breach to identify Facebook accounts that were potentially at risk. Facebook enabled additional security controls for any account within the adobe breach that used the same password on Facebook.

What You Can Do – Comparing Compromised Passwords with Your Web Applications Users Info

Here’s how to check if users the password information within a data breach may put your users at risk. Note: This may not be realistic for an organization to perform due to the technical requirements and resources needed.

1. Obtain the compromised user data – Download a data dump of the compromised information. This may take some searching but the information is available online.
2. Determine the passwords associated with user email addresses – This step is straight password cracking. The work required will depend upon on the original method used by the website to protect their passwords. Unfortunately, in many cases the passwords are poorly protected with either encryption or a weak hash such as md5. The current best practice for password storage is bcrypt or PBKDF2. Read here to find out how sophos analyzed the adobe breach.
3. Test Your User Passwords – Next we need to compare the compromised data with your web application’s usernames and passwords. Important, this step does not require you to view the passwords of your users. Instead, we’ll simulate the login process in your application to validate if the compromised password from the breached website matches the user in your web application. Here are the steps:
1. Compare the usernames within the breached data (from step 1) with usernames in your web application. Note any matches. These are the accounts we want to test in your application.
2. Work with your development team to identify the authentication routine for your web application. This will include a step where the password provided by the user is hashed and then compared against your data store of usernames and hashed passwords
3. Build a script to perform the hash and database comparison. The purpose of using a script is to avoid having to manually interact with your website UX for each test.
4. Take the list of impacted usersnames (from step 3.1) and their actual passwords (from step 2) and run them through the script (from step 3.3). If a login is successful then we’ve identified a reused password that is at risk.
4. Protect your users – For any matches in step 3.4 you’ll want to immediately take action to protect their account. This can include locking their account, forcing a password reset, or whatever actions are typically taken by your organization in the event of account takeover.

What You Can Do – Securely Store Your Passwords
Ensure you protect password data in your application by using an appropriate hashing algorithm. Approaches such as encryption, md5 hashing or any sort of home made manipulation are not sufficient. Instead you should use scrypt, bcrypt or PBKDF2. More information on password storage can be found at the OWASP Password Storage Cheat Sheet.

–Michael Coates – @_mwc

*** This is a Security Bloggers Network syndicated blog from A Journey in Security authored by Unknown. Read the original post at: http://michael-coates.blogspot.com/2013/11/how-third-party-password-breaches-put.html