...我已經在這裏讀過一些討論過各種方法的線程，並且只是在我們提出的建議解決方案上尋找一些反饋。在其中一條線索中發佈了評論，推薦一個公鑰/私鑰，聽起來很棒，這就是我們在想的...關於（半）保護Flash/PHP遊戲高分的建議
客戶端 - 1.密鑰存儲在Flash swf中，使用3rd派對工具。 2.高分數與高得分值沿着散列（EX：MD5（「ourSecretKey」 + 200）） 3。該值是通過AMF發送到PHP腳本在服務器上，與高得分沿（200 ）
服務器端 - 1.服務器接收數據並散列傳遞的高分（200）密鑰（存儲在服務器和Flash中的'ourSecretKey'），並檢查傳遞的哈希值是允許輸入高分的匹配項，否則爲失敗。
我知道這不是一個萬無一失的解決方案，但這是可以接受的嗎？我的意思是，這是一個簡單的在線Flash遊戲的高分數形式足夠的安全性？思考？
預先感謝您！
對於一個荒謬的短值（即：值爲<的64個字符），由於彩虹表攻擊，MD5作爲散列變得無效，並且由於您發送的值將通過線路共享，所有他們必須做的是蠻力共享的祕密（他們有一個已知的產品一起工作）
這樣，那不是公鑰私鑰。它巧妙地共享祕密。
而且，記住這個共享的祕密將是您的Flash文件發送給用戶，這些天，而輕易地拆卸，那麼你的「祕密」已經不是什麼祕密了。
你想與適當的加密簽名，其中一個新的符號鍵被分配給從服務器每一場比賽，並多次得分更質詢 - 響應機制，不能用相同的符號鍵提交。 （用於額外保護;））
但是，你仍然有在您沒有辦法阻止實際的評分系統被篡改的問題。有人足夠聰明，只需對您的SWF對象進行反向工程，並注入新的代碼即可將分數設置爲其所選值。
您的問題的答案是，這取決於。這主要取決於遊戲的估計流行度。
從安全角度來看，您的解決方案是關於作爲明文發送高分一樣安全。你在這裏所做的就是默默無聞的安全，根據你聽的人的情況，在某些情況下可能會有好處。在這種情況下，可能是喬的普通用戶不可能自己破解它。對於任何擁有l33t h4xxor技能的人，你都可以用明文形式發送。如果你想要阻止喬，那麼這可能就足夠了，至少在某人爲喬創建一個假客戶端的情況下（這取決於你的遊戲的流行度可能需要幾天時間才能完成）或者如果是哇））。
更好的解決方案是@Kent Fredric提供的解決方案。然而，正如它表示，它不能解決有人創建假客戶端的問題。解決方案可能是這樣的：
這將保證兩兩件事：
但是這個方案仍然存在一個嚴重的缺陷。沒有辦法知道遊戲實際上是在玩遊戲。如果客戶受到威脅，該列表可能只是發送給服務器的「完美遊戲」的預製件。直接篡改評分系統是不可能的，但只要有足夠的努力，人們很可能會創建一個包含「完美遊戲」的動作列表。
然而，它比在肯特弗雷德裏克的帖子中使用解決方案提供了更強的保證。解決整個問題意味着你必須以某種方式驗證客戶端。這是非常困難的，因爲這樣做的大多數方法都很容易規避。
最後，我只是對你選擇的哈希算法發表評論：對於那些仍然生活在九十年代的人來說，MD5是一個很棒的哈希算法。對於我們其他人，我推薦SHA-2或至少SHA-1。
這個方案可以通過讓服務器決定併發送每個遊戲的隨機種子來進一步改進。例如。客戶端告訴服務器它想玩。服務器說，好吧，玩種子nn發起的遊戲。然後當客戶想要上傳高分時，服務器檢查高分實際上是否用於遊戲nn。即使這個計劃可以被黑客入侵，但是整個遊戲都需要進行修改。工程。並重建。哪些可以完成（並且已經用於一些使用該方案的流行遊戲）。 – 2012-11-20 09:01:01
是的，當然，客戶端可能仍然蠻力排列動作列表來找到一個產生理想分數的序列，但是你至少提高了從O（1）到某個東西產生假分數所需的計算複雜度更多的O（n^3），不得不蠻力排列找到一個合適的分數，至少應該讓真正的業餘愛好者退出，而他們會採取相反的措施。 – 2012-12-02 16:42:41
塊引用 最後，我只對你所選擇的哈希算法的評論：MD5是爲那些仍然生活在上個世紀九十年代很大的哈希算法。對於我們其他人，我推薦SHA-2或至少SHA-1。
呸，我知道我應該提到SHA代替:)
如果我不使用像一個swf加密應用程序加密，SWF代碼中不會，至少使相當多的困難獲取存儲在Flash中的密鑰？我認爲如果沒有這個密鑰（或者至少不容易），找出用於生成發送到服務器的散列的內容將是一個巨大的痛苦。
像這樣的東西是什麼，我在想：SWF Encrypt
再次感謝大家對這些問題的答案，這是令人驚訝的幫助。哦，這只是一個簡單的Flash遊戲，由客戶發送給客戶，有趣的事情可以在假期工作。
如果您的遊戲分佈有限，且沒有真正的金錢/獎金參與玩家獲勝，您的原始方案可能就足夠了。
使用SWF Encrypt可能會使提取密鑰更困難一些，即使在更高級的系統中使用它也可能是一個很好的工具。但是如果你有一個真正的公鑰/私鑰方案（例如RSA），這實際上是一個有爭議的問題，因爲公鑰不是祕密，它不應該是祕密。仍然爲了防止大多數人編輯代碼並篡改評分系統，SWF Encrypt可能是一個足夠好的選擇。
只是爲了讓你多一點偏執我寫了下面還有：
與SWF加密問題，與大多數其他類似的工具，是它仍然必須能夠執行腳本在（可能受損）的機器上。所以所有信息必須在所述機器上可用。與經典密碼學的使用相比，發送消息：
當您發送加密消息時，您通常會信任源和目標，因此這兩者都有解密消息的密鑰。你不相信的是信使，或者至少不是你的敵人不會攔截信使。所以信使沒有鑰匙，你的信息是安全的。
您的問題在於，您相信目的地（您）而不是來源（客戶），反之亦然。儘管如此，您還是需要信息來源能夠加密信息，因爲您更信任信使。因此，源需要具有所有信息來加密和解密消息才能正常工作。你的問題是你看不到「好」源和「壞」源之間的區別。
我的意思是說，由於代碼必須仍然可以在客戶端上運行，所以這樣做的信息必須完全可用，儘管可能以模糊的形式存在。黑客可以創建自己的ActionScript編譯器，將混淆的ActionScript代碼轉換爲可讀的並進行適當更改。困難但絕對可行。
然而，如果你的發行量有限，而且沒有真正的贏錢，那麼這種複雜的攻擊水平很可能不會成爲你的問題。
對來源不可信的基本原則有很好的評論。 – noio 2012-11-11 13:55:17
肯特提到，我沒有看到使用該解決方案的任何優勢。作爲客戶端，我可以請求服務器端創建密鑰。好的，我不能多次使用它，但我不必......每當我需要它時，我都會請求它。
當然，這隻會增加複雜性。但是，「共享密鑰」是一種「發現一次，提供數百萬次」的方法，而每鍵1鍵則至少讓你依賴分配密鑰的服務器，並且可能會限制分配這些密鑰鍵。 但是Andreas的基於序列複雜性的安全性可能會使複雜性太難以使其值得扭轉。 – 2012-12-02 16:49:45
哇
漂亮的硬解8）。
我實現了這樣的系統一次。雖然它沒有爲每場比賽的工作...
你應該在服務器上重放遊戲。當用戶玩 - 你存儲「狀態改變」，然後簡單地以某種「重放」模式給你遊戲。
有一個且只有一個100％的加密分數的工作方式：記錄重播。
但不只是任何重播，理想情況下，您應該只記錄用戶按鍵和它們之間的空間。這樣，即使有人篡改了源或RAM動態，服務器上播放的重播也會發現問題。
不幸的是，這種解決方案需要大量的工作才能實現。爲了簡單起見，您可以手動驗證所有分數（或最佳分數），並且您很高興。儘管如此，你仍然需要避免一些事情：
可能還有更多。
然而，這種防禦是牢不可破的。代碼需要時間：D。
請注意，這篇文章有幾年在回來，事情總是發生。現在認爲MD5 *已完全破碎。 – 2012-11-20 08:50:46