例子：

不加密例子：

加密例子：

結論：前端賬號密碼需要加密。

論點一：https是否真的“安全”？

1、Https通訊中間摻雜著許多代理（客戶端代理、伺服器代理等），而正是因為這些代理的出現，使得https也變得不那麼安全。

通過代理就能監控https明文資料，從而能夠獲取到使用者未加密的賬號密碼。

2、抓包原理（Fiddler、Charles、Wireshark等抓包工具）

抓包工具作為中間代理，通過對客戶端偽裝成服務端和對伺服器偽裝成客戶端的方式，對騙客戶端與服務端進行欺騙，從而打到擷取明文資料的目的。

其實抓包的原理本質上就是中間人攻擊，但前提是使用者客戶端上安裝抓包工具根證書並設定為信任。只要使用者不設定證書信任，https還是非常安全的。只要在認證環節出了問題，https的安全性就會失效。

論點二：使用者隱私保護

加密能保障使用者隱私安全，防止內部人員竊密。

1、保護使用者隱私。使用者賬號密碼可能包含其個人身份資訊，賬號密碼洩露會導致其身份隱私資訊洩露；

2、防止內部竊密。請求經過服務端必然會留下請求日誌或痕跡，任意內部開發人員都能夠獲取到使用者賬號密碼，會對企業資料安全造成困擾；

3、防止撞庫。使用者明文賬號密碼被截獲後，會被嘗試於不同應用上，對整個網際網路賬號安全都帶來影響。

論點三：提升逆向成本

提升逆向成本。

（1）通過自定義加密演算法對賬號密碼進行加密，提升作弊者的協議偽造成本；

（2）通過在加密演算法中加入時間戳或其他隨機值，能夠避免重放攻擊；

（3）通過加入環境檢測邏輯，檢測當前使用者執行環境是否正常。

總之通過對賬號密碼進行加密，我們能夠提升逆向分析的難度。我們弄個在該加密串中加入很多有意義的標識，迫使作弊者必須分析。

當然加密和混淆是不可分割的，只加密不混淆，加密演算法明文呈現，加密的效果就會大打則扣。