Category Archives: Security

We need more encryption and security, not less

The linked article shows just how trivial it is to use metadata to identify the entity associated with the connecting device and start to unpick further details of their life, work and the supposedly secure stuff they’re working on.

Security, a thought for the day

If the ‘good guys’ have a backdoor then so do the criminals
If the ‘good guys’ can crack your encryption, so can the criminals

Having weak encryption would not have stopped the Paris attacks as the security services had already stopped monitoring them.

If you think “I don’t use encryption” then think again, when you bought something online you used encryption, when you made a mobile phone call encryption was needed to protect the setup of the call, your password is stored (or should be) in an encrypted format to prevent hackers from simply downloading a human readable list and so on. Encryption isn’t some dark evil used only by terrorists, it’s used by all of us for good reasons. The government needs to give better reasons for denying it to the public than “terrorists!!”.

Alternatively maybe they’ll be happy that all their governmental and private communications are no longer encrypted to make the job of the press easier in reporting on their deeds and misdeeds, for surely if they have “nothing to hide they have nothing to fear”

Authenticator change, let’s follow the money

Been pondering and I think I’ve come up with a reason for this apparently stupid change which has no visible driving reason, no screaming customers, no mega threads on the official forums (or indeed on blogs) about how terrible it is to keep entering the authenticator numbers.

Nothing which really explains why they’ve made the change.

So, let’s fall back to the standard in any business or political field and follow the money.

Authenticators, how they work

Authenticators are a third party product which are made and branded for Blizz by Vasco, functionally they’re pretty much the same as the RSA secureID system which many people will have encountered in a work environment or indeed to the systems which many banks are rolling out to their customers for online access security.

At the backend these systems tend to be the operators own authentication system, coupled with an API provided by the security vendor and hardware authentication boxes (HSM in my field, hardware security module) which do the heavy lifting of actually performing the security check on the supplied number.  Each of these machines as a finite capacity in terms of queries per second, usually some reasonably aggressive support contract response times (let’s face it having your auth system down is a bad thing) and often a license fee based on the number of queries over a set period (for example 90% of the peak value measured over the month).

All of which means $$$ to Blizzard, and the bad sort.  It’s money heading out to Vasco.

We have a trail.. let’s follow

The problem Blizzard face is controlling the costs incurred by the security system, something which is funded mostly out of reduced support costs (less compromises and clean up).  However that’s rather intangible and doesn’t keep the accountants happy.  From an opex point of view the authenticators are an overhead and one which is increasing with time, from a risk perspective there is a chance to reduce the load on the HSMs without significantly increasing the changes of a compromise.

If we look at the entire bnet customer base and extract information on accounts which have been compromised, then pull out the numbers for those compromised with authenticators and then further filter factoring in ‘location’ information based on IP.  Then I suggest that accounts which have an authenticator, log in from a ‘regular’ IP and have been compromised from that IP is a tiny fraction of the total.

Therefore altering the authentication mechanism such that it only checks for an authenticator value once ever “n weeks” or “z logins” when the auth is coming from a ‘regular’ location (defined as “the account has logged in from this location successfully using the authenticator Y times in the last P weeks”).  With some reset mechanics thrown in to drop back to full security checking when there has been suspicious attempts.  Then from the corporate point of view this is a good trade off.  It lowers the load on the HSMs, it cuts back the licensing / support costs without greatly increasing the support costs in dealing with a higher load of compromises.

Additionally we have Diablo 3 on the horizon which means fresh players, fresh authenticators and additional load on the system.  I have no doubt that the current bug which causes players to be kicked out when changing toons forcing a fresh login has also had some impact on their usage stats which might have triggered them making this live ahead of schedule.

Customer expectations

This is the big fail from Blizz, they’ve been banging the account security drum for ages, with good reason.  It’s bad PR for customer accounts to be hacked regularly, encourages criminal activity and generally annoys the paying customer.  Annoy them enough and they’ll go and get their MMO crack from somewhere else.

The biggest fail was rolling it out, letting the “good location” database populate and then stop asking for authenticators.  Which as any geek with an ounce of security sense would have told them will have normal players panicing.  The system changed, it changed in a way which the players have been told means an account compromise.

Stupid, massively predictable and stupid

If Blizzard needs to fix one thing it’s their internal processes and communication.