Tag Archives: Apps

“Borderline bulletproof” security for API keys

In episode 5 of my Keep in Touch podcast I shared some thoughts on how I currently think about protecting credentials, API keys, and secrets (summarised as keys for the rest of the post) for 1st and 3rd party services and APIs. This blog post is a recap of those ideas and also a call for feedback and input from you.

The risks

The problem I am talking about addressing, is related to the fact that many applications embed keys in their binaries. These keys are required to authenticate (and authorise) the app, the user, or both with remote services. These services could be public or private APIs. Similar considerations apply if these APIs are 1st party or 3rd party.

If these keys are bundled with the app, a nefarious attacker could extract them and then impersonate the developer.

It’s not my intention to teach bad actors how to execute their plans, but I do want to give a few examples of some attack vectors that could lead to sensitive information falling in the wrong hands:

the nightmare scenario: the attacker could run a man-in-the-middle attack by running a WiFi hotspot or could be operating one of the nodes on the internet between the device and the APIs the app connects to
the easier than you’d think scenario: the attacker could run an on-device proxy (such as the brilliant Charles for iOS app that I use daily for non-nefarious reasons), and monitor all traffic
the attacker could grab the app binary (ie. apk or ipa) and do a string search for key-like strings
Any of the above could lead to the attacker obtaining the keys that the app uses to authenticate itself against remote servers. Once they get these keys they can start impersonating the app and its users.

The hypothesis

I believe that by not including any keys in the app’s binary and by provisioning these credentials only via a channel owned by the operating system that uses SSL pinning, the risks mentioned above can be reduced or even avoided.

SSL pinning is essential in order to prevent an attacker from inspecting the traffic between the client app and the remote endpoints.

Animated GIF showing the way keys can be securely transmitted from cloud to app to server. This flow is described in detail below

This animation attempts to illustrate the approach I am suggesting:

Provision the app without any keys
Attempt to detect if the app is running on a jailbroken / rooted device, and bail if that is the case
Upload the necessary keys to the Trusted Cloud provided by the Host operating system (i.e. CloudKit for iOS apps) using another app (i.e. console, browser, etc)
Enforce read-only access to these keys for the client app
Upon (first) launch, fetch the keys from the Trusted Cloud
If the keys must be stored, only store them in a keychain or in a secure enclave
Use the keys to communicate with the Server using an SSL pinned connection
Should the keys become compromised, they should be replaced, and the client apps should naturally fetch the new keys. For this reason, getting the new keys should not require the previous keys.

The steps above rely on the fact that the mobile OS provides a cloud service that uses SSL pinning in order to communicate to the client apps. Without it, there cannot be a secure key provisioning mechanism and the entire flow falls apart.

The checklist

Often times the security considerations come in “late” or “after the fact”. To assess the state of affairs, and to add more protection going forward, I would go over the checklist below:

Limit the number of people who have access to the credentials. Replace the credentials when these people leave the job.
Never embed the keys in the codebase
Never grant the build (or distribution) servers access to the keys
Only trust the cloud service that belongs to the platform vendor for your app (i.e. CloudKit for iOS apps, Firebase for Android apps.)
Avoid storing the keys anywhere (on the device) unless really necessary
If the keys must be stored, then the only acceptable place is the Keychain
Avoid bundling black-box libraries. If the libraries use networking, inspect all networking traffic
Do not use a 3rd party networking library unless absolutely necessary. Always check the source code of such libraries
Never be the largest consumer of any one technology, framework, or library
Only load the keys at the code level that really needs them. Do not pass them through the business layer, particularly if there are 3rd party analytics or logging libraries bundled with the app
Obfuscate the code and avoid obvious naming strategies for the keys
Check the app’s signature / hash or anything else similar that guarantees that the binary has not been tampered with
Be mindful of jailbroken or rooted devices but never change the code in order to support them
Do a quid-pro-quo vulnerability analysis with a trusted partner (make sure dinner or beer is something at stake if an issue is found)

If you have more to add to this list, I would love to hear from you!

Closing comments

I think of myself as a security minded person, but I am by no means an expert. I offer no guarantees that implementing the steps above is going to remove or prevent any security related problems for a system I have not seen before, but, based on my current knowledge, I do believe it is the closest thing to a “borderline bulletproof” approach to securing keys and credentials that native apps use.

Lastly, I sincerely hope that, if you read this and have identified a flaw in my reasoning, or if you can spot an oversight, you will share with me (ideally with a solution in tow) so I can update the article.

