4 Reasons a native mobile app can be more secure than a mobile browser based app

I had the plea­sure of shar­ing an office with a co-work­er that I don’t see as often as I’d like. Hav­ing just come back from some inter­est­ing con­ver­sa­tions with a smart cus­tomer, he seemed in the mood to talk. I asked a few ques­tions to goad him into start­ing, but most­ly he talked and I typed. Any­thing below that’s smart is his. Any­thing that’s mal­formed, is my inter­pre­ta­tion of what he said.

Here you go: Four rea­sons why a native mobile app can be more secure, with a bonus dis­cus­sion on how more secure means you can do bet­ter busi­ness as a result of ‘dig­i­tal trans­for­ma­tion’.

1. It’s eas­i­er to use mul­ti-fac­tor authen­ti­ca­tion in an app. The app itself is a chan­nel for deliv­ery of a PIN, but if they’re on an app they also have a phone num­ber right there. Mul­ti-fac­tor authen­ti­ca­tion is so easy as a user and adds A LOT of addi­tion­al secu­ri­ty. A win-win if there ever was.
2. Cer­tifi­cate pin­ning. An app can have an embed­ded cer­tifi­cate, bet­ter than a brows­er for pre­vent­ing man-in-the-mid­dle attacks.
3. Fine-grained risk eval­u­a­tion. (This is my favorite.) API calls can have their risk-expo­sure be eval­u­at­ed on a “what are you doing basis” (GET vs POST) rather than on a giv­en URL. Fine grained autho­riza­tion and risk checks  are hard­er to do in a brows­er with a URL scheme. You’d have to code it in the appli­ca­tion (and in each-and-every appli­ca­tion). When it’s API dri­ven, you can do the risk assess­ment in the infra­struc­ture. In the infra­struc­ture it has a low­er cost of own­er­ship, and the “secu­ri­ty experts” can do their job with­out break­ing open code and man­ag­ing the “appli­ca­tion” life­cy­cle.
4. Key­chain con­ve­nience. (I did­n’t ful­ly under­stand this one, but felt I was wear­ing out my ques­tion and answer time.) The stuff that we’re (CA) doing in the Mobile API Gate­way allows uncom­pro­mised secu­ri­ty with con­ve­nience. In the brows­er, secu­ri­ty is a trade off with con­ve­nience. In a mobile app, it’s not. You can use your thumb for con­ve­nient authen­ti­ca­tion but still ben­e­fit from mutu­al SSL authen­ti­ca­tion (because it can be stored in the app).

Wait, there’s more!

Not only do mobile apps make mobile com­put­ing (which is real­ly just ‘com­put­ing’) more secure, it makes your web com­put­ing more secure. With an app, you can use two fac­tor authen­ti­ca­tion on the web more eas­i­ly. Using the phone as a way to require some­thing the user knows (their pass­word) AND some­thing they have. While you don’t need an app to do this, it becomes eas­i­er with an app.

By the way, my bank has imple­ment­ed 2‑factor authen­ti­ca­tion for online-bank­ing when the brows­er isn’t rec­og­nized. I love it (would love it more if they did it every time I logged in but only if they short­ed the cur­rent code length of 8 or 9 dig­its which is too hard to type in). I no longer get all stressed out that I’m going to for­get who I told them my favorite teacher was in sec­ond grade or who my favorite author is.

Imag­ine this at an ATM. Elim­i­nate “shoul­der surf­ing” for peo­ple’s PINs by sim­ply hav­ing two-fac­tor authen­ti­ca­tion at the ATM through the mobile app. By the way, this would be anoth­er rea­son for peo­ple to down­load your app… which means (as a bank) you can start to con­vert hold­outs who come to your branch­es for every­thing to peo­ple who might try some of the mobile bank­ing ser­vices (and low­er costs).

Talk­ing about low­er­ing costs… when some­one for­gets their ATM, cred­it, or deb­it PINs they’re reset by peo­ple. In a call cen­ter or at the branch.

What if reset­ting a PIN could be done through the app?

Bam­mo. Offload the call cen­ter, and peo­ple are hap­pi­er because they don’t have to deal with over­worked & unhap­py call cen­ter or branch work­ers.

(I know the end of this post does­n’t read so well… that’s why I don’t usu­al­ly write in the after­noon. Want­ed to get this done. Email me if I can offer more clar­i­ty.)

—Updat­ed 3/10/16

Got some good feed­back on the post. One in par­tic­u­lar point­ed out that it’s not real­ly about mobile app vs brows­er as it is API-dri­ven app vs ses­sion-based ones. Using APIs to cre­ate your apps enables you to make them more secure than oth­er­wise. While I am at the depth of my tech­ni­cal lan­guage at that point, I do believe this is an impor­tant clar­i­fi­ca­tion that helps make the above more under­stand­able if you are tech­ni­cal.

In fact, I think under­stand­ing the dif­fer­ent of AP-based vs non-API-based is a bet­ter way of explain­ing my bias towards the expe­ri­ence of native appli­ca­tions, though I would not have explained it that way with­out expo­sure to the smart peo­ple at CA.