Image for post
Image for post

Preventing Account Takeover

Ryan McGeehan
Dec 21, 2015 · 11 min read

Suddenly your users are complaining about purchases they didn’t make. They can’t access their accounts. They’re screaming “I’m hacked” but have no idea why, or how. Your customer service team is overwhelmed with questions.

Account takeover has arrived. Now you need to answer this question on every single user login:

The user sent the right password, but is it really the user?

Let’s talk about building a defensive program around “Account Takeover”, and make sure that users are who they claim to be, even if they’ve successfully authenticated.

Why does this happen?

Governments break into protestor accounts. At Facebook, attacks like this preceded the Tunisian revolution.

You can steal money stored in accounts. Paypal has dealt with this for over a decade. Bitcoin companies are starting from scratch to deal with it.

This list is not exhaustive; there’s a long tail of reasons the bad guys will grief your users.

How are accounts taken over?

Credential dumps are a massive source of these attacks. For instance, Adobe lost a huge stash in 2013 which still surprise startups who aren’t inspecting logins.

Keylogging malware could steal the password of a user and replay it.

Classic phishing attacks are still prevalent and trick the user into sending credentials to the wrong domain.

“Man in the Middle” attacks occur, which can steal passwords off the network between the user’s device and the application.

PREVENTION

Keep in mind that there are many half-solutions involved here, because the underlying platform (the password) is flawed. When many half-protections are all employed it can be extremely difficult to takeover accounts in bulk, even with the victim’s passwords at hand.

LOGIN HISTORY

Image for post
Image for post

Now, consider a new event when “magoo” logs in from 1.1.1.1, with a familiar cookie, from Chicago, and using the Chrome browser. With the above data, you can limits your suspicion of this user and eliminates entire categories of potential attacker.

Only in a complete and total compromise will this user turn rogue. For instance, a rooted / malware infected device, or a gun behind their head.

With a strong login history, you can design your infrastructure with the appropriate challenges to the user and their identity. You can even decorate this data with “very trusted” cookies and IP addresses, based on whether they registered with that ID or performed an action that earns trust for that location, like multifactor or a history of purchases without chargebacks.

Unrecognized IP + Cookie? Ask for email confirmation!

Some companies put a ton of effort into identifying the browser in this decision making process. These techniques are used by ad companies and is contentious around privacy and anonymity. However, these same techniques are the strongest protections that protect every day people against government snooping, fraudsters, and spammers, so it depends on the hands its in. Most technology in security has this dual edge.

IP REPUTATION

Depending on your product, you may not expect to see authentications from known open proxies, known infected hosts, Tor, co-located data centers, EC2 instances, etc. You may only expect mobile carriers, consumer IPs; those sorts of ISP’s.

Almost every security company will sell varying types of this data. You can use it to make judgements (along with login history) on whether you want to throw new hurdles in front of the user.

You can also build this database yourself, by profiling different ASNs that have real users, previously known bad netblocks, and straight up blacklists of known malicious CIDR ranges.

MULTIFACTOR

There is a massive misunderstanding of how Google Authenticator helps against active phishing attacks. It doesn’t!

Image for post
Image for post

Phishing pages that spoof login forms easily steal the OTP from users.

However — OTP based MFA is a great defense against hackers with credential dumps trolling your platform. In that case, the bad guy does not interact with your users and attempt to steal their tokens, so OTP based MFA still has value for users who have re-used their passwords on your site.

The best case here is something out of band, like a Duo Mobile push, where the potential victim is also informed of the IP address trying to login (which likely isn’t in their region). If they’re not at keyboard, it’s extra suspicious.

Again — tradeoffs. Most people don’t have Duo Mobile installed, the Google Authenticator app is more prevalent. In most cases, the users probably has neither, which leaves something like SMS, which can also be attacked. Also, SMS deliverability is very poor, especially with international users.

Every decision here has a usability, reliability, or security tradeoff.

EMAIL CONFIRMATION

Image for post
Image for post

Notice the nuances. On the left, clicking the link verifies the user, giving opportunity to observe the user’s browser and if the user is actually on the device that initiated the login. These two individuals (good guy / bad guy) in this situation would have revealed that one does not have access to the victim IP and email account. If they differ — it could be a bad guy interfering.

However, this breaks if the user confirms the email from their cell phone, or another computer, which is the same characteristic of a phisher and is a false positive. This potential for breakage is a trade towards a very strict approach with better security and away from a good user experience.

