I had the pleasure of sharing an office with a co-worker that I don’t see as often as I’d like. Having just come back from some interesting conversations with a smart customer, he seemed in the mood to talk. I asked a few questions to goad him into starting, but mostly he talked and I typed. Anything below that’s smart is his. Anything that’s malformed, is my interpretation of what he said.
Here you go: Four reasons why a native mobile app can be more secure, with a bonus discussion on how more secure means you can do better business as a result of ‘digital transformation’.
- It’s easier to use multi-factor authentication in an app. The app itself is a channel for delivery of a PIN, but if they’re on an app they also have a phone number right there. Multi-factor authentication is so easy as a user and adds A LOT of additional security. A win-win if there ever was.
- Certificate pinning. An app can have an embedded certificate, better than a browser for preventing man-in-the-middle attacks.
- Fine-grained risk evaluation. (This is my favorite.) API calls can have their risk-exposure be evaluated on a “what are you doing basis” (GET vs POST) rather than on a given URL. Fine grained authorization and risk checks are harder to do in a browser with a URL scheme. You’d have to code it in the application (and in each-and-every application). When it’s API driven, you can do the risk assessment in the infrastructure. In the infrastructure it has a lower cost of ownership, and the “security experts” can do their job without breaking open code and managing the “application” lifecycle.
- Keychain convenience. (I didn’t fully understand this one, but felt I was wearing out my question and answer time.) The stuff that we’re (CA) doing in the Mobile API Gateway allows uncompromised security with convenience. In the browser, security is a trade off with convenience. In a mobile app, it’s not. You can use your thumb for convenient authentication but still benefit from mutual SSL authentication (because it can be stored in the app).
Wait, there’s more!
Not only do mobile apps make mobile computing (which is really just ‘computing’) more secure, it makes your web computing more secure. With an app, you can use two factor authentication on the web more easily. Using the phone as a way to require something the user knows (their password) AND something they have. While you don’t need an app to do this, it becomes easier with an app.
By the way, my bank has implemented 2‑factor authentication for online-banking when the browser isn’t recognized. I love it (would love it more if they did it every time I logged in but only if they shorted the current code length of 8 or 9 digits which is too hard to type in). I no longer get all stressed out that I’m going to forget who I told them my favorite teacher was in second grade or who my favorite author is.
Imagine this at an ATM. Eliminate “shoulder surfing” for people’s PINs by simply having two-factor authentication at the ATM through the mobile app. By the way, this would be another reason for people to download your app… which means (as a bank) you can start to convert holdouts who come to your branches for everything to people who might try some of the mobile banking services (and lower costs).
Talking about lowering costs… when someone forgets their ATM, credit, or debit PINs they’re reset by people. In a call center or at the branch.
What if resetting a PIN could be done through the app?
Bammo. Offload the call center, and people are happier because they don’t have to deal with overworked & unhappy call center or branch workers.
(I know the end of this post doesn’t read so well… that’s why I don’t usually write in the afternoon. Wanted to get this done. Email me if I can offer more clarity.)
Got some good feedback on the post. One in particular pointed out that it’s not really about mobile app vs browser as it is API-driven app vs session-based ones. Using APIs to create your apps enables you to make them more secure than otherwise. While I am at the depth of my technical language at that point, I do believe this is an important clarification that helps make the above more understandable if you are technical.
In fact, I think understanding the different of AP-based vs non-API-based is a better way of explaining my bias towards the experience of native applications, though I would not have explained it that way without exposure to the smart people at CA.