Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Even If You Haven't Been a Victim of Account Takeover, You're Still Vulnerable

DZone's Guide to

Even If You Haven't Been a Victim of Account Takeover, You're Still Vulnerable

To secure software, you have to secure people. Here are some examples of how hackers have taken over accounts and some best practices to prevent similar attacks in the future.

· Security Zone
Free Resource

Address your unique security needs at every stage of the software development life cycle. Brought to you in partnership with Synopsys.

The past few years have seen some of the world’s largest corporations fall victim to data breaches. Yahoo, LinkedIn, and Adobe, to name a few, have had to grapple with the theft of millions of user credentials. Stories like these should serve as a cautionary tale to organizations that create accounts and store user information — regardless of their size. Arming your organization with robust security measures that can halt account takeover efforts must be a top priority.

Securing your business at the application layer will not only offer protection if your business is hacked, but will also defend against credentials stolen from third parties in separate attacks. Yes, even if you are not hacked yourself, information taken from a different data breach could cause your business just as much harm. Here is why:

Cybersecurity best practices dictate that you do not reuse the same password for multiple accounts. However, despite knowing this, many people do. A study done by Dashlane found that the average number of accounts registered under one email address in the United States is 138. On average, people reused their favorite password on at least four other accounts, and the average inbox contained 37 “forgot password” emails. They additionally found that in response to lost password queries, 10% of companies sent the user an email that displayed their password in plain text. This lack of responsibility toward user credentials is what makes even one data breach so threatening. It is likely that the stolen username and password from one site can be used to access the same user’s profile on another one.

Take Fitbit for example. The company suffered warranty fraud as a result of account takeover. Stolen credentials were used to hack into Fitbit user profiles to request new devices, saying that their own had stopped working. In reality, hackers had changed the account information to an email address in their control, allowing them to receive multiple new Fitbit devices for free. Brian Krebs notes that though it would appear that Fitbit itself had been hacked, in reality the compromised accounts resulted from information stolen in a previous data breach at a different company.

The same thing might have happened to Facebook in 2013, if not for their proactive response to the Adobe data breach. Following the breach at Adobe, Facebook crosschecked for any accounts that used the same exact same login information on both sites. When they encountered users who had used the same credentials, they prompted them to change their password, as they might be at risk of account takeover via the data breach at Adobe.

While Facebook’s response is admirable, most businesses simply do not have the resources to monitor data breaches across the web, especially as they become more frequent. Until users start to adopt better password practices, the safest bet is to implement a series of account takeover defenses on your own site, so that you are covered from a myriad of account takeover tactics regardless of other breaches.

One way you can work to protect your site and users is by monitoring requests to determine if they are being made by a bot. Hackers need automation, and will employ botnets to input user credentials for them. You might detect a bot via behavior profiling. This allows you to learn information about how your users typically operate. If they do something drastically different i.e. logging in from a different device or physical location, it might be an indication that their account has been compromised. Another way to spot a bot is through rate limiting. If there is a lot of traffic within a short period, that indicates a bot. If it seems requests are coming from a bot, you might administer a Captcha, stopping the bot while not disrupting users. Then record information, such as the IP address of the bot, to help recognize attacks in the future.

Since it is unlikely that consumers will collectively embrace secure web usage anytime soon, the best thing an online business can do is be proactive about account takeover defense with a real time approach.

Find out how Synopsys can help you build security and quality into your SDLC and supply chain. We offer application testing and remediation expertise, guidance for structuring a software security initiative, training, and professional services for a proactive approach to application security.

Topics:
security

Published at DZone with permission of Mike Milner, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}