On the right, we have a token the user will have to put into their game or website. This can still be phished by the attacker. But — it still gives opportunity to the potential victim that something is suspicious and greatly reduces the success rate of a phisher. This is more relaxed and a better customer experience while providing some security, and Steam has many other restrictions to support the tradeoff, like delayed trade restrictions.

The Steam marketplace has a complex fraud process based on many other signals.

In both cases, had I used a familiar device in my login history, I likely wouldn’t have needed to go through this process.

A huge downfall is if the user shared the same password with their email account which would also be compromised. The user is almost certainly out of luck. They will need serious support from their webmail provider to get back on their feet. It’s extremely hard to trust a user after that.

USER KNOWLEDGE

Image for post
Image for post

This “who is this?” check occurs after the password, but before a complete authentication. The user must prove that they know something about the internals of their account (in this case, friends!). You could lean on information from your own user data to challenge the user with a question that is only easy for them to answer.

The downside: targeted attacks. It’s very hard to prevent a dedicated attacker form learning this sort of info from real world channels. But, in a credential dump, targeted attacks would not scale to potentially hundreds of thousands of victims, so this defense has its place for specific types of threat.

SPF / DMARC / DKIM

Image for post
Image for post
PayPal’s DMARC policy using Agari

There are issues here, though. To have the most aggressive stance on spoofed email, you’d want a DMARC “reject” policy, asking the largest email companies to drop all email that you haven’t signed yourself.

This will break anything you’ve setup internally that sends emails on your behalf from marketing, recruiting, or sales vendors. All vendors that use your domain in email should be ready to handle DKIM by configuration, or it will break and another part of the company will come yelling at you.

So in most cases, companies will set a “quarantine” policy, which is a decent middle ground to sends them to the spam folder. As shown above, PayPal asks for a more aggressive approach, rejecting entirely.

“LINK SHIM”

Image for post
Image for post

By warning users that they’re about to view untrusted content, it’s a very easy way to stop casual phishing from your own content. This is only relevant if the phishing attacks are happening on your platform through messaging products. MySpace and Facebook launched this early on when they started experiencing account takeover based spam. It was a critical early defense during my time at Facebook when we started seeing phishing attacks launched from wall posts.

TAKEDOWNS

Image for post
Image for post

There are several companies that will “take down” phishing hosts that are clearly malicious. Here is a list. You use their API’s or email and report URLs to them to coordinate “takedowns” with the ISP hosting the content.

These companies costs vary greatly, but my experience is that you should demand subscription pricing and avoid any per takedown cost. Costs should scale with minor proportion based on your phishing volume as they should automate most of the verification and submission to blacklists and security companies.

If you have a very small phishing issue, this should be very cheap as their job won’t be high effort. The company should be incentivized in your security, and “per takedown” pricing is not a good model. Also, familiarity with the facets of your product being abused is important, instead of just focusing on email based attacks.

CUSTOMER SERVICE

Give support direct access to takedowns, build tools used to review and investigate suspicious account history, the ability to suggest and blacklist IPs or netblocks (be careful!), and to discover other compromised users. Make them soldiers against these attacks, and loop that feedback into defense automation.

This sort of manual investigative loop can feed into “State Sponsored Attack” alerts that you may have heard about. Manual review of an attack could discover a motive, which may warrant an alert to the potential victim. The information potential victims report to you is useful in discovering motive.

Image for post
Image for post

For instance, if 100 potential victims all report to you that they belong to a protest group, you may have some useful information to warn the other 900 with.

TOR

Image for post
Image for post

The tradeoff here is that companies allowing Tor turn on pretty much every available hurdle on for this experience. Most companies concerned with account takeover run similarly. Even if they don’t explicitly treat Tor as “bad”, any learning algorithm will eventually do so.

PROACTIVE RESET

This has a great network effect of warning users and ultimately protecting the larger internet from credential re-use. The challenge is getting a hold of the credential dump, which usually find their way through hacker forums eventually.

Check out Scumblr from Netflix to bootstrap engineering around this:

THIRD PARTY AUTH

Conclusion

Right now I am cheering on U2F, password managers, any hardware crypto for identity, and products similar to the Duo Mobile push. Even these solutions are incomplete. We face massive usability issues if we aspire to make passwords, and this article, irrelevant.

I really wish I knew how to solve that, but I don’t.

@magoo

Starting Up Security

Guides for the growing security team

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store