CVE-2014-4451 – Apple iOS bug allowing unlimited incorrect pin attempts

A bug that would allow unlimited incorrect pin attempts on any iOS device is enough to make a lot of people’s toes curl. Unfortunately that is what I found when I recently stumbled upon an iPhone lockscreen bug allowing me to do just that.

On the 28th September 2014 I raised a bug with Apple which later was assigned the ID CVE-2014-4451. Now that this has been patched in the latest iOS 8.1.1 I am able to release the details of how the bug was exploited. At this stage I do not have any devices running any iOS earlier than 8.0 therefore am unable to test if this affects earlier releases of the operating system.

The steps to reproduce are demonstrated in the following video I placed on YouTube:


I have yet to discover if this affects devices running iOS 7 or earlier, therefore if you have one of these devices and are able to demonstrate that the issue occurs on that release of iOS also please leave a comment here and let me know.

I hope that this information helps users become aware that they should stay up to date with the latest release of software wherever possible to protect themselves against such bugs.

I thank Apple for working diligently to resolve the bug as quickly as possible.



Thanks to @DarthNull on twitter, we now know this goes back at least as far as iOS 6

Shoeboxed Australia increasing prices from 1st June 2014

shoeboxed price increasesFollowing my recent review of Shoeboxed (in which I have to admit I was amazed with the service) I have just received an email indicating that price changes are coming and on the Classic plan which is a great plan for those of you that would like to use it for personal use, this brings an ~25% increase on the cost (you can see the full comparison table below).

I can happily say I am still loving Shoeboxed and will be sticking with them despite the increase. Shoeboxed has informed me (via Twitter) that it is their first price increase in four years and they will honour current prices for month to month plans until the end of the year (if you sign up before 31st May 2014) or annual packages until 30th June 2014. So if you have been considering giving Shoeboxed a try,  now is the time to get a trial, see if you like it and lock in an annual plan before the 30th June or the current monthly pricing until 31st December 2014. I personally feel this is a more than generous offer to lock in the current price for long enough to account for the price increase and a single price increase in four  years is not bad at all.

Shoeboxed does have a referral program which gets both the referrer (me) and referee (you) 10% off the price for 12 months and  (and yes if you click through to Shoeboxed from this post it will be as a referral) so that is one other way to get an additional discount for your first 12 months (and for me too :D).

So if you would like to give them a go, have a read of my review and give them a whirl. Now is definitely the time to lock in some cheaper prices.

Changes at a glance:

 Lite (<1st June)Lite New PriceClassic (<1st June)Classic New PriceBusiness (<1st June)Business new PriceExecutive (<1st June)Executive New Price
Monthly Price$19.95$16.95$39.95$49.95$99.95$129.95$177.77$249.95
Annual Price$199.00$169.00$399.00$499.00$999.00$1299.00$1777.00$2499.00
Per doc overage price$0.66$0.44$0.44$0.385$0.385$0.33$0.33$0.275

Full details of the price changes available on Shoeboxed’s Site


Could bugs like Heartbleed pose issues for biometric authentication?

Heartbleed and Biometric SecurityCould a future bug, with similar implications to that of Heartbleed cause major concern to the future use of biometric security? Following the critical Heartbleed vulnerability in OpenSSL, and reading countless articles online (see below for a few) an interesting conundrum came to my mind.

As we now know, there are three requirements to overcome the effects of the Heartbleed bug on any one server or service:

  1. Patch the affected software on the affected server
  2. Revoke and re-issue the SSL certificates (essentially the private keys used to encrypt traffic between two points such as the end user’s browser and a bank’s web server for example)
  3. Change your password for the affected service/application in case it had been compromised


The conundrum focuses on a problem with step 3 and the use of biometric security measures such as fingerprints, retina scans and potentially new vein-scanning technologies. While these technologies are not heavily in use by consumers today they are becoming more commonplace, many users of the new Apple iPhone 5s (myself included) use a fingerprint to speed up unlocking the lock screen and the potential uses are already on the rise as this technology becomes more mainstream.

Taking a high level look at this, from a pure sequence of events (as opposed to analysing how or where the biometric data is stored and/or transferred and how it may or may not be encrypted), I provide the following hypothetical scenario to consider. In 12 months time lets say you can use your fingerprint or a retina scan to get cash out at an ATM, or to identify yourself to your bank and other providers using your smart phone. The technology is in use for a period of time and after a while a bug with similar consequences as Heartbleed happens to be discovered. At that time there may be no clear evidence of whether the bug has been exploited or not, however this actually becomes irrelevant. Taking a worst case scenario, lets say despite the best efforts of the companies, the multiple layers of encryption and all the other security measures that one of the many supporting components of the authentication process has a bug which has, or could potentially cause your biometric details to be exposed, copied or intercepted.

As our primary form of authenticating ourselves today is using a password, we can simply change our passwords which invalidates the potentially compromised user credentials. As I am sure you can now surmise if we were using biometric authentication, we could not simply change our retinas or fingerprints, these stay with us for life. I will admit this is taking the extreme end of a worst case scenario, with any high level security solution, you would expect several layers of protection, but it definitely poses an interesting question of what can be done to invalidate and then re-issue a biometric credential.

Unfortunately I don’t have an answer, I do hope that this might promote some discussion or at least get the idea in the back of a few peoples minds. If anyone has any thoughts or ideas please let me know as I am genuinely curious as to the answer to the riddle. In the mean time, perhaps it is best for us to all strongly consider who we want to hand over our biometric “prints” to… if they are ever compromised you can’t simply change them.


Articles that prompted my thinking: