Làm thế nào nhiều trò chơi nên xử lý xác thực?


27

Tôi đã loay hoay tìm hiểu hệ thống xác thực sẽ hoạt động như thế nào trong các trò chơi, nhưng sau nhiều lần tìm kiếm, có vẻ như làm việc với ssl / chứng chỉ có thể hơi phức tạp đối với một trò chơi nhiều người chơi có dung lượng ít hơn nhiều so với MMO.

Tôi biết rằng các trò chơi nhiều người chơi thành công cần điều này, nhưng tôi muốn kiểm tra xem các trò chơi nhiều người chơi khác thường có biện pháp phòng ngừa này không.

EDIT : Tôi sẽ mô tả những gì tôi có trong tâm trí. Máy chủ không chỉ xử lý logic trò chơi, mà còn xác thực. Vì vậy, để chơi trên một máy chủ cụ thể (mọi người đều có thể bắt đầu), trước tiên bạn cần đăng ký tài khoản trên máy chủ và mỗi lần bạn muốn chơi ở đó, hãy đăng nhập như bình thường (mật khẩu / tên người dùng).

Câu hỏi của tôi là, sẽ không cung cấp một kênh an toàn để đăng nhập / đăng ký tài khoản có thể được tha thứ / dễ hiểu trong bối cảnh này không? Ngoài ra, tôi cũng muốn biết các trò chơi có kiến ​​trúc tương tự sẽ xử lý vấn đề này như thế nào.


SSL certs là phức tạp và đau đớn để quản lý. Tôi khuyên bạn nên tránh xa.
tro999

4
@ tro999 Thực ra nỗi đau đến từ việc họ có chữ ký của chính quyền CA. Đối với một trò chơi không giao tiếp với máy chủ thông qua trình duyệt, bạn có thể sử dụng chứng chỉ vĩnh cửu tự ký, thậm chí bạn có thể yêu cầu khách hàng xác minh rằng chứng chỉ chính xác đã được sử dụng. Với một thư viện tốt, nó khá dễ cài đặt.
aaaaaaaaaaaa

Có các giải pháp lưu trữ ứng dụng cung cấp cho bạn SSL miễn phí thông qua các tên miền phụ và các ký tự đại diện của chúng. Do đó, bạn có thể sử dụng HTTPS mà không cần phải suy nghĩ về chứng chỉ SSL. Cũng như một lựa chọn khác.
Sean Middleditch

@eBusiness bạn nói đúng.
tro999

Câu trả lời:


41

Cụ thể liên quan đến bit cuối cùng của câu hỏi của bạn: Không, không bao giờ được tha thứ khi có một hệ thống xác thực không an toàn. Người dùng hiếm khi được giác ngộ khi nói đến bảo mật máy tính. Người dùng sử dụng cùng một mật khẩu cho trò chơi nhỏ của bạn giống như họ làm cho tài khoản Google, tài khoản Facebook, tài khoản ngân hàng, v.v. Ngay cả khi bạn có thể cho rằng đó là lỗi của họ khi sử dụng các thói quen bảo mật Internet kém, bạn sẽ là người chịu trách nhiệm nếu trò chơi của bạn được sử dụng như một vectơ tấn công để đánh cắp thông tin đăng nhập của người dùng. Là một nhà phát triển hiểu rõ hơn, các lựa chọn đạo đức duy nhất là bảo mật đúng quy trình xác thực của bạn hoặc hoàn toàn không có.

