NMandelbrot : Clients gaming the system

Mandelbrot set with suspicious lines
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.

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
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.

Is your CPU time there to be stolen?

Or can it be bartered? If you were given the choice between giving up cpu time, giving up privacy, or giving up money, to reimburse a developer for their time, which would you choose?

If you don’t feed us, do we not starve?

RT @ppinternational: uTorrent client is stealing your CPU cycles to mine #bitcoin http://t.co/g7z3y9AjGe http://t.co/SHpfQuOsdY http://www.engadget.com/2015/03/06/utorrent-bitcoin-miner/

The Monty Hall problem

image
One of these things is not like the other

There’s a bit of a meme going about trying to explain The Monty Hall problem. It’s an interesting statistical problem because the result appears at first to be counterintuitive.

The basic formulation comes from a game show, where the final round consisted of three boxes, and behind 1 is a car, and the other 2 are goats.

If you pick the car, you keep it.

The complication in the setup comes from the host, Monty Hall, who, after you’ve picked a box, opens another box to reveal a goat, then gives you the opportunity to stick or swap. The question is, in a statistical calculation, should you switch?

The naive answer would suggest that as there’s only 2 boxes left, there’s a 50/50 chance that you’ve chosen the car. But that formulation misses the important facts that you choose a box first, and you are always shown a goat. There’s a lot of descriptions that show how the possibilities collapse with numerous branches to show that in 2/3rds of cases, it pays to switch.

There is a simpler way of thinking about the solution. In 2/3rds of cases, you choose a goat. Since Monty had to reveal a goat, changing your mind guarantees you a car in those cases. In the other 1/3rd, you picked the car in the first case.

Sometimes statistics is unintuitive because you have the wrong model, and users can’t see the wood for the decision trees. There are good reasons for some faulty models to exist, but these should be corrected and challenged.

Can’t patch, won’t patch

As a software developer, I take a keen interest in the platforms I am developing on, as that’s often the one thing I have least control over, given that the customer will ultimately be installing in their environment in most cases.

As a Windows developer with an Android phone, this story particularly interests me from a security perspective. I don’t want to have to target a moving platform, but equally I don’t want my software compromised by the security of the system it runs on, so having developed and supported projects under WIndows (mainly web via IIS, and IE on intranet) and Android, the recent spat between Microsoft and Google over security exploits and Google’s “Project Zero” has been of big interest to me.

Patching my thumb with gauze
Patching my thumb

The Microsoft bugs mentioned in the posts show how responsive a company needs to be to stay on top of security. For a product as big as Windows, 90 days is not much time to implement and test a fix. Microsoft obviously want to make their job as easy as they can to get those fixes out quickly, so they officially only support patches for users running up to date versions, including service packs. Their support for Windows expires if you haven’t updated for 2 years, and for most of their consumer software if you haven’t updated for 1 year. (note that Windows 8 is supported well past 2018, but only if you’ve been installing the free service packs).

Google’s problem with Android is that it has been open for OEMs to adapt for their platforms, at which point it is no longer Google’s Android. Whilst Google has worked to minimise the things that OEMs can control, including moving the WebView component at the heart of the flaw into Google Play in Android 4.4 and higher, the platform is still reliant on OEM support as much as, if not more than, Google. That is pretty much Google’s position, that the handset manufacturers need to update to a more recent platform, or submit a patch for Google to distribute to all the OEMs.

So if you’re stuck on Jelly Bean, you now have to either rely on the support commitment the manufacturer has to a handset that is no longer making them money, or use the open nature of the platform to install an alternative Android, not provided by the OEM.There are workarounds using other browsers, but they rely on users understanding what webview is (and potentially disabling WebView in all the apps, like Facebook, that use it).

Google seems to care deeply about server-side security and was seemed genuinely angry about the NSA breach between their data centres, but their record on the client side isn’t great. Android permissions, and Chrome passwords are two key examples. Microsoft’s “Scroogled” campaign attempted to cast to same doubt on Google’s cloud security, and was partially successful, although Microsoft’s successful certification of Azure to ISO-27018 is a far better card to play in this battle.

Google’s Project Zero is definitely a good way to set a rising tide of security, and is an essential part of the response we need to the Heartbleed and ShellShock exploits from last year, and the ongoing revelations about back-doors that spy agencies around the world have discovered. Google is not immune from the rising tide, and has fallen foul itself in meeting good practice. Microsoft seems to be their biggest critic in this area, but it’s been firing blanks, whilst open source vendors have been busy patching and moving on.

As a user, I know hackers are working to find exploits, so any exploitable discover has to be disclosed, to those who can fix it first, and to the rest of the community in a reasonable time, so that users can protect themselves. The problem with disclosure only comes where there is no possible means for the average user to defend themselves, which is precisely the problem with the above exploits. Usually, “Open Source” is given as the answer to empower users, but in this case, open source isn’t enough to get Android fixed. That’s still no reason to hide the exploit however, as users need to know if they need to protect themselves, especially if the solution is to avoid certain apps or websites.

Do you think Project Zero has demonstrated responsible disclosure?

Keep it Simple, John Sonmez

I’m trying to build a better blogging habit, after following John Sonmez’s blogging email course. I started following him, and his Simple Programmer blog, after I saw a review of his Soft Skills book on Christos Matskas’ blog and thought it was something I needed to know more about.

I’ve been presenting and blogging for a while, since I realised that my technical skills were a necessary but not a sufficient condition for a fulfilling career, because the soft skills open the doors to the greater challenges of customer and team relationships, and greater responsibility. Communication and explanation are becoming more important right from the start of a developer’s career however, as more companies move towards adopting portions of the agile manifesto and encourage greater interaction between the technical and the business owners, as well as expecting a much higher degree of collaboration within teams,

For those of you just starting out, or those looking to jump things up a gear, the course lays out some great motivation and practical steps to get you set up, and start building up your soft skills by communicating.

Blogging may not be for everyone, but I don’t have much faith in a software engineer who can’t clearly communicate their ideas. So if you don’t currently blog, vlog, present or attend Guided Conversations, today is a great day to start.

If you’ve just started, please feel free to include a link to your blog, YouTube channel, or other communication forum below. Part of the soft skills are about collaboration and sharing.

Speech and Science

Just another WordPress.com weblog

Rough Copy Media

media analysis / with added swearing

Simple Programmer

Making The Complex Simple

How To Tutorials

PHP, ASP, .Net, Linux, SEO

ZenScript

My eBooks are available at Amazon Worldwide

JamesRadcliffe.com

James Radcliffe, Musician. Music, Blog, Pictures, Live, News...

The Code Club Blog

Adventures in Teaching Kids How to Code

The Inner Donkey Sanctuary

Taking care of my inner donkey since 1977

Stack trace ramblings

Just another WordPress.com weblog

The DIEM Project

Dynamic Images and Eye Movements

Voidspace - Cyberpunk, Spirituality, & Python

Just another WordPress.com weblog

the HabitForge blog

Simple Accountability. Positive Change.

James Wiseman

Mainly programming, with a bit of science thrown in

codeface

on making software

Don Charisma

because anything is possible with Charisma

Kendall F. Person, thepublicblogger

original performance art with an imagination to change the world

THIS DAY, THIS SONG

Discover a new song every day

Scottish Games Network

The home of the Scottish Games Network

Follow

Get every new post delivered to your Inbox.

Join 1,553 other followers

%d bloggers like this: