這個實際上和桌面程式是一樣的。
參考：桌面qq在2012的時候把密碼md5計算之後，儲存到本地加密的sqlite資料庫裡。
參考：手機**是通過本地des加密，再把密碼儲存到本地檔案裡的，如果拿到root許可權，能破解出密碼明文。
參考：
我實際測試了下，可以輕鬆得到所有帳號的密碼明文。
參考：linux是通過加鹽(salt)，再hash後，儲存到/etc/shadow檔案裡的。
貌似以前的發行版是md5 hash，現在的發行版都是sha-512 hash。
linux使用者密碼的hash演算法：
實際上是呼叫了glic裡的crypt函式，可以在man手冊裡檢視相關的資訊。
可以用下面的命令來生成：
mkpasswd --method=sha-512 --salt=***x
其中salt引數，可以自己設定，最好是隨機生成的。
可以用 mkpasswd --method=help 來檢視支援的演算法。
看完上面一些軟體的做法之後，我們來**下，使用者密碼該如何儲存，還有能做到哪種程度？
實際上也是如此，通過上面qq和**的例子，允分說明了加密串是可以得到的。linux更是一切都是公開的，只要有許可權就可以讀取到，包括salt值，shah演算法，(salt+密碼) hash之後的結果。
假如不加鹽，那麼攻擊者可以根據同樣的hash值得到很多資訊。
比如**1的資料庫洩露了，攻擊者發現使用者a和使用者b的hash值是一樣的，然後攻擊者通過其它途徑拿到了使用者a的密碼，那麼攻擊者就可以知道使用者b的密碼了。
或者攻擊者通過彩虹表，暴力破解等方式可以直接知道使用者的原來密碼。
所以，每個使用者的salt值都要是不一樣的，這點參考linux的/etc/shadow檔案就知道了。
應該用哪種演算法來儲存？
從上面的資料來看，手機**是本地des對稱加密，顯然很容易就可以破解到使用者的真實密碼。qq也是對稱加密的資料庫裡，儲存了使用者密碼的md5值。
顯然對稱加密演算法都是可以逆向得到原來的資料的。那麼我們嘗試用非對稱加密演算法，比如rsa來傳輸使用者的密碼。
那麼使用者登陸的流程就變為：
客戶端用公鑰加密使用者密碼，儲存到本地；
使用者要登陸時，傳送加密串到伺服器；
伺服器用私鑰解密，得到使用者的密碼，再驗證。
有的人會說，如果伺服器的私鑰洩露怎麼辦？
可以考慮有乙個專門的硬體來解密，這個硬體只負責計算，私鑰是一次性寫入不可讀取和修改的。搜尋 rsa hardware，貌似的確有這樣的硬體。
當然，即使真的私鑰洩露，世界一樣運轉，像openssl的心血漏洞就可能洩露伺服器私鑰，但大家日子一樣過。
非對稱加密演算法的好處：
這點實際上是如何讓客戶端儲存的加密串及時的失效。
比如：強制要求客戶端儲存的加密串一周失效；
使用者手機中病毒了，攻擊者竊取到了加密串。但是清除病毒之後，使用者沒有夠時的修改密碼。攻擊者是否會潛伏很久？
發現某木馬大規模竊取到了大量的使用者本地加密串，是否可以強制使用者的本地加密串失效，客戶端不用公升級，使用者不用修改密碼，也不會洩露資訊？
下面提出一種 salt + 非對稱加密演算法的方案來解決這個問題：
使用者填寫密碼，客戶端隨機生成乙個salt值（注意這個salt只是防止中間人攔截到原始的password的加密串），用公鑰把 (salt + password)加密，設定首次登陸的引數，傳送到伺服器；
伺服器檢查引數，發現是首次登陸，則伺服器用私鑰解密，得到password（拋棄salt值），驗證，如果通過，則隨機生成乙個salt值，並把salt值儲存起來（儲存到快取裡，設定7天過期），然後用公鑰把(salt + 使用者名稱)加密，返回給客戶端。
客戶端儲存伺服器返回的加密串，完成登陸。
客戶端下次自動登陸時，把上次儲存的加密串直接發給伺服器，並設定二次登陸的引數。
伺服器檢查引數，發現是二次登陸，用私鑰解密，得到salt + 使用者名稱，然後檢查salt值是否過期了（到快取中查詢，如果沒有，即過期），如果過期，則通知客戶端，讓使用者重新輸入密碼。如果沒有過期，再驗證密碼是否正確。如果正確，則通知客戶端登陸成功。
如果發現某帳戶異常，可以直接清除快取中對應使用者的salt值，這樣使用者再登陸就會失敗。同理，如果某木馬大規模竊取到了大量的使用者本地加密串，那麼可以把快取中所有使用者的salt都清除，那麼所有使用者都要重新登陸。注意使用者的密碼不用修改。第2步中伺服器生成的salt值，可以帶上使用者的mac值，os版本等，這樣可以增強檢驗。
注意，為了簡化描述，上面提到的使用者的password，可以是先用某個hash演算法hash一次。
瀏覽器的登陸過程比較簡單，只要用rsa公鑰加密密碼就可以了。防止中間人擷取到明文的密碼。
伺服器用rsa私鑰解密，判斷時間（可以動態調整1天到7天），如果不在時間範圍之內，則登陸失敗。如果在時間範圍之內，再呼叫coreservice判斷使用者名稱和密碼。
這裡判斷時間，主要是防止攻擊者擷取到加密串後，可以長久地利用這個加密串來登陸。
伺服器用rsa私鑰解密，再用aes解密加密串，判斷使用者名稱是否一致。如果一致，再以（使用者名稱+android/ios/wp）為key到快取裡查詢。如果判斷快取中的salt值和客戶端傳送過來的一致，則使用者登陸成功。否則登陸失敗。
不用aes加密，用rsa公鑰加密也是可以的。aes速度比rsa要快，rsa只能儲存有限的資料。
多次md5或者md5 + sha1是沒什麼效果的。
rsa演算法最好選擇2048位的。搜尋" rsa 1024 crack"有很多相關的結果，google已經將其ssl用的rsa演算法公升級為2048位的。
如何防止登陸過程的中間人攻擊，可以參考，魔獸世界的叫spr6的登陸演算法。
對於網頁登陸，可以考慮支援多種方式：
伺服器用salt（存資料庫的） + hash演算法來儲存使用者的密碼。
用salt（存快取的，注意和上一行的salt是不同的）+ rsa演算法來加密使用者登陸的憑證。
這樣伺服器可以靈活控制風險，控制使用者登陸憑據的有效期，即使使用者資料洩露，也不需要修改密碼。
移動App該如何儲存使用者密碼
這個實際上和桌面程式是一樣的。參考 桌面qq在2012的時候把密碼md5計算之後，儲存到本地加密的sqlite資料庫裡。參考 手機 是通過本地des加密，再把密碼儲存到本地檔案裡的，如果拿到root許可權，能破解出密碼明文。參考 我實際測試了下，可以輕鬆得到所有帳號的密碼明文。參考 linux是通過...
移動App該如何儲存使用者密碼
update 2018 06 04 2015年出的乙個規範 json web token jwt jwt 官網 八幅漫畫理解使用json web token設計單點登入系統 json web encryption jwe json web signature jws update 2017 9 6 ...
移動APP如何儲存使用者密碼
儲存了使用者資訊便涉及到了安全問題.解決的方法大概有一下幾種 1.首先,如果客戶端和服務端都是你來設計開發,那麼有兩種比較可靠的方案 a.客戶端將密碼hash加密,登入成功後將hash值儲存到sqlite.服務端得到使用者名稱和hash值,採用同樣的演算法對密碼進行hash運算,然後和使用者傳來的h...