關於mobile做authentication security

[itdog][mobile, security, oauth][其實IoT可能都關事(唔熟)]

關於mobile做authentication security問題。
之前可能講過, but我都再講多次, 重要野唔怕一講再講。

Mobile App裝o係Mobile,你就要預左好似frontend javascript咁赤裸俾人睇晒。
因為hacker可以crack mobile
=>拎到APK file
=>decompile做source code

我舉個例子,mobile app用OAuth Authorization Code Grant Flow做authentication。
好多人都係咁做,好多industrial專業engineer都可能係咁做。(就算vendor如pingIdentity, 佢地個網都係咁講架ja)

但以大眾做法,我(or hacker)好似上面咁講,decompile source code,拎到你hard code既client id同client secret。
拎到client id同secret,就有security位俾hacker利用。
玩法可能好多(e.g: phishing, 假client etc)。
實際security impact,視乎OAuth以至成個architecture﹑business flow擺位,以及token權力範圍。

其實就算做OAuth,都有較安全做法。
就係當mobile app install落部機時,立即dynamic registration去register一個per device既OAuth client。
reg完OAuth, 然後立刻將device client register到application的DB。
runtime時,device每次perform operation,都是以device名義去access server。
server side每次checking就要check token validity,同埋device authentication(對返DB record)。

consideration其實有幾個point不過skip費事太長氣。
淨係講最重要一點:

hacker就算crack左你個mobile app睇晒source code都冇用,因為每部device裝完機到runtime都會拎個dynamic client去,根本唔會有個hard code左既id/secret儲o係source code。

(其實玩 IoT 可能都係類似咁,起碼要有device registration, rather than only IoT app registration)

在mobile app上較OAuth/OIDC安全的authentication protocol design

前言

在上篇 OAuth/OIDC在mobile app生態上是防不勝防的security漏洞 提及到,OAuth/OIDC那種做法的flow是近乎不可能保障mobile app usage的生態安全。
其實關鍵問題在於,整個authentication過程中,是需要使用login username/password,從而無可避免被惡意agent capture credential。

Redesign?

那要根本地解決,就可能需要重新設計一個針對mobile app的authentication flow,而當中避免在login過程中需要到login credentail。其中一個可行做法,就是web-pre-authentication。

Web-pre-authentication + mobile app device one time registration

我所謂的web-pre-authentication的意思是,把authentication先在web application上安全地做好。
繼而在mobile app install的時候,就只需要做一次one time device registration就可以讓mobile app以後能自動登入。
這樣的design就能避免mobile app在runtime時login的危險流程。
而另一個關鍵位就是如何把identiy/token之類從安全的web side轉移到相對不安全的mobile app環境之上。

web-to-mobile的implementations

這web-to-mobile的流程,我至少設想到三個implementation flow,而三種flow各有長短,分別能support不同use case。

1) scan QR code
2) Manually input code
3) Server push code

實際上這些flow都有些特別針對security的tricky design考量過,但也許遲些我有時間劃一些flow diagram/sequence diagram,才能比較好的去說明整個design。

OAuth/OIDC在mobile app生態上是防不勝防的security漏洞

前言

我平時都有留意開做Single Sign On既方法,而之前有看過OAuth2同OpenID Connect(OIDC),我亦都寫過幾個post去討論。
web application上應用OAuth2/OIDC是基本上沒太大安全問題的,但在mobile app上的應用其實就可能對生態構成security漏洞。
 
昨天突然想通了一些東西。
mobie app與web application的分別其實在於agent。

mobie app與web application分別在於agent

web application的use case,agent就是browser(e.g: firefox/chrome)。
而mobile app的use case,agent就是mobile app本身,相對地是不可靠的。
 
打個比喻,如果是web application的use case,而現在你使用一個極可疑的malicious browser去進行OAuth/OIDC flow。
那肯定會有安全問題,因為malicious browser是可以capture你的login password。
(一般情況下user是用正常firefox/chrome就不會有問題,因為它們內置了很多安全機制去保護end user。這就是為什麼web application usage是基本上安全。)
換句話說,只要agent是compromised/malicious,其實就很難做到security protect。因為單單是只要在過程中用到過password,都可能被惡意agent capture,從而出現安全問題。
 

惡意mobile app的可行設計

例如,mobile app就可以這樣做一個惡意app:
mobile app表面上假扮進行OAuth (假設是使用Facebook login),實際上其實是一個模仿facebook login page的假的browser UI。
在login過程中,這mobile app就偷偷的capture user login name/password,並使用proxy方法進行login。
結果就是end user在不知情的情況下login而login password被偷取了。

結論

明白到關鍵位是agent,而mobile agent就是mobile app本身,所以我結論就是,基於desgin問題,OAuth/OIDC那種做法的flow是近乎不可能保障mobile app usage的生態安全。