#JAFAC – Don’t Miss It Next Time

I had the privilege to speak at the very first edition of #JAFAC hosted at the fantastic GRIDAKL. Many people requested that speakers share their slide decks. Since there’s nothing sensitive in mine, I’m able to post it below.

During the interactive part of the talk I mentioned a number of apps. Some these (iOS) apps were: Air NZ, Amazon, Chirp, Drafts, Emoji++, Evernote, Garageband, IMDb, Instagram, Instapaper, Kibo, MacID, Musixmatch, OmniFocus, Overcast, Slack, Starbucks, Trello, Way2Ride, Workflow, and Trade Me.

I didn’t know what to expect when I was invited to take part in this event. I have a lot of respect for the people who put it together, so I went. This tweet right after the conference pretty much sums up my experience:

Thanks #JAFAC for:
– letting me get away with a technical presso
– teaching me quite a few things
– helping me meet awesome people
E noho rā

— Nick Parfene (@nicktmro) April 23, 2016

I came back reassured, inspired, and motivated. Thanks Sandy, Brenda, David, Steph, Jimmy, Christine, Te Miha, Richard, Colart, and everyone else I had the pleasure to listen and to talk to.

It was also very impressive to see just how knowledgeable were all the people in the attendance. Day two, the un-conference, enabled all of them to play a more active part and turned into such a revelation.

“Coaching Leaders” session with Stephanie BySouth. Part of un-conference on day two

If you focus on enabling people to work together successfully, if you are all about empowering teams, if you are keen to find ways to remove needless processes, if you want to learn on how to use feedback properly, if you desire to be in the company of really smart (Agile) people, then trust me, you don’t want to miss the next edition. In the mean time, I’ll leave you with a quote from Sandy: “no pain, no Spain”.

AirPlay Speakers. A SONOS Alternative for iOS Users

I have been jealous of my friends sporting SONOS setups for a while now. My reasons for not jumping on the SONOS bandwagon are not limited to just the steep prices that the SONOS speakers come with. The reality is that I prefer to use my own music / sound playing apps and because I listen to podcasts for a considerable amount of time. In this blog post I will describe a cheaper and more flexible alternative for achieving the multi-room setup that SONOS is praised for, using AirPlay enabled speakers.

Scenario

In this article, I’ll describe my actual home setup. I need at least three speakers: two for my lounge area and one for my office. I wish to be able to play music and podcasts (via my Overcast, my preferred Podcast app) to either speaker independently or to all speakers simultaneously.

The SONOS Ecosystem

Pros

SONOS PLAY:1

Part of the SONOS promise is that you can easily and painlessly play the same music in multiple locations (rooms), using speakers that “play nice” and “just work” with each other. I believe that SONOS does deliver on this promise.

Scaling the SONOS setup is trivial, all that’s required is buying another speaker and adding it to the setup.

Cons

I have three main reasons to hold back from buying into the SONOS ecosystem:

SONOS speakers are quite expensive (arguably they do have very good sound)
They require the use of the SONOS app
Integration limitations

Now that Apple Music is available for SONOS my third reason is all but gone, but I have to acknowledge that this may not be your case if you prefer streaming apps that are not available in the SONOS app.

Cost

The cheapest speaker is the SONOS PLAY:1. It costs for $199. A high-er end SONOS PLAY:5 speaker costs $499. The SONOS SUB Wireless Subwoofer and the SONOS PLAYBAR TV cost just under $700 each.

The AirPlay Solution

Pros

iHome iW3

My needs are quite specific, therefore some of these pros may not apply to everyone.

AirPlay is available to any app (it’s a global iOS setting). It’s also easily accessible from the iOS Control Center
Big choice of speakers (most are budget friendly)
Old Airport Express units can turn any speaker with Line-In into an Airplay Speaker
Very easy to use as external speakers for Apple TV
Can stream the sound from any of my Macs (iTunes even has support for multiple speakers)
Most speakers have Bluetooth too, thus making them really good travel companions (to locations where WiFi is not available)

Scaling the AirPlay setup is not too difficult, after adding another speaker to the setup, there’s an option AirFoil configuration step.

Cons

The initial setup is more complex than with SONOS. Usually it requires joining an adhoc WiFi network provided by the speaker, followed by entering the local WiFi settings which enable to speaker to join the local network and become a wireless speaker for any AirPlay device.

SONOS speakers can easily turn into a 5.1 setup when enough speakers are added to the setup. AirPlay speakers haven’t really solved this, yet.

