Re: [討論] ====關於解決隨機認證圖====

看板HOT_Game (熱門遊戲)作者SmallBeeWayn (喵喵叫的蜜蜂貓)時間18年前 (2007/06/23 04:50)推噓9(9推 0噓 3→)

留言12則, 11人參與討論串23/25 (看更多)

首先，在談到結構該怎麼搞之前，先討論一下資料該怎麼存放的問題... 基本上，資料有三項, 來源(圖片特徵值), 結果(辨識結果), 加入時間我看了一下愛台灣.txt 居然用64,16 Byte長度的資料@_@ 對結果做加密就算了, 來源值似乎也做過加密...? 基本上來源值用MD5或是CRC-64應該就足夠防止算出結果重複了如果在換算之前多一道內部XOR的話，MD5/CRC的值就可以直接傳送了我的建議的話...CRC-64長度為16Byte, 應該滿合適的結果的話因為需要接收方做解密的關係原本的加密方法應該就繼續使用下去伺服器的儲存當然還是SQL比較好用來源做Primary, 加入時間做Index 每一筆的資料長度大約是32Byte 然後以每x筆為單位做一個升級包由於資料長度固定, 逗號跟換行其實都不需要的資訊倒是升級包需要做一個整個資料的效驗碼，免得資料傳錯了... 伺服器的工作則分為兩個部份 1.接受客戶端的更新提供 2.接受版本更新請求當客戶端啟動的時候會向伺服器提供自身當前版本並由伺服器方面提供一直到最新版本為止的升級包為了簡化封包複雜性這兩項工作應該由不同的服務Port來處理而且最好是用UDP方式甚至其實也可以用不同的主機來處理一台機器只儲存升級包，另一台才處理資料之後，當客戶端收到新的來源時，並不立即請求更新除非系統已經超過一段時間接收到新來源且一直沒有提交更新 (也就是當使用者不在的時間)才用啟動模式更新版本另一方面，當客戶端有提供新的結果時會向伺服器提交包含自身當前版本及最新的來源&結果伺服器就會更新資料庫，並且檢查新的升級包是否已經完成如果已經完成則回傳 ============== 再來，就是偽造的請求跟偽造的結果這兩個問題偽造的版本更新請求會讓伺服器負載過度我是不知道是不是有人會這樣搞啦不過版本更新請求還是應該加一點驗證碼才是... 偽造的結果可以利用重複檢核或是信任的支援者來處理重複檢核就是儲存同一個來源的結果重複率跟來源主機也就是假定多數的使用者提供的是正確得結果不過萬一遇到DDOS一樣無法或者就是在新增一種封包請求就是「這一筆來源-結果對應是錯的」這樣的信息但是其實一樣擋不住DDOS 信任的支援者是比較安全的方式也就是只讓特定的一些人提供更新資料其他人只能請求新的升級包這種的好處是不怕被假結果攻擊... 不過要找信任的支援者很麻煩的, 得主動去找或者呢，就是讓整個資料的編碼複雜性增加讓來源&結果的編碼互相掛勾增加偽造結果的複雜性這方面的方法我還沒想到.... -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.204.46