1樓：黑照
使用C/S架構的情況下首先就避免了使用B/S那種純明文的傳輸協議。C/S的安全性保證應該是在通訊協議方面而不是簡單的加密解密這塊。
當然借鑑B/S的也行。
如果C/S架構的只是登陸密碼做限制那安全性也太弱了。監聽一樣可以獲得有關的通訊方式，比如和資料庫直連的話不就能獲得資料庫的通訊IP和賬戶密碼了。
2樓：王泥煤
反對玄星的答案。
題住問的是身份鑑別和重放攻擊的問題。不是資料篡改的問題。
密碼學裡的標準解決方案是使用 Diffie-Hellman金鑰交換協議或者以RSA為代表非對稱加密協議。
當然，只應對重放攻擊的方法也有寫，就是使用隨機數驗證，例如：
Server上儲存著使用者密碼的md5雜湊:p_hash，當使用者請求登入時，server生成乙個隨機字串:token，將token傳送至客戶端。
使用者在客戶端輸入明文密碼:p，客戶端進行了如下計算：
hash(hash(p)+token)
意思就是先將密碼明文進行一次md5，然後與token拼接後，再進行一次md5，把最終的加密結果：auth_token傳送至server。
Server接受到auth_token後進行如下計算來校驗使用者輸入的密碼是否正確
auth_token = hash(p_hash+token) ？
如果攻擊者對網路進行監聽，得到的只是auth_token，如果重放auth_token，那麼這個包使用的是Server上一次生成的隨機數，伺服器驗證不予通過。以上。
HTTPS 下 Web 前端密碼非對稱加密是否有意義？
最近被這個問題折騰了好久。我來說說我的看法吧。首先，前端非對稱加密幹的人不多。而且就算幹了的站點比如google我都不知道他的加密演算法是什麼。然後，這個事情是有意義的，因為這樣可以證明服務端絕對不會拿到你的真實密碼，給客戶安全感。最後，我也不知道我該用單次的sha256 鹽還是PBKDF2 sha...
C S架構的軟體真的沒有未來了嗎？
B S是一種特殊的C S，B是可以用指令碼進行功能定製的通用C端。對效能要求不高 且不需要呼叫系統本地功能的場合，可以選擇使用B S，也可以選擇C S，其它場合只能選擇C S。隨著JS開發框架的發展，B S和C S有融合的趨勢，很多C S程式使用B S技術開發而成，反之也成立，很多C S程式通過相應...
問問大家知道哪些明信片數字密碼的加密方式！
回憶 沒那麼複雜，還有個最普通的，字母表順序，1 a，2 b.26 z 每組單詞已經用橫線劃分好，可以得到 235311420 21311 2016 4535135132523 接下來就是嘗試分組了。2 3 5 23 5 3 11 4 20 3 1 14 20 3 1 1 4 20 21 3 11 ...