Cost

One the the most affordable options is the iHome iW3 AirPlay Rechargeable Wireless which retails for $49.95!

The audio aficionados can splash out on a Bowers & Wilkins Zeppelin Air Wireless AirPlay Speaker Dock. Amazon sells it for $420 at the moment.

I happen to have a Mac that is always on at home, so I decided to also purchase AirFoil. This has enabled me to group my speakers into “rooms”. The Mac version costs $29.

Alternatives

Bluetooth

Most people will probably just use Bluetooth, and that’s ok. Not everyone needs the lossless audio that SONOS and AirPlay offer.

AirPort Express

As I mentioned above, an old Airport Express can turn an existing speaker into an AirPlay enabled speaker. Check out Apple’s refurbished store for a deal on AirPort Express units or buy from Amazon for $29. You don’t need the current generation one.

Android

There are apps out there that allow Android to tap into AirPlay. I am not familiar enough with them, and I suspect the new Chromecast Audio may actually be a more suitable solution. Chomecast Audio sells for $35.

Conclusion

I implemented the AirPlay solution for myself and I’m happy with it. I’d love to hear your thoughts, especially if you prefer an alternate setup.

DevMob 2014 – Epilogue

This year’s DevMob was different compared to all the previous DevMobs: there was tangible equilibrium between iOS and Android, with both platforms showing maturity in terms of tools, design metaphors and developer attention.

Sponsors & Venue

DevMob 2014 – Wellington

This (un)unconference¹ would not have been possible without support from the sponsors: Microsoft, Alphero, Xero, Powershop, CactusLab, JSA, and 3 Months.

This year, the swag was particularly nice (thanks to the Alphero team). The sponsors also contributed with very interesting talks, availability and engagement throughout the weekend, and a wicked Lego Death Star draw!

It was Wellington’s turn to host, and the chosen venue was Samuel Marsden Collegiate School. I give it the thumbs up: the food was great, there were plenty of rooms (and each had a projector), and we were even allowed to use the amphitheatre.

An evolving conference

Over the years, the conference evolved from being focused on iOS only, to sharing the spotlight between iOS and Android. This reflects the marketshare and the user base of the two platforms, and the ever growing number of developers interested in them. As one of the attendees who hasn’t missed a single iteration of this event, I’m happy to see such organic growth. It’s also good to see that the Microsoft folk have not given up, and keep attending these gatherings and contributing with incredibly useful insights (Azure being one such example).

My observation (potentially wrong) is that, year after year, the iOS talks have become a bit more abstract and more high level (a good incentive for me to return). At the same time, the audience has managed to keep some practical sessions on the board:

the show-and-tell sessions took a UI/UX spin
the demos contained products that are more and more polished (even though their authors consider them “rough”)
the live coding sessions were focused on concepts that a newcomer would probably struggle to fully understand, but would still find valuable

If a couple of years ago Julius was struggling² to attract a handful of devs to take part in a blue-sky discussion, this year all the Android sessions had full rooms. Refreshingly, Google’s Material Design was at the centre of most discussions. The tools and libraries that people spoke about covered everything you can possibly think of: from analytics, networking, and storage, all the way to dependency injection and reactive programming.

I’m sad to see that Android developers still have to battle with basic things such as networking and resource loading. Michael Rueger from Xero gave a very good talk about the way their app tackles this area. I definitely think his talk should be shared at one of the next Wellington Android Development Meetups. While I’m talking about Xero, Glenn Parker was particularly active and even shared some interesting work they have underway. The Poweshop folks also contributed a great amount, confirming that Wellington is the place to be for Android developers. Not to be outdone, I shared as much as I could about the way that we do things at Trade Me.

No doubt about it, Android is a first class citizen and there’s some outstanding work being done in this space.

New in 2014

Back in 2009 when Jade Software launched DevMob (under the NZiDev moniker), the questions that people used to ask were along the lines of “how do I code, test, deploy, market my app, all at the same time?”. After just 5 editions, this question has transformed into “how do I run a distributed team? how do we collaborate with designers and testers? how do you manage an app’s backlog?”.

This year, I believe two themes were new to the stage: mobile development at scale, and an in-depth look at how to build mobile software. The gimmicky apps were pretty much absent, confirming that the mobile gold rush is well and truly over. For a change, Layton and Karl did not have to too many questions on how to build the next million dollar app.

Scale

Surprisingly, managing scale was probably one of the most talked about things this year. So much so that the group ended up creating a follow-up session after Luke Gumbley‘s “Backlog management / Feature planning” talk.

Team building, maintaining happiness, and dealing with ownership, all got tackled by the audience. The information flowed freely and openly thanks to the trusted environment that makes so many people return to this event year after year.

Depth

It wasn’t just the management side of things that was new this year. The sessions went deeper into the product life-cycle with topics such as API design, security, functional testing and mocking, UX, continuous integration and more.

I was happy to see large development houses (Cactuslab, JSA, Powershop, Trade Me, Vend, Xero, etc) share intimate details about how they tackle many aspects of the SDLC. The fact that non-coding topics permeated DevMob 2014 is encouraging for future iterations of this (un)conference.

Until next time

I missed out on the socialising that traditionally happens after the first day of the conference. I suppose that’s part of the deal when the event is hosted in one’s home town.

Many thanks to the hosts Nat, Janine, Tanya, Julie and everyone who contributed to making this event a success.

If I got anything wrong, or if you wish to pass any feedback, you can reach me on twitter.

Notes:
¹ To learn more about (un)conferences you can visit Nat’s website, buy this Kindle book, or, my favourite option, just take part in one!
² Julius is no longer struggling to attract new people to his talks. He now just needs to find a way to keep Sam awake. (Okay, this photo is cropped and you can’t see the 30 people sitting behind Sam, but it’s funny nonetheless.)

Julius teaches Sam Material Design

Smart Lock – I called it

In my Log In post I was hoping that One day, smarter Log In pages would be able to Trust my location. A mere 2 days later, Google announces Smart Lock (as part of Google Play Services 6.5 and Lollipop).

The Verge provides a good translation of what this will mean to regular users.

In a nutshell, you can now define a location as safe, and then your Lollipop phone won’t ask you to unlock it when you’re nearby—it’ll just let you straight in.

Apps vs. Websites – The ownership perspective

This topic has been covered time and time again. Typically, these articles cover a mix of technology, performance, ROI, look and feel, and other such metrics.

Today I’m going to suggest that the end user’s ownership of an app (as opposed to a website) is one criteria that businesses should consider when making the decision to build a Native App. I’m also proposing that building a Responsive Website is no longer an option, but an expectation.

In 2014, even the cheapest smartphones come with HTML5 capable browsers! End users do not and should not have to understand why a website is different, and sometimes even feels alien, when viewed on a mobile device. The time when we had to compromise on mobile because of technical reasons is long gone. Let’s leave this here.

If the mobile browsing experience is in the same class as the browser experience then why should you even consider an app?

Unless you’re planning to build an amazing app that you plan to support long term, keep up to date with the fast evolving mobile UI/UX, in which you utilise the mobile platform paradigms to the point that the user feels like it was built in collaboration with the designers of the first party apps, then you probably shouldn’t build an app.

The subtlety here is that it all boils down to the fact that you own your website, but the end user owns your app.

If the user has a bad experience on your site, they can’t get rid of your mobile optimised (hopefully responsive) website. Your links will always work, even if they remove all shortcuts or bookmarks. A short url, a web search result or an ad will always be able to bring them back. When they’re back you’ll have a chance to make them change their mind and convince them to return in the future.

On the other hand, if the user has a bad experience with your app, they can simply forget the app ever existed on their device. They will delete it and they’ll do that almost as a punishment for your failure to delight them. Deleting the app will close all the communication channels once provided by that medium: all extensions and widgets will be gone, all URL schemes will seize to function. The reality is your app is competing with potential photos of their friends and family, or with another app that is more in fashion than yours.

The end user owns your app because they install it, they dedicate disk space to it, and they can get rid of it if they choose to. They are in complete control of this lifecycle and, you may not realise this, this lifecycle has financial and psychological implications.

Unlike accessing your website, when installing your app the user is likely to be asked for their password (or fingerprint for Touch ID). Even if your app is free, the psychological connection is made: they acquired your app. They are now using disk space just to have your app around.

Your app must be delightful, it must add value every time it’s used, otherwise the user will eventually run out of patience and delete it. Once they do, you will face a big uphill battle to convince them to give your app another try.

There is no such psychological attachment to your website because the user is not involved in the site’s lifecycle. They usually just “ask” a search engine for it. When they run out of space for their next photo they won’t think which sites they can remove…

If you can’t build a delightful mobile app, then you’d better have an amazing responsive website. The reality is though, that if you don’t have both, then it’s likely that you’ll never be the first port of call for a mobile user.