例子：
不加密例子：
加密例子：
結論：前端賬號密碼需要加密。
論點一：https是否真的“安全”？
1、Https通信中間摻雜着許多代理（客戶端代理、服務器代理等），而正是因為這些代理的出現，使得https也變得不那么安全。
通過代理就能監控https明文數據，從而能夠獲取到用戶未加密的賬號密碼。
2、抓包原理（Fiddler、Charles、Wireshark等抓包工具）
抓包工具作為中間代理，通過對客戶端偽裝成服務端和對服務器偽裝成客戶端的方式，對騙客戶端與服務端進行欺騙，從而打到截取明文數據的目的。
其實抓包的原理本質上就是中間人攻擊，但前提是用戶客戶端上安裝抓包工具根證書並設置為信任。只要用戶不設置證書信任，https還是非常安全的。只要在認證環節出了問題，https的安全性就會失效。
論點二：用戶隱私保護
加密能保障用戶隱私安全，防止內部人員竊密。
1、保護用戶隱私。用戶賬號密碼可能包含其個人身份信息，賬號密碼泄露會導致其身份隱私信息泄露；
2、防止內部竊密。請求經過服務端必然會留下請求日志或痕跡，任意內部開發人員都能夠獲取到用戶賬號密碼，會對企業數據安全造成困擾；
3、防止撞庫。用戶明文賬號密碼被截獲后，會被嘗試於不同應用上，對整個互聯網賬號安全都帶來影響。
論點三：提升逆向成本
提升逆向成本。
（1）通過自定義加密算法對賬號密碼進行加密，提升作弊者的協議偽造成本；
（2）通過在加密算法中加入時間戳或其他隨機值，能夠避免重放攻擊；
（3）通過加入環境檢測邏輯，檢測當前用戶運行環境是否正常。
總之通過對賬號密碼進行加密，我們能夠提升逆向分析的難度。我們弄個在該加密串中加入很多有意義的標識，迫使作弊者必須分析。
當然加密和混淆是不可分割的，只加密不混淆，加密算法明文呈現，加密的效果就會大打則扣。