Nude Celebrity Scandal, Cloud Service Security and You!

September 04, 2014

Following the slew of private celebrity photos leaked earlier this week, both end-users and organisations are understandably concerned. Invariably, user confidence in the security of online services, and the confidentiality of any data stored, has been shaken by such leaks.

This is especially worrying for organisations, as more and more enterprise services move onto remotely hosted cloud platforms, which are now home to the corporate crown jewels (emails, commercially sensitive information, intellectual property etc).

The same security issues that appear to have caused the recent iCloud breaches typically affect these cloud platforms. From a security perspective, using a cloud system is effectively outsourcing and therefore should be treated as diligently as any other outsourcing arrangement.

According to Apple , the recent celebrity photo compromise occurred due to a “very targeted attack on user names, passwords and security questions” – in other words, social engineering password resets.

Ultimately, this type of attack in some form or another affects all systems that are targeted at individual end-users and unfortunately there is no magical solution for this.

That said, there are some initiatives which organisations can put into place in order to reduce the likelihood of these attacks, both against internal cloud-based systems, as well as for users:

  • Design password requirements intelligently – Password security requirements are a complex beast. However, make password security requirements too complex and people will inevitably use the bare minimum to comply, such as “Password123!” and not an inch more.
  • Use Passphrases – Passphrases (obligatory xkcd: ) are strings of words, used in place of a password. These are easier to remember, because they typically make some form of logical sense to the user (e.g. “will I hate this system?”) whilst being long enough to reduce the chance of being trivially guessed.
  • Secure Password Reset – Designing password reset functionality can be a little tricky and often becomes a balancing act between usability and security. One of the most common security issues with password reset functionality is that it offers an unlimited number of attempts. Effectively, all this does is shift the risk of a brute-force password guessing attack from a user’s password to a user’s password reset information (which typically has a smaller search space – it’s easier to guess the city a user was born in than a 8-character-plus password).
  • Enforce Two-Factor – Two-factor authentication is where you need something else to log in, such as a physical token (check out Yubikey), or an SMS sent to your phone. Typically, this “second factor” will give you a one-time token, which is validated on the server side for each authentication. You can do this as a one-stage or two-stage process: that is, you can require the “second factor” after a valid username and password has been entered (like Gmail), or you can require the one-time token to be entered at the same time as your username/password (like some online banking apps).


Two-factor authentication with Gmail, also available in Google Authenticator form ( ).

  • Monitoring – With the case of recent iCloud breaches – if any accounts were compromised via password guessing, Apple should have been monitoring logs. With the proliferation of alerting and log monitoring tools, organisations should always keep an eye on their systems, which provide warnings of attacks.
  • End-users can help too – By providing notifications of failed authentication attempts (e.g. “there have been 2667 failed authentication attempts since your last login at 7pm on Tuesday”). They also provide an easy way for users to report account compromises (e.g. “Not you? Click here to contact Security”) and so users can help you in monitoring attacks against their own accounts.
  • Delegate authentication – Don’t get me wrong, delegated authentication (sometimes also referred to as “single sign-on”) is difficult to do correctly and can potentially present a lot of attack surface. However by reducing the number of passwords your users have to remember, you make it easier for your users to remember a single strong password, which can then be used to identify that user across a number of systems.
    According to anecdotal evidence, this can also prevent users from re-using passwords to an extent, as there is less incentive for users to use easily-derived (and thus, easily-guessed) passwords across a large number of systems, if they only have to remember one.

It should also be noted that user education also plays a big part in securing authentication. Security controls are useless, if your end-users aren’t using them properly. Adequate education can ensure that users:

  • Don’t re-use their passwords
  • Don’t make their passwords predictable (e.g. “My password is $systemname” for a passphrase)
  • Don’t put their passwords on a post-it note, stuck to their monitor
  • Know how to spot the signs of an attack or compromise (e.g. last login time, etc)
  • Know what to do when they feel their password has been compromised

As always, there is no magic bullet solution for security. That said, these suggested controls, in conjunction with strong application security controls, secure development practices and educating your users, can be used to contribute to the overall security of your applications, as well as your data and that of your users.

Further reading:

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *