下午在談交易類服務的時候，除了證書做數字簽名以外，也談到了重放攻擊的問題。
對於重放攻擊可以通過序列號的方式來判斷。
序列號從頒發角度分成：1.服務呼叫者自身頒發。2.服務提供者頒發。
序列號生成方式分成兩類：1.不重複，隨機頒發。2.遞增。3.時間戳。
頒發者如果選擇是服務提供者，那麼就會使得原本一次的會話互動變成兩次，增加了複雜度和失敗率，因此最好選擇服務呼叫者自身頒發。生成方式如果選擇1，那麼儲存的成本很大（服務呼叫者頒發的方式，在服務呼叫者這邊必須全量儲存，在服務提供者這邊如果校驗沒有被使用過，也會記錄下來，最終也是全量儲存。服務提供者頒發方式，序列號只儲存在服務提供者這邊，不過也是全量。）生成方式選擇2，那麼不論選擇哪一種頒發方式，都只需要儲存上一次的序列號，但是對於多執行緒和集群的併發訪問控制需要做好保護，防止由於併發訪問本身順序不準確導致服務被拒絕。生成方式選擇3，那麼任何一種頒發方式都不需要保持序列號，校驗的時候制定容忍時間窗大小來判斷是否是有效的時間戳。需要注意的是客戶端和服務端的時間差異性問題，當時間差大於可容忍的時間窗，那麼每次請求都可能被作為無效請求拒絕。
這裡我的想法是結合兩種方式去做重放攻擊的防範，即保證資源使用的可控，也保證系統複雜度不高：採用服務呼叫者自身頒發序列號，同時生成方式採用時間戳的方式。服務端校驗流程如下：
其中服務有效期可以自己選擇定義（可以是半小時，一小時等等），選擇的參考就是首先客戶端這邊與服務端最大可容忍的時間差是多大，其次就是自己的儲存預估，如果儲存越大，那麼可以放的更寬一些。這種設計在容忍值內採用的是不重複性的校驗，畢竟時間戳方式也是不重複的，這樣減少了在短時間內由於併發和並行帶來的順序控制難的問題，其次在容忍值後採用的是遞增校驗，這樣可以減少對於序列號的儲存壓力，可根據自身儲存能力考慮最大的容忍時間。
歡迎討論...
Web服務的重放攻擊的一點想法
下午在談交易類服務的時候，除了證書做數字簽名以外，也談到了重放攻擊的問題。對於重放攻擊可以通過序列號的方式來判斷。序列號從頒發角度分成 1.服務呼叫者自身頒發。2.服務提供者頒發。序列號生成方式分成兩類 1.不重複，隨機頒發。2.遞增。3.時間戳。頒發者如果選擇是服務提供者，那麼就會使得原本一次的會...
重放攻擊的一點想法
http請求是短連線 每次有請求接入 伺服器都要重新核實一遍 請求裡面使用者的身份資訊，而這個往往是通過瀏覽器的cookie來實現的 目前好像這個是 各種五花八門 登入，實現b s會話的基礎 什麼單點登入 oauth2.0都是圍繞這個在做事 只是元件數量和 過濾器多少 過濾條件 多少的問題。重發攻擊...
關於web效能的一點想法
概念 資料層 前提條件同等硬體，同等頻寬條件。為了提高效能，需要減少io，降低資料庫連線斷開頻率 連線斷開很費資源 減少io 所有常量，或變動不大的量統統常駐記憶體。降低資料庫連線頻率 資料層分離，資料層負責統一協調。常量常駐記憶體指的是，一些常量，在系統啟動時候，從資料庫或者配置方案，一次性載入到...