Như một số lời khuyên không được yêu cầu nhưng có liên quan, người dùng không muốn được yêu cầu đăng ký trò chơi của bạn. Họ có thể làm như vậy nếu họ muốn chơi trò chơi của bạn đủ tệ, nhưng đăng nhập Yet Another Freaking để đăng ký sẽ khiến nhiều người chơi tiềm năng mất đi. Người dùng bị bệnh đến chết khi tạo một tài khoản mới cho mỗi trang web, dịch vụ và trò chơi ngoài đó, đặc biệt nếu họ yêu cầu bất kỳ loại xác thực email hoặc tương tự. Nếu bạn có thể, hãy tránh việc đăng nhập hoàn toàn hoặc sử dụng dịch vụ xác thực của bên thứ ba hiện có mà người dùng có thể đã có tài khoản. Bạn sẽ có nhiều người chơi theo cách đó. Điều này sẽ tăng gấp ba nếu bạn có kế hoạch mua bất kỳ loại ứng dụng nào trong ứng dụng.

Trò chơi trên web

Một tùy chọn phổ biến - đặc biệt cho các trò chơi Web, mặc dù nó cũng hoạt động cho các trò chơi truyền thống - là sử dụng dịch vụ xác thực của bên thứ ba dựa trên Web. Cả Facebook và Google đều có các API được lập thành tài liệu (cả hai đều dựa trên các API được tiêu chuẩn hóa, iirc) để xác thực. Họ yêu cầu khả năng mở cửa sổ trình duyệt và hướng người dùng tới các dịch vụ của họ, nhưng điều này khá dễ thực hiện trên hầu hết các nền tảng không có giao diện điều khiển và tất nhiên là tầm thường đối với các trò chơi Web.

Các dịch vụ này xử lý tất cả các chi tiết lộn xộn của việc mã hóa lưu lượng đăng nhập qua mạng, lưu trữ an toàn thông tin đăng nhập và xác thực thông tin đăng nhập của người dùng. Sau đó, máy chủ trò chơi của bạn chỉ cần triển khai phần giao thức nhận cookie từ người dùng và hỏi dịch vụ xác thực xem cookie có hợp lệ hay không, có thể được thực hiện với HTTP đơn giản trong hầu hết các trường hợp.

Tôi sẽ không yêu cầu hầu hết các trò chơi nhiều người chơi truyền thống làm điều này, bởi vì họ không, nhưng tôi sẽ tuyên bố rằng hầu hết các trò chơi Web thông thường trực tuyến làm điều này.

Đối với các trò chơi truyền thống (không phải Web), có thể tạo điều kiện thuận lợi cho quy trình đăng nhập này bằng cách nhúng trình duyệt (Awesomium, Chromium Embedded Framework hoặc điều chỉnh Webkit là các lựa chọn phổ biến) hoặc bằng cách gọi ra một trình duyệt bên ngoài mặc dù vậy, hãy lấy cookie xác thực và không thực sự dễ dàng hơn việc nhúng một trong các thư viện đã nói ở trên).

Một ví dụ điển hình của phương pháp này là bất kỳ trò chơi nào của Facebook.

Trò chơi truyền thống sử dụng HTTPS

Có một dịch vụ HTTPS đơn giản để đăng nhập ngày càng bình thường. Nhiều trò chơi sử dụng các giao thức tùy chỉnh, nhưng hầu hết trong số này không đầy đủ (chúng có đăng nhập an toàn, nhưng không có cách nào an toàn để tạo / cập nhật tài khoản, vì vậy dù sao chúng cũng cần dịch vụ HTTPS) hoặc đơn giản là không an toàn.

Bạn thậm chí không cần phải đi lấy chứng chỉ SSL tùy chỉnh. Có các nhà cung cấp dịch vụ lưu trữ ứng dụng trực tuyến cung cấp cho bạn một tên miền phụ và sử dụng chứng chỉ SSL ký tự đại diện. Bạn có thể đặt dịch vụ xác thực của mình tại mygame.someservice.com, được bao phủ bởi chứng nhận ký tự đại diện * .someservice.com mà Một số Dịch vụ duy trì và bạn sẽ ổn.

