The internet has been a-buzz with the recently high-profile thefts of a lot of salacious celebrity photos. As soon as it transpired that iCloud was allegedly the source of these leaks – many, myself included, feared the worst – some kind of exploited, zero-day exploit in Apples cloud storage solution.

As it turns out, the vulnerability wasn’t really anything new, just a well coordinated and lengthy exercise in social engineering and password theft. It appears the data that was stolen and subsequently leaked online had been collected and traded over several months and obtained by gaming the password recovery and signup processes of iCloud, and presumably, several other online sites.

So how does it work?

It’s actually fairly simple – the hackers recover the passwords for the accounts of their targets, and then restore any stored files or device images. This is mostly achieved by identifying the valid email address of the target, and then gaming the password recovery systems.

The hackers first need to verify that the email they’ve been given is a valid login credential – they do this by brute forcing signup and password recovery pages on the target website – paying close attention to the login failure messages returned. If a failure message indicates that the login credential is correct, but the password is wrong, the hacker then has 50% of the information required to break into that account.

They’ll then use a social media driven attack on password recovery questions based on publically available (or privately sourced) data on the target, attempting to guess the recovery answers. If the site they’re targeting isn’t particularly security conscious, as a last ditch they’ll attempt to script a brute force attack to crack into an account. This can be very obvious, so it’s not a preferred attack vector.

Any data stolen can subsequently be used to break into other digital accounts owned by the target – people often use the same passwords everywhere, or if they break into an email account, they can simply password reset everything. Often any contacts or addresses stolen can be used to attack other targets – especially in scenarios where important people have been targeted where they can potentially learn contact information of other potential targets.

Avoid being part of the problem

Here are a few things that you can change in your software to make it less likely that your accounts are hijacked, or that your site is used to exploit somebody else:

Return generic “username or password invalid” responses to authentication failures

Your UX department will probably hate you for this, but it’s a very simple compromise – never tell a user which part of their login credentials failed. Simple by returning “Invalid Password” instead of “Invalid Credentials” verifies to a potential hacker that the email address they attempted to use is already registered.

Use usernames for authentication instead of email addresses

Using email addresses during authentication allows a potential hacker to exploit your signup process to verify a valid account. If your site returns a message like “Email already registered” you are confirming the existence of a user account that’s open to exploitation. You can potentially mitigate against this by returning a more generic “Email not allowed” but often even that is enough of a positive signal to a potential hacker.

Ensure authentication attempts are rate limited

This is really anti-brute-forcing-101 – don’t let people repeatedly submit a login form without slowing them down after a few failed attempts. Once you’re in the region of 5 or so failed attempts, it’s perfectly acceptable to start making users complete CAPTCHAs – google offers recaptcha for free – use it. This is a UX compromise, but so long as you only flag suspicious traffic you’re not going to inconvenience many real users. Make sure that your CAPTCHA implementation doesn’t rely on cookies or other client side state – people writing tools to brute force logins will simply not respect them.

Ensure API authentication attempts are rate limited

Similar to using CAPTCHAs in your website – make sure any API authentication methods are similarly rate limited. The simplest implementation is to start scaling the time a login attempt takes based on the number of failures. For 1-10 attempts – allow the user to login as fast as they can, but after that, start artificially slowing your response times after every failed request from a given IP, client or key – preventing brute forcing your APIs.

Ditch all those “password recovery” questions

There aren’t many good ways to deal with password recovery – but the obvious one is to use SMS verification based on real phone numbers. Allowing people to recover accounts based on personal details that are easy to Google is crazy. If the answers to your password recovery questions are available on your users public Facebook profiles (date of birth, mothers name, place of birth, first school, etc) then you’re just letting your users fall into the pit of failure by accepting them as security questions. Prefer verification by phone or SMS – there are great services out there that make this easy so prefer them over perpetuation the “password recovery” problem. Alternatives to this are accepting “recovery email addresses” like Gmail, and verifying a small 0-99p charge made to any registered credit card.

If your users refuse to give you contact information to recover their account, don’t, under any circumstances, hand the account over.

Don’t enforce restrictive password requirements

Enforcing silly “0-9 characters, alpha numeric and at least one special character” style password requirements absolutely reduces the attack space for a password hack and opens your site up to simplistic brute force attacks. Encourage users to set long passwords, or jumbled pass phrases. We know passwords aren’t great, but they’re what we have – so the longer the better.

Don’t store passwords in either clear text or a reversible hash

Whilst not directly related, please remember that any kind of clear text or reversible password hash is a terrible idea – if you’re compromised, there’s a good chance that your users passwords will be stolen and used to attack more important online properties they own. Play nice, use something like bcrypt.

In the vast majority of cases of “hacking a user account” data made publically available is used to exploit a third party site – so lets all play nicely and protect our users together, lest the data stolen by something even more valuable that humiliating or salacious photos.