Xác thực cho trò chơi nhiều người chơi qua ổ cắm


11

Tôi đang triển khai giao thức nhị phân tùy chỉnh cho trò chơi nhiều người chơi mới. Đây là một game chiến thuật theo lượt nên thời gian không thực sự quan trọng. Hiện tại tôi đã hoàn thành phần đồng bộ hóa dữ liệu cơ bản của hệ thống và tôi đã tự hỏi làm thế nào đăng nhập / đăng xuất và mã hóa của người dùng thường được thực hiện cho các trò chơi MMORPG hoặc tương tự.

  • Bạn có thể đề xuất một kế hoạch truyền mật khẩu an toàn / bí mật trong khi đăng nhập không? (Trao đổi khóa Diffie-Hellman?)
  • Làm cách nào để triển khai mã hóa mạnh cho các gói dữ liệu? (AES 128-bit? .. hoặc bất kỳ sơ đồ nào mà bài đăng này đề cập đến là "mã hóa mạnh hơn khả năng bạn sẽ bẻ khóa")
  • Có các lược đồ định dạng datagram giúp làm cứng máy chủ trò chơi để phát lại các cuộc tấn công, các gói dữ liệu không hợp lệ và tương tự không?

Câu trả lời:


15

Đáp án

  • SRP - Mật khẩu từ xa an toàn - Điều này dựa trên Diffie-Hellman. Ý tưởng là bạn có thể thực hiện kiểm tra mật khẩu lẫn nhau mà không thực sự chuyển mật khẩu hoặc bất kỳ thông tin nào có thể được sử dụng để lấy được nó. Mặc dù nó an toàn qua dây, bạn vẫn nên băm và muối mật khẩu của mình vì máy chủ của bạn không bao giờ được lưu trữ chúng trong văn bản thuần túy .
  • Ưu điểm của SRP là một khi nó hoàn thành, nó cũng cung cấp cho bạn một khóa mã hóa được thương lượng lẫn nhau mà kẻ tấn công sẽ không thể suy ra được với dữ liệu bạn đã chuyển. Điều này có nghĩa là bạn có thể tự do sử dụng thuật toán mã hóa đối xứng (như AES) sau khi người dùng được xác thực.
  • Giả sử bạn đang sử dụng UDP với triển khai đáng tin cậy / có trật tự (hướng kết nối) của riêng bạn trên đầu trang: mã hóa toàn bộ tải phát UDP - bao gồm cả 'số thứ tự gói' của bạn. Nếu hệ thống của bạn được thiết kế chính xác, nó sẽ tự động từ chối các tin nhắn được phát lại và kẻ xâm nhập sẽ không thể thay đổi số thứ tự gói vì nó được mã hóa (do đó có thể phát lại - nhưng nó sẽ tự động bị bỏ qua).

Suy nghĩ

Xác thực của bạn có được an toàn không? Chắc chắn rồi. Không thỏa hiệp về mặt bảo mật khi mật khẩu bị nghi vấn. Vì vậy, bạn chắc chắn nên xem xét viên đạn đầu tiên trong câu trả lời của tôi.

Dữ liệu của bạn có nên được bảo mật? Chỉ khi đó là giao dịch mua / giao dịch vi mô trong trò chơi - và tại sao không sử dụng thứ gì đó đã thử và đúng như HTTPS. Mã hóa lưu lượng trò chơi của bạn không có khả năng là một giải pháp khả thi vì những lý do sau:

  • Đó là sự hoang tưởng hoàn toàn.
  • Nó sẽ thêm chi phí thời gian CPU trên máy chủ của bạn, trừ khi bạn có thể mua các mô-đun mã hóa phần cứng (đắt tiền).
  • Không quan trọng bạn cung cấp bao nhiêu bảo mật cho dữ liệu của mình qua mạng - ai đó có thể chiếm quyền điều khiển máy khách và chặn tin nhắn ngay trước khi chúng được mã hóa và gửi. Đây không chỉ là một khả năng nhưng vô cùng tốt hơn vì nó là đáng kể dễ dàng hơn để mã bơm so với chặn các gói dữ liệu. Nếu bạn đang làm điều này để ngăn chặn gian lận, bạn hoàn toàn lãng phí thời gian.
    • Về mặt bảo mật mật khẩu, thật không may, không có gì bạn có thể làm một cách hợp lý về một hệ thống bị tấn công, máy khách đã trở nên thù địch. Blizzards WoW dongle được thiết kế để đối phó với điều này - nhưng tôi không chắc nó an toàn đến mức nào (đặc biệt nếu bạn để nó cắm vào).

