在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的生態安全。

[IT狗][single sign on]OAuth2/OIDC安全考慮

Single sign on (SSO)坊間可能是用OAuth/OIDC。
但其實無論OAuth還是OIDC,其實都很易因為phishing website而出事。

唔係你個Mobile App用果時出事,而係當Malicious mobile app砌一個扮browser UI來模仿OAuth/OIDC flow中的authentication step的login page,就可能會出問題。

security問題:
(1) UI可以扮假既address bar,user唔可能用有冇address bar同個url黎分到係真定假。

(2) 由於agent(browser)係假扮,所以用PKCE code verifier (https://tools.ietf.org/html/draft-ietf-oauth-spop-15#section-1.1)呢種防止中間interception既方法係防唔到。因為佢從頭到尾都係假,而唔係interception。

我望過某d vendor網站,例如pingidentity (https://developer.pingidentity.com/en/resources/napps-native-app-sso.html)
佢都只係講用上面PKCE果種方法去防,其實真係唔夠,好易出事。

大約咁諗過,安全既做法,可能要好似blizzard battle.net authentication app果種先比較安全。

又或者用authorization code grant flow, 就可以有client secret exchange code for token果個step protect到。
但係如果mobile app係hardcode一個global app key都係出事。
(即係”user A”同”user B” mobile上同一隻app都係share同一條app key)
因為我係我部機度crack左條global key, 就可以用黎hack隻app。

所以如果每隻app install後各自dynamic register一個device specific的OAuth client (要係per device per user的), 之後操作都係用依個per device per user level既client id&secret, 行authorization code grant flow咁就應該較難被破解。(好似係)

但係, 經常出現login page, 其實user都可能被train到好易信任果個login page界面。phishing website都係可能會令user中伏。