NMandelbrot : Clients gaming the system

There’s a glitch in the data

In any system with clients outside your direct control, you will be subject to Rule 1 of network security : Don’t trust the client. For the Mandelbrot Set, the worst that can happen to the result is that a few pixels go astray, provided the input is properly sanitised to protect the server.

For more complex calculations, where the data matters, it may be of interest to some parties to try and skew the results. In the Search for Extra-Terrestrial Intelligence hack, for example, participants were claiming credits for work not done, or submitting bad data, so some verification of the result is required, which can either be done on the server, or by submitting the same work to multiple clients and getting them to “vote” on the result, which requires a much smarter reduce algorithm than is available in the sample code.

Note that securing the client code (e.g. by obfuscation or delivering a non-JS payload to execute the algorithm) is no defence, given that there must be a globally accessible service for the clients to talk to in order to get any data back. The channel itself can be secured, providing you don’t trust the encryption for long, but even with client-side security, such as an SSL certificate, as soon as the code leaves your server, you no longer have any guarantee over it. Given the importance and sensitivity of your data, that may or may not be a problem.

Anyone who doesn’t validate all inputs on the server is handing the keys to their attacker*, but when you don’t know what the input should be (otherwise, why do the calculation at all), you have to find a way to build trust. Maybe each client gets tagged with an id, non-traceable to a user, and the validity of responses from that client can be measured over time to give a trust rating, allowing the voting to be weighted to prefer results from trusted clients, assuming there is a mechanism in place to lose trust if a client is compromised.

Maybe the payload includes some hidden data, a known, non-repeating, throwaway result (similar to a 2-factor authentication token) whose only purpose is to validate that the client is responding correctly, but is otherwise indistinguishable from real data.

There’s no one solution to fit all situations, and the server and client cost of the solution will be correlated with the importance of the data, up to the point where the data, even in a subset, and even with protections, is too important to be opened to untrusted machines.

There are many other client-side attacks or mitigations I have missed, so feel free to add your own suggestions below.

* Note : you can do client-side validation prior to sending to the server for usability reasons, but not for security.

Advertisement

I don’t trust change

Everything changes

I don’t trust change. I know change is what we do, it’s why people need new software to do things they couldn’t do before, to sweep away the cobwebs and start everything anew. To change. For the better.

The better what? Faster, more efficient, more user friendly. “Just better”. “An improvement”. “The new shiny”. “Make it cool”.

Great, can you write me a requirement for that, or some acceptance criteria?

“We’ll know it when we see it.”

But how will we know?

“It doesn’t matter. We’ll know.”

And when you come back and say it doesn’t have enough “zing” or “pizazz” or isn’t “cool” or “new” enough?

“Well then, it shows you didn’t listen to us.”

A change for the better?

If you want to change, you should know why. What will the users notice? What pain will it take away? What will it allow you to do that you couldn’t do before?

Those are questions I can pick away at, questions with an answer where I can measure something tangible. I can change the time it takes to do something, I can change a system to do something new, and I can show you exactly what the change looks like.

A change without a diff is a break.

If you don’t know why you’re making a change, the chances are, you’re making the wrong change, and you won’t know when the change is done. Make a small improvement, or a big one, but know why. If you can’t articulate the difference between the present reality and the desired future, all I can tell you is that the change will break. It might be beneficial, it might not, but there will be no way to trace from now to the future, and no way to know if anything has improved.

The best change may be no change

We love writing software, coming up with new ideas, new approaches. We want the new shiny. But that doesn’t mean it will do us, or our customers, any good. Angular.js makes it much easier to write web apps a certain way, but is that the type of web app that most suits your customer, and do they really need a web app at all? Is a web page easier for them?

And maybe what needs to change isn’t the software. Maybe there is a process that people have forgotten that will fix the problems, maybe they’re solving the wrong problem.

Software isn’t always the answer, and neither is change.

When to embrace change.

Change when things cause you pain. Subversion makes branching and merging painful. If that’s a problem for you, try git or mercurial. Manipulating the DOM from a callback is painful. If that’s a problem for you, try Angular or another framework. If they’re not causing you pain, chances are something else is, go change that first.

Change when there’s a functionality gap. When you’re chasing a new regulations, new APIs, new competitors, or new customers. And make sure that functionality does something to help close that gap. You might have a few ideas, so pretotype and prototype them first, make the change as small as possible, and build on it, because a small change is easier to throw away, physically and psychologically.

Embrace change.

But don’t trust it, until you know where you want the change to take you, and you have a way to check you’re on the right path.

HTC One Mini vs One Mini 2