Xin vui lòng, nếu bạn đang mã hóa để ngăn chặn gian lận từ bỏ nó. Bạn sẽ đến gần - Tôi đã cung cấp cho bạn thông tin trong trường hợp bạn không có. Hãy nhớ rằng bạn có thể mã hóa các gói theo byte đầu tiên trong gói và chỉ báo xem phần còn lại có được mã hóa hay không: mặc dù, một lần nữa, tôi sẽ dính vào HTTPS nếu bạn cần thực hiện những việc như giao dịch thẻ tín dụng: chúng cực kỳ không thường xuyên và HTTPS được thiết kế bởi các chuyên gia - không giống như những gì bạn hoặc tôi thiết kế.

Tất cả những gì đã nói, Blizzard thực sự mã hóa lưu lượng WoW của họ. Lý do chính khiến điều này bị phá vỡ là bởi vì một người nào đó, có khả năng là một người nghiệp dư hoàn toàn, đã quyết định rằng họ sẽ thử sức mình với một thuật toán mã hóa được trồng tại nhà; này gay gắt ra thực sự tốt . Ngay cả khi bạn sử dụng thuật toán tiêu chuẩn công nghiệp, rất có khả năng ai đó sẽ thiết kế ngược mã của bạn và mô phỏng nó - một khi khách hàng nhập mật khẩu của họ, không có thông báo nào cho biết hệ thống không được hỗ trợ được kết nối.


2
+1 để nói rằng mã hóa các gói dữ liệu để ngăn chặn gian lận là vô ích. OP: kiểm tra mọi thứ bạn nhận được từ máy khách, chạy kiểm tra độ tỉnh táo, kiểm tra kỹ xem hành động mà khách hàng yêu cầu có khả thi không, kiểm tra phạm vi vũ khí, tốc độ di chuyển, v.v. nhưng đừng lãng phí thời gian để bảo vệ khách hàng của bạn vì nó sẽ bị hack nếu Trò chơi của bạn là giá trị nó. Một số công ty MMO mã hóa và làm xáo trộn khách hàng / giao thức của họ nhưng điều đó không phải để ngăn chặn gian lận mà là gây khó khăn hơn cho những người tạo bot để có kết quả tốt, và thậm chí điều này được thực hiện bởi các nhóm chuyên gia chuyên dụng.
Gilead

1
Một vấn đề nhỏ về câu trả lời thứ ba của bạn: chỉ mã hóa các gói có thể không đủ để ngăn chặn sự giả mạo, vì nhiều sơ đồ mã hóa ít nhất có thể dễ uốn . Để bảo vệ tính toàn vẹn của tin nhắn, bạn cần có MAC hoặc chế độ mã hóa được xác thực .
Ilmari Karonen

+1 Cảm ơn bạn đã trả lời rất đầy đủ. Nhìn vào việc thực hiện SRP ngay bây giờ. Bạn có đề xuất gì về chức năng băm được sử dụng cho mật khẩu? MD5? Giao thức OTR (Tắt Bản ghi) sẽ như thế nào đối với trường hợp sử dụng như vậy? nó sẽ hoạt động tốt cho auth / crypto thay vì SRP? Trong trường hợp tôi sử dụng SRP, tôi có cần sử dụng một trong các chế độ "mã hóa xác thực" sau đây không? (OCB 2.0, Gói chính, CCM, EAX, Encrypt-then-MAC và GCM)
Robinicks

1
@Jenko sử dụng họ thuật toán SHA (có thể là SHA1) - bạn nên tránh MD5 những ngày này. OTR thực sự không phải là thứ bạn nên xem xét - nó không được thiết kế để bảo mật / tối nghĩa (thực tế nó được thiết kế để ai đó có thể giả mạo các gói dễ dàng hơn ) nó cũng được thiết kế để nhắn tin tức thời và không liên lạc với máy. Không có chế độ nào trong số đó là cần thiết, chỉ cần sử dụng SRP: một khi bạn có khóa đối xứng được đàm phán lẫn nhau chỉ đơn giản là có thể mã hóa thứ gì đó đủ đảm bảo rằng bạn đang nói chuyện với bên thứ ba chính xác. Ngoài ra, một lần nữa, đọc lại hai đoạn cuối của tôi.
Jonathan Dickinson

1
Trên thực tế, tôi có một đề xuất thậm chí còn tốt hơn: sử dụng DTLS hiện có trên triển khai UDP và đừng cố tự lăn. Nó sẽ giúp bạn tiết kiệm thời gian và có rất nhiều chi tiết nhỏ nhưng quan trọng rất dễ bị sai nếu bạn cố gắng thiết kế lớp mã hóa datagram của riêng mình.
Ilmari Karonen

2

Tôi nghĩ rằng nhận xét cuối cùng của tôi cho câu trả lời xuất sắc của Jonathan là đáng để mở rộng thành một câu trả lời của riêng mình:

Nếu bạn không có nhiều kinh nghiệm về tiền điện tử, bạn không nên cố gắng thiết kế lớp mã hóa của riêng mình nếu bạn có thể tránh được. Nếu bạn làm có rất nhiều kinh nghiệm crypto, bạn nên biết tốt hơn so với thiết kế lớp mã hóa riêng bạn nếu bạn có thể tránh nó.

Thay vào đó, hãy thử tìm một thư viện tiền điện tử hiện có, được tiêu chuẩn hóa và được thử nghiệm tốt, thực hiện những gì bạn cần. Trong trường hợp của bạn, tôi khuyên dùng GnuTLS , theo Wikipedia , cung cấp cả xác thực TLS-SRP ( RFC 5054 ) và giao tiếp UDP an toàn với DTLS ( RFC 6347 ). Cái trước đảm nhiệm việc đăng nhập, trong khi cái sau bảo vệ kênh an toàn do đó hình thành từ cả các cuộc tấn công nghe lén và hoạt động, và thậm chí có thể bảo vệ bạn khỏi các cuộc tấn công phát lại .


Tôi đang sử dụng TCP. Đây là một loại trò chơi rất khác nhau cho một khách hàng cụ thể. Tương tự như đánh bạc / cá cược, tất cả thông tin có thể được sử dụng để chiếm quyền điều khiển làm tăng khả năng thua lỗ không cần thiết của nhà cái. Chúng ta cần giữ dữ liệu cực kỳ an toàn, vì thông tin là tiền trong trường hợp này.
Robinicks

OK, nếu bạn đang sử dụng TCP, thì điều đó thậm chí còn dễ dàng hơn: bạn có thể sử dụng TLS 1.2 bình thường thay vì DTLS, cung cấp cho bạn nhiều tùy chọn hơn để lựa chọn. Tuy nhiên, tôi vẫn muốn giới thiệu thư viện GnuTLS.
Ilmari Karonen

Tôi sẽ nghiên cứu một chút và xem liệu tôi có thể tham khảo mã nguồn TLS ở cả phía máy khách và máy chủ hay không, và dựa trên giao thức của tôi xung quanh những gì nó làm. Điều này sẽ đủ mạnh? Thực chất nó chỉ là mã hóa gói với một số mật mã / chế độ, đúng không?
Robinicks

Không, giao thức TLS có nhiều hơn một chút . Đó là lý do tại sao bạn muốn sử dụng một thư viện tiêu chuẩn thực hiện nó, thay vì tự lăn.
Ilmari Karonen
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.