Ý tưởng ở đây là người dùng đăng nhập vào dịch vụ của bạn, tạo ra một phiên cookie duy nhất, sau đó người dùng có thể chuyển vào máy chủ trò chơi chính của bạn. Sau đó, máy chủ sẽ hỏi hệ thống đăng nhập nếu cookie hợp lệ cho người dùng được yêu cầu. Thường có thời gian chờ rất ngắn trên cookie, theo thứ tự giây (ví dụ 15-30), và nó thường bị vô hiệu hóa một khi được sử dụng, khiến cho các cuộc tấn công phát lại là không thể.

Lưu ý rằng HTTPS là tùy chọn được đề xuất nhất của tôi nếu bạn dự định gửi thông tin thanh toán qua dây từ bên trong máy khách. Tuy nhiên, tốt hơn đáng kể là sử dụng bên thứ ba cho việc này. Nếu bạn nghĩ rằng việc bảo mật một cái gì đó đơn giản như mật khẩu là quá nhiều công việc, bạn thậm chí không muốn nghĩ đến việc cố gắng đáp ứng các quy tắc tuân thủ PCI tối thiểu (và khá trung thực) để lưu trữ và xử lý số thẻ tín dụng. Dù sao bạn cũng sẽ có doanh số bán hàng tốt hơn nếu bạn có người dùng sử dụng dịch vụ thanh toán của bên thứ ba đáng tin cậy mà họ đã có trong hồ sơ.

Một lợi thế mạnh mẽ của việc tách dịch vụ đăng nhập của bạn khỏi máy chủ trò chơi chính là nó cho phép chức năng bên ngoài được gắn với tài khoản người dùng độc lập với trò chơi. Bạn có thể có một số tính năng tài khoản (xem hình đại diện hoặc tương tự) trên trang web của mình hoặc có thể bạn cho phép liên kết tài khoản Facebook với tài khoản của mình hoặc có thể bạn có nhiều trò chơi chia sẻ một nền tảng tài khoản cơ bản (ví dụ: tính năng Galaxy at War của Mass Effect 3).

Một trò chơi ví dụ phổ biến sử dụng HTTPS để xác thực là Minecraft.

Xác thực web của bên thứ ba với các trò chơi của khách hàng bản địa

Có thể sử dụng các dịch vụ của bên thứ ba như Facebook Connect hoặc Google với một khách hàng bản địa. Ví dụ, Facebook có SDK gốc cho iOS và Android, cũng như Google. Một số dịch vụ cũng có SDK gốc cho các máy khách PC truyền thống.

Nếu dịch vụ đích không có SDK gốc và yêu cầu sử dụng trình duyệt Web, bạn có thể nhúng trình duyệt vào trò chơi của mình. Tuy nhiên, một số người dùng có thể không tin tưởng sử dụng trình duyệt được nhúng để nhập thông tin đăng nhập.

Bạn cũng có thể sử dụng một trình duyệt bên ngoài. Có một vài cách để thực hiện điều này. Một số yêu cầu tích hợp hệ điều hành nhiều hơn một chút so với những người khác. Một số yêu cầu bạn phải có một dịch vụ Web bên ngoài chạy cùng (hoặc ít nhất có thể truy cập bằng) máy chủ trò chơi chính của bạn. Lưu ý rằng vì Facebook và Google thường yêu cầu một URL được xác thực, bạn sẽ cần một trang đích công cộng để sử dụng các giao thức này trong (hầu hết) tất cả các trường hợp.

Cách dễ nhất và đáng tin cậy nhất, nếu không muốn nói là dễ nhất, là trả lại yêu cầu đăng nhập của bạn từ khách hàng thông qua trang web chính của bạn. Khách hàng của bạn kết nối với máy chủ trò chơi chính với tư cách là người dùng khách được xác thực và nhận được mã thông báo phiên duy nhất. Máy chủ trò chơi không cho phép khách hàng thực sự làm được nhiều việc khi ở trạng thái này; Trò chơi không biết người chơi là ai, vì vậy người chơi chưa thể trò chuyện, bắt đầu trận đấu, v.v.

Sau đó, khách hàng khởi chạy trình duyệt bên ngoài trỏ vào URL đăng nhập của tên miền trò chơi của bạn, chuyển mã thông báo phiên này dưới dạng tham số trong URL. Trang web sau đó trải qua cái bắt tay đăng nhập thông thường cho Facebook / Google.

Tại thời điểm này, máy chủ web của bạn biết rằng người dùng đã đăng nhập và có thể liên kết điều đó với mã thông báo phiên mà nó nhận được từ máy khách. Xác minh này sau đó có thể được liên lạc với máy chủ trò chơi, nâng kết nối khách không được xác thực của khách hàng thành phiên người dùng được xác thực. Điều này có thể được thực hiện bằng cách để máy chủ web liên lạc trực tiếp với máy chủ trò chơi, nếu có thể. Hoặc máy chủ trò chơi có thể thăm dò định kỳ máy chủ web về trạng thái xác thực của các kết nối khách đang chờ xử lý. Hoặc khách hàng có thể định kỳ thăm dò máy chủ web để xem đăng nhập đã hoàn tất chưa và khi có, báo hiệu cho máy chủ trò chơi yêu cầu xác minh từ máy chủ web.

Tất cả những điều này yêu cầu máy chủ trò chơi và máy chủ web của bạn có thể giao tiếp, nhưng bất kỳ dịch vụ xác thực bên thứ ba nào cũng sẽ yêu cầu máy chủ trò chơi của bạn có thể giao tiếp với thế giới bên ngoài, vì vậy điều này không gây ngạc nhiên.

Phương pháp xác thực này được tìm thấy trong một số MMO cỡ nhỏ đến trung bình.

Lưu ý rằng tất cả điều này cũng hoạt động để thực hiện các yêu cầu thanh toán thông qua một dịch vụ bên ngoài, như PayPal, Thanh toán Amazon, Google Wallet, v.v.

Kết nối TLS trực tiếp

Không quá khó để bắt đầu một phiên TLS qua giao thức luồng tùy chỉnh. Các thư viện như OpenSSL, GnuTLS, NSS và các thư viện dành riêng cho hệ điều hành khác nhau cung cấp API trình bao bọc luồng, lớp trên một giao thức / giao thức cấp thấp. Nói chung, bạn chỉ cần cung cấp byte thông qua API trình bao bọc và nó xử lý bắt tay và mã hóa.

Các phần khó khăn ở đây là đảm bảo việc sử dụng TLS của bạn được an toàn. Ví dụ, một số thư viện phổ biến sẽ yêu cầu chứng chỉ được ký hợp lệ từ cơ quan đáng tin cậy. Một số thư viện phổ biến yêu cầu điều đó, nhưng theo mặc định, không tin tưởng bất kỳ cơ quan chức năng nào. Một số trong số họ không yêu cầu chứng nhận đó là hợp lệ.

Bạn nên luôn luôn yêu cầu một chứng chỉ hợp lệ. Cho phép các certs không hợp lệ sẽ không cho phép kẻ tấn công chỉ nghe trộm để đánh cắp mật khẩu, nhưng nó vẫn sẽ cho phép các cuộc tấn công trung gian.

Cách tiếp cận này đòi hỏi tối thiểu tuyệt đối về các phụ thuộc bên ngoài trong khi vẫn cho phép bảo mật tối đa.

Ví dụ về các trò chơi sử dụng điều này hiện nay bao gồm hầu hết các MMO truyền thống lớn.

Trò chơi truyền thống an toàn (ish)

Các trò chơi không sử dụng dịch vụ riêng biệt và không sử dụng TLS thường phải thực hiện một số loại giao thức đăng nhập không dựa trên giao thức trò chơi chính của chúng. Với phương thức này, máy chủ tạo ra một số ngẫu nhiên (một nonce) và gửi nó đến máy khách. Sau đó, khách hàng băm dữ liệu đó bằng mật khẩu của người dùng (và tên người dùng, có thể là một số dữ liệu khác) và gửi phản hồi đó đến máy chủ. Sau đó, máy chủ sẽ so sánh giá trị băm này với thông tin đăng nhập có trong hồ sơ. Điều này giữ cho mật khẩu của người dùng được giữ bí mật trên dây và đảm bảo rằng bạn không thể sử dụng một cuộc tấn công phát lại đơn giản vào mật khẩu băm, giống như nhiều lược đồ đăng nhập dựa trên hàm băm yếu khác.

Một vấn đề là người dùng không có cách nào để gửi mật khẩu mới cho dịch vụ qua giao thức này một cách an toàn. Việc triển khai điển hình cũng lưu trữ mật khẩu của người dùng trong văn bản gốc trên máy chủ, đây là một hành vi khủng khiếp (nếu máy chủ của bạn bị hack, người dùng của bạn có thể đã bị đánh cắp mật khẩu email / facebook / ngân hàng, vì anh ta đang sử dụng cùng một mật khẩu cho trò chơi của bạn như ở mọi nơi khác, bởi vì người dùng có xu hướng làm điều đó).

Có các phiên bản nâng cao của chương trình đăng nhập cơ bản đó. Cơ bản nhất - mặc dù vẫn không an toàn lý tưởng - là cho máy chủ gửi mật khẩu băm mật khẩu với giá trị nonce trong khi đăng nhập. Điều này cho phép máy chủ lưu trữ mật khẩu băm (và muối) một cách an toàn trong khi cho phép khách hàng tạo cùng một hàm băm trong khi đăng nhập. Điều này cho phép kẻ tấn công lấy muối cho một mật khẩu người dùng cụ thể, nhưng điều này không đặc biệt hữu ích mà không nhận được mật khẩu băm ban đầu (không được gửi qua dây trong khi đăng nhập). Trong quá trình tạo / cập nhật mật khẩu, khách hàng sẽ gửi toàn bộ mật khẩu băm (bằng muối) mà kẻ tấn công có thể đánh hơi. Nếu hàm băm được sử dụng đủ mạnh (giả sử, sha-2/512) thì việc ép buộc thuần túy là không khả thi, mặc dù kẻ tấn công vẫn có thể dễ dàng tạo ra các mật khẩu yếu (đó là lý do tại sao thực thi một số độ dài mật khẩu tối thiểu, phân phối tối thiểu các chữ cái / số / ký hiệu và so sánh với một từ điển các mật khẩu đã biết / rõ ràng / yếu là quan trọng). Việc kẻ tấn công vẫn có thể lấy được mật khẩu băm là lý do tại sao nó vẫn an toàn hơn để thực hiện toàn bộ trao đổi mật khẩu qua một kênh được mã hóa, bảo mật.

Một số thư viện mạng trò chơi phổ biến thực hiện một số hình thức tùy chọn của giao thức này. Tôi tin rằng SmartFox là một ví dụ như vậy, mặc dù tôi chưa xem xét sâu về nó (tôi thường bỏ qua bất kỳ hệ thống xác thực thư viện nào như vậy và sử dụng phương thức HTTPS, vì nó rất đơn giản để thực hiện và mạnh hơn đáng kể). Một số trò chơi Internet không phải Web sớm cũng sử dụng phương pháp này, đặc biệt là trước khi Steam, XBL, v.v.

Trò chơi truyền thống không an toàn

Rất nhiều trò chơi không may chỉ cần gửi tên người dùng / mật khẩu trong văn bản gốc. Có thể họ băm mật khẩu, loại mơ hồ bảo vệ mật khẩu thực tế của người dùng (gần như không đủ tốt) nhưng một cuộc tấn công phát lại khiến việc đăng nhập vào dịch vụ trò chơi trở nên tầm thường.

Đừng làm điều này. Thật vô trách nhiệm và lười biếng. Sự ngây thơ trên Internet của những năm 1990 đã phổ biến các phương thức đăng nhập này không còn là lý do khả thi.

Nhiều trò chơi web và Flash trước Facebook đã sử dụng phương pháp này. Tôi không biết bất kỳ ví dụ cụ thể nào ngoài đỉnh đầu của tôi; Tôi muốn tin rằng tất cả họ đã chết từ lâu, nhưng thế giới không may mắn như thế.

Không có chứng thực

Hầu hết các trò chơi không thực hiện xác thực. Người chơi kết nối, gửi một số tay cầm để nhận dạng duy nhất bản thân và trận đấu bắt đầu. Không có máy chủ toàn cầu nào cố gắng xác nhận rằng chỉ có một người thực sự được phép tuyên bố là "CaptainMisterDude". Máy chủ cục bộ chỉ đảm bảo rằng chỉ có một trình phát hiện được kết nối có bất kỳ xử lý cụ thể nào và đó là kết thúc của nó. Các máy chủ cục bộ sử dụng danh sách đen dựa trên tên và dựa trên IP cho những người gây rắc rối. Điều này là phổ biến cho các trò chơi phong cách FPS deathmatch ngay cả ngày nay.

Nếu bạn không cần bất kỳ trạng thái vĩnh viễn nào cho các tài khoản, thì đây là giải pháp đơn giản nhất và khá "an toàn" vì thực sự không có gì để hack hoặc đánh cắp. Rõ ràng điều này không hoạt động quá tốt nếu bạn cần lưu trữ thông tin tài khoản giữa các phiên trò chơi.

Quake là một ví dụ về một trò chơi sử dụng phương pháp "xác thực" người dùng này.


1
Tại sao bạn viết nhiều về HTTPS? HTTP không đặc biệt phù hợp với giao thức chơi game. Một giao thức nhị phân được xây dựng có mục đích trong một đường hầm TLS sẽ là cách để đi.
aaaaaaaaaaaa

10
Để đăng nhập? Nó hoàn toàn phù hợp. Bạn không đăng nhập 30 lần / giây. Bạn đăng nhập một lần khi bạn khởi động máy khách và thế là xong. Đăng nhập HTTPS trả về một cookie mà giao thức nhị phân được xây dựng có mục đích sử dụng để xác thực kết nối mà không cần mật khẩu.
Sean Middleditch

1
Chỉ vì đó không phải là vấn đề hiệu suất không có nghĩa là nó không phải là một cách tiếp cận cồng kềnh làm tăng thêm sự phức tạp không cần thiết.
aaaaaaaaaaaa

4
Tôi sẽ sử dụng những từ chính xác đó để mô tả phương pháp đề xuất của bạn. Để mỗi mình. :)
Sean Middleditch

2
Vì vậy, bạn sẽ bao gồm toàn bộ thư viện HTTP để gửi 2 chuỗi một chiều và nhận lại 1 hoặc bạn sẽ tự thực hiện tập hợp con HTTP được yêu cầu, bao gồm cả xử lý chuỗi thoát?
aaaaaaaaaaaa

3

SSL sẽ giúp khách hàng xác định các máy chủ hợp pháp, so với các máy chủ "giả mạo" bằng cách sử dụng chứng chỉ máy chủ được ký bởi một CA đã biết. Tôi nghi ngờ rằng hầu hết các trò chơi không bận tâm để làm điều này.

Tuy nhiên, có những lý do tốt tại sao họ có thể muốn. Một số cơ chế tránh / gian lận cấp phép có thể hoạt động bằng cách sử dụng máy chủ giả mạo hoặc máy chủ "người đứng giữa".

Tôi hy vọng các mạng nhiều người chơi lớn như Steam và Microsoft, có tích hợp bảo vệ như vậy.

Trò chơi dựa trên web có thể chỉ đơn giản là sử dụng HTTPS, nhưng tôi không biết liệu trò chơi đó có hoạt động với Websockets hay không (một Google tầm thường sẽ trả lời nó).

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.