As a wee aside, and because my last post about an HTC phone was one of my most popular, I wanted to do a quick follow-up to my last post to talk about the phone.

I had an HTC One Mini that stopped responding. It was an ok phone but was often slow and occasionally crashed. When it finally died, within warranty, I sent it back to HTC for repair. I was told I’d get an update within 2 weeks, and on the 14th day after it arrived at the repair centre, I was told they had to send off for a new part.

2 weeks after that, I found out the new part was an HTC One Mini 2, which is one of the stupidest names for a phone I’ve come across. At least the Hero, Desire and Incredible made some kind of aspirational sense.

Having lived with this new phone for a few months now, I do prefer it to the previous phone, but I can’t recommend it.

It’s faster, runs cooler, and lasts longer than the phone it replaces, but the camera is very very bad. That was one thing the previous phone got very right : a responsive camera, that took reasonable pictures. This one is not an UltraPixel camera so the pictures are grainy, the shutter speed is only good for completely stationary objects, and the pictures take far longer to save than they ever did on any previous phone, even when they were saving to cheap sd cards.

More than that however, in fixing the crashes, the software updates have left the phone in a state where it constantly needs rebooted (often via the power+volume-up combo) as the lag time gets intolerable.

I’ve now had 4 HTC phones, and this one will definitely be my last. I’m not sure where to go next though. Maybe LG, maybe Motorola, possibly Sony.

Any recommendations?

Losing tokens : 2 factor authentication recovery

Use your palm to sign in

My phone broke. I lost access to Google Authenticate and the second half of my two factor authentication.

It was a great opportunity to look at how each of the main services deal with recovery. I’m always looking to increase the baseline of security in every new body of work, and 2-Factor authentication is one interesting avenue, but has a big potential failure scenario. I want to look at how the services deal with this to understand the trade offs.

For those of you unfamiliar with the concept, authentication is generally performed by one of 3 factors : something you know (e.g. a password), something you have (e.g. your car key) or something you are (e.g. fingerprints). 2 factor authentication asks you to prove your identity via 2 of these channels, rather than one, and often chooses the something you have and something you know channels because of the difficulty of replacing the something you are channel if the security is compromised.

Most of the services I discuss here use Google Authenticator which uses your phone as the something you have, seeded with a shared secret (usually encoded as a 2d barcode) to generate a new code at regular intervals that should appear random to any observer but always consistent between server and client.

Many of the services use one-time codes to allow you to log in if you lose your device, and some force you to enter one of those codes as part of the verification process. For all those that provide it, print out those codes as soon as you get the option, and keep their printout safe not near your phone.

The services

Google : provides a set of 10 one time codes. An email when any is used. Easy migration process to a new device, automatically disabling the old device.

Github : sends a text to my phone. Not so good for a stolen phone.

WordPress : a set of 10 one time codes, but no email indication, when one is used. Frustratingly I have to disable and re-enable 2FA to move to a new device, rather than WordPress disabling the old device automatically. Although it does have the nice side effect, unlike Google, of emailing me to let me know a new device was added.

Twitter : temporary password, with 1 hour expiry, provided you’re logged in on another device. For most services this should not be a problem, but it’s a good reminder to ensure you always have more than one trusted device for an account so you can create new trust relationships and disable old ones.

Dropbox : can re-enable authenticator via barcode, if logged in on another device. Email is sent.

I like the Google and WordPress approach for simplicity, if you’re organised enough to use paper as you’re backup device, but I’m comfortable with the approach taken by Dropbox and Twitter that use another device for the authentication.

Conclusion

I don’t like the Github approach, because it fails to recognise the use of the phone for multiple purposes, making a phone much more valuable a target. Luckily my phone was bricked, but I continue to monitor my accounts for suspicious activity, just in case it comes back to life now I’ve been sent a replacement.

I like notifications. I get email notifications on multiple devices and as they are timely, I know immediately if there are unexpected changes. Good marks for Google and WordPress here, but I wish Google sent emails for enabling on a new device and WordPress sent emails for use of one time codes.

I prefer the one time code approach for the way I like to work but I can see the benefits of the multiple trusted device approach. I can’t see any benefits to the github recovery approach apart from simplicity.

2 factor authentication is good, but check your recovery strategy now. I only got back into my accounts because I was prepared.

Further reading

★ : Two-Factor Authentication Hacked: Why You Shouldn’t Panic buff.ly/1wukaiE

Be sure you have a backup plan, for Apple and others. I almost lost access to some of my accounts because I misplaced my backup keys, similar to this guy.

If you lose your phone, or are scared you will, have a look at this Lifehacker guide before you enable 2-factor authentication on your accounts.