2011-03-30 38 views
1

我不需要它太安全。即使md5,通常是破損的,比我需要的更安全(只要在2分鐘內找不到碰撞,應該是100%)。在線遊戲:JavaScript中的快速不太安全的密碼哈希/校驗和功能?

我需要它用於我們將在本週末的黑客馬拉松中製作的視頻遊戲。我們有一個模擬遊戲核心部分的服務器,我們需要同步多個玩家(我們使用socket.io和nodejs作爲彗星服務器),並確保沒有玩家通過修改值來作弊。因此,校驗和(如果他們發送有效校驗和,將與服務器中生成的校驗和進行比較,則用戶具有正確的東西)。

所以,只要校驗和不是太容易反向工程,就應該沒問題。因爲我沒有太多在線遊戲的經驗(雖然我在C,Java,Python甚至PHP中使用過一段時間的套接字,但是),如果有人可以推薦一些關於一般性閱讀的話,那將是非常棒的。模式遵循。所有我發現了一個論文,解釋的帝國時代2的在線還挺吸:)

非常感謝

更多ellaboration原因:

每個客戶都有變量(包含屬性等對象)。事件發生在客戶端,因此狀態發生變化。根據狀態,變量會發生變化。所以,客戶端將變量的狀態和哈希值發送到服務器。服務器從客戶端獲取新狀態(例如,可能是「按下右箭頭」),檢查它們是否有效,然後在變量上生成新值。檢查哈希是否與客戶端發送的哈希相對應。如果沒有,它會向客戶端發送一個同步消息,爲他的變量賦予新的值。然後將其全部保存並將共享變量上的更新發送給其他客戶端。 (因爲不是所有變量都可以被其他客戶端看到)

散列主要用於同步。我不知道這是不是最好的方法,但是這是想到的。但是,如果它們只是一個簡單的校驗和(例如CRC32),而不是更難以僞造的東西,我不想讓它們與這些值相混淆。這樣我覺得同步會更容易。

同樣,我沒有關於電子遊戲網絡的經驗,但是從我做過的其他事情來看,這聽起來符合邏輯。我感謝所有反饋。

+0

你想加密什麼?輸入/輸出數據流?你想要一些獨特的標識符?也許,你想生成一個鹽?請更確切地說。 – Deele 2011-03-30 10:42:50

+0

現在闡述更多。感謝您的關注。 – Mamsaac 2011-03-30 10:56:42

+0

爲了完整起見,在基本的2.4 GHz Core2 PC上使用單個內核可以在約14秒內(平均)找到MD5衝突。這比「兩分鐘之內」要低。這如何適用於你的情況尚不清楚。 – 2011-03-30 11:37:13

回答

3

不信任客戶端。使用服務器作爲中心機構,不是爲核心部件而是爲所有部件。儘可能複製服務器端的遊戲狀態,並向客戶端提供數據。不要做任何處理/儘可能少的客戶端。無論客戶修改服務器的什麼值都會拒絕它們。

+0

完全不信任客戶端。我正在複製服務器中的所有狀態和值。哈希的用途是用於同步目的,但是,我不希望任何人通過僞造哈希來搞亂同步。我會精打細算的。 – Mamsaac 2011-03-30 10:48:46

+0

@Mam如果有人想搞亂同步,只會讓其他玩家受益,因爲服務器會拒絕他們獲得的任何好處 – 2011-03-30 10:52:49

+0

我想你是對的......所以,通常的做法是隻用CRC32或什麼校驗和更常見?順便說一句,我想通過嘗試使用常識來提出上述算法。如果有什麼好的論文可以推薦? – Mamsaac 2011-03-30 11:00:07

0

這種方法我不會建議。如果在客戶端進行任何加密,則不安全。 我會建議的方法,使所有可能的行動清單,這是存儲和生成的服務器上。雖然玩家可以採取任何行動,但可以通過可能的行動列表進行更改。當播放器瀏覽器發送任何操作數據時,將根據可能的操作列表進行檢查,如權限表,如果允許操作,則使用正則表達式,其他輸入數據進行驗證。 如果您對保護數據流感興趣,請使用SSL。 最後一件事,就是使用公鑰/私鑰加密數據流。

0

如果您從客戶端上的操作生成哈希,那麼無論加密算法如何安全 - 算法總是可能的 - 客戶端可以操縱這些值並生成新的有效哈希。他們不需要對用於創建驗證令牌的方法進行反向工程 - 您已經提供了用於生成驗證令牌的代碼。

這隻剩下在服務器上生成一組驗證令牌的選項,將它們發送給客戶端並允許客戶端返回相關的驗證令牌 - 如果您這樣做了,那麼在服務器中沒有任何淨收益使用散列與對稱加密相比甚至是隨機值。

0

對於評論太多想法,所以張貼答案是更多的問題;

很難確切地說出你要在這裏保護什麼。如果你想要的只是消息同步......你可以自由使用TCP,並且讓協議處理它嗎?如果這就是你打算做的事情,那麼我完全不知道你的問題是什麼。

如果不是,但不能使用TCP,那麼同步消息可能比您想象的更重要,尤其是在LAN環境中;你使用'hackathon'這個詞,但我不知道這意味着什麼......但是你是否真的想阻止其他玩家發起惡意/惡作劇行爲? (如果使用UDP,通過局域網非常容易)

如果是這樣的話,您不僅要考慮獲取'安全'方法來確保同步;你還需要在做任何事情之前驗證所有消息的來源,因爲UDP/IP中的IP'源'信息幾乎是毫無價值的,除了知道在哪裏發送答覆。你不能基於源IP假設任何東西。 (我的意思是由於TCP/IP的「連接」本質,而不是UDP/IP的隔離數據報; UDP在封閉的環境中很容易,比如你描述的發送惡作劇數據報,可能造成嚴重破壞)。

如果這就是你所需要的,你通常會吠叫正確的樹;你想要快速的東西,並且「足夠安全」以防止快速分析;數據是一種你不關心是否有人可以查看它一個小時,並找出某個時刻有人按下的按鈕 - 你只是想阻止某人發送僞造或DOS數據包被欺騙。

因此,每個客戶端/服務器連接都應該有一個共享的隨機鹽,每個「會話」至少應該重新生成一次。散列發生,消息與散列'簽名'一起發送 - 消息與鹽散列。當接收者獲得該消息/簽名時,它接收該消息並對salt進行相同的哈希處理,並且其結果必須與發送的簽名匹配,否則該消息被欺騙。