從安全和體驗上解析移動App的登陸

App登陸須要解決的問題有兩個：安全、體驗。它們分別對應着登陸過程的用戶認證，以及用戶登陸過程操做複雜度兩個問題。


1、登陸過程的用戶認證，常見的手段有密碼加密傳輸、動態密碼、驗證碼等。


一、密碼加密。
目前互聯網行業的移動APP有很多在使用最簡單的作法：根據密碼生成一個散列值，把散列值發送給服務器。服務器計算庫中用戶密碼的散列值，而後和客戶端傳來的散列值比較，一致的話，登陸成功。
若是安全性要求更高一些的話，常見的作法就是公鑰加密。具體作法是這樣，登陸前先向服務器請求一個公鑰密鑰，用公鑰密鑰加密一串根據密碼生成的散列值，而後發送給服務器。服務器使用私鑰密鑰解密，而後與根據數據庫中的用戶密碼計算出來的散列值進行比較，一致的話，登陸成功。固然，還能夠作的更優化一些，就是控制公鑰密鑰的有效期來加強安全性，好比公鑰10秒鐘失效、只能使用一次等。
關於公鑰加密，能夠參考這篇文章：http://www.360doc.com/content/11/0406/17/4146412_107621805.shtml


二、動態密碼。
關於動態密碼，其本質就是選擇另一種能夠識別用戶身份惟一性的方式來和用戶的靜態密碼一塊兒作用戶認證。具體常見的幾種實現手段，能夠參考這篇文章：http://baike.soso.com/v5973952.htm
目前市面上適合App使用的最多見的方式是利用手機短信進行動態密碼認證。即用戶常規登陸時，若是服務器發現有異常，能夠向用戶手機發送一條包含動態密碼的短信，用戶在有效期（常見的是30秒到1分鐘）內把用戶名、用戶密碼、動態密碼一塊兒發送給服務器進行驗證。這個對用戶來講，操做門檻比較低，也很方便。


三、驗證碼。
服務器一旦發現登陸有異常，如IP變化、短期內登陸次數過多等，會向App下發一個圖片，用戶把圖片中要求輸入的數據和用戶名、用戶密碼一塊兒提交給服務器。


爲了下降用戶登陸過程的複雜性，一般狀況下，用戶只須要輸入用戶名和密碼，只有服務器發現異常狀況纔會啓用驗證碼、動態密碼等機制。


2、減小用戶輸入次數的自動登陸。
App登陸成功後，服務器會告訴App一個session，後續交流都使用session。但一般爲了安全起見session都是要設置有效期的，從1星期到20天都見過。那麼，爲了避免讓用戶在session失效後從新登陸，減小用戶的手動輸入用戶名和用戶密碼的次數，引入了「自動登陸」概念。
流程以下：
登陸成功後，服務器給App下發sesion的同時，還下發一個認證token，客戶端把token作爲應用程序的私有數據存儲起來。之後，每當session過時後，就把token發送給服務器獲取新的session。整個過程都是對用戶透明的，對用戶來講，輸入一次用戶名和密碼後，就再也沒有登陸這個事情了。
固然，這種自動登陸的前提，是能保證token的安全性遠大於session。咱們知道，因爲手機OS的安全機制，token作爲應用程序的私有數據，對其它應用是不可見的，能夠保證token的安全性。咱們還能夠再上一個鎖，把token和用戶使用App的那個設備作綁定。可供選擇的綁定數據有imsi,mac等。這樣的話，只要用戶手機不丟，就沒事。


沒有一種安全機制是絕對安全的，咱們須要在實際應用過程當中綜合運用App使用場景、具體業務類型、用戶習慣等各類方式來平衡安全性、用戶體驗還有商業應用中很重要的成本。