Là giải pháp này RESTful và an toàn?

Sản phẩm của chúng tôi đăng ký người chơi mới trên dịch vụ của chúng tôi và chúng tôi đã chọn lưu trữ nó trên Azure (chúng tôi đang sử dụng .NET) và chúng tôi muốn nó không trạng thái (cho khả năng mở rộng) và tương đối an toàn.

Vì đây là REST WS đầu tiên tôi viết, tôi muốn nhận được một số phản hồi về việc đó có phải là một giải pháp vững chắc hay không.

Một số giả định để biết về ứng dụng của chúng tôi:

1. Người dùng đăng nhập vào dịch vụ ẩn danh mà không yêu cầu mật khẩu từ người dùng
2. WS phải hoàn toàn không trạng thái để cho phép mở rộng theo chiều ngang
3. Chúng tôi đang kết nối bằng HTTPS (SSL) để ngăn chặn rình mò bên thứ 3

BIÊN TẬP:

1. Chúng tôi nhắm mục tiêu cho các thiết bị iOS / Android gốc
2. Mối quan tâm chính của chúng tôi là đảm bảo chỉ những khách hàng không bị giả mạo mới có thể gửi yêu cầu

Và quy trình xác thực trừu tượng:

1. Máy khách tạo một hàm băm đơn giản (UDID: Dấu thời gian) và mã hóa nó bằng dấu thời gian với một số thuật toán cơ bản (ví dụ: khóa bí mật là mỗi ký tự thứ 2 từ hàm băm)
2. Máy khách gửi UDID, Dấu thời gian & hàm băm của mình đến máy chủ
3. Máy chủ xây dựng lại hàm băm và giải mã hàm băm được mã hóa được gửi từ người dùng
4. Nếu hai cái bằng nhau - chúng tôi biết rằng nó thực sự được gửi từ khách hàng của chúng tôi (và hy vọng không phải từ một người gửi độc hại)

Bất kỳ đầu vào / đề xuất nào cũng sẽ rất tuyệt - rõ ràng vì đây là lần đầu tiên tôi xử lý vấn đề này, tôi có thể đã thiết kế nó không chính xác.

Cảm ơn!

Cập nhật lần 2:

Đọc thông số kỹ thuật bảo mật cho OAuth, dường như không có câu trả lời thực sự cho câu hỏi của tôi - vì máy khách và máy chủ phải biết các khóa bí mật và máy khách được lưu trữ cục bộ trên thiết bị di động của người dùng của chúng tôi (trái ngược với ứng dụng web).

Từ hướng dẫn bảo mật OAuth ( http://hueniverse.com/oauth/guide/security/ ):

Khi thực hiện OAuth, điều quan trọng là phải hiểu những hạn chế của các bí mật được chia sẻ, đối xứng hoặc không đối xứng. Bí mật máy khách (hoặc khóa riêng) được sử dụng để xác minh danh tính của máy khách bởi máy chủ. Trong trường hợp máy khách dựa trên web như máy chủ web, việc giữ bí mật máy khách (hoặc khóa riêng) là tương đối dễ dàng.

Tuy nhiên, khi ứng dụng khách là ứng dụng trên máy tính để bàn, ứng dụng dành cho thiết bị di động hoặc bất kỳ phần mềm phía máy khách nào khác như applet trình duyệt (Flash, Java, Silverlight) và tập lệnh (JavaScript), phải có thông tin đăng nhập của khách hàng trong mỗi bản sao của ứng dụng . Điều này có nghĩa là bí mật của máy khách (hoặc khóa riêng) phải được phân phối cùng với ứng dụng, vốn đã thỏa hiệp chúng.

Điều này không ngăn chặn việc sử dụng OAuth trong ứng dụng đó, nhưng nó giới hạn mức độ tin cậy mà máy chủ có thể có trong các bí mật công khai đó. Vì các bí mật không thể tin cậy được, nên máy chủ phải coi ứng dụng đó là các thực thể không xác định và chỉ sử dụng danh tính khách hàng cho các hoạt động không yêu cầu bất kỳ mức độ tin cậy nào, chẳng hạn như thu thập số liệu thống kê về các ứng dụng. Một số máy chủ có thể chọn cấm ứng dụng đó hoặc cung cấp các giao thức hoặc tiện ích mở rộng khác nhau. Tuy nhiên, tại thời điểm này không có giải pháp được biết đến cho giới hạn này.

Điều này có phần tắt trên một tiếp tuyến, nhưng từ quan điểm bảo mật, bất kỳ bí mật nào trên máy khách không phải là bí mật. Bạn nêu trong câu hỏi của bạn rằng.

Mối quan tâm chính của chúng tôi là đảm bảo chỉ những khách hàng không bị giả mạo mới có thể gửi yêu cầu.

Là một người đã làm việc trong ngành công nghiệp game, đây là một nguyên nhân bị mất. Nếu có đủ giá trị để có thể gửi các yêu cầu tùy ý, người dùng sẽ tìm ra cách gửi các yêu cầu đó. Bạn không bao giờ có thể dựa vào việc có thể biết liệu một yêu cầu đến từ một khách hàng đáng tin cậy hay không. Dưới đây là một số lời khuyên từ kinh nghiệm của tôi.

• Giữ bản sao chính thức của trạng thái trò chơi trên máy chủ
• Hình những thay đổi của chúng tôi đối với trạng thái mà mỗi người dùng có thể thực hiện và kiểm tra vi phạm phía máy chủ.
• Có giới hạn tỷ lệ về mức độ nhanh chóng người dùng có thể tăng cấp hoặc kiếm tiền / vật phẩm để bắt tập lệnh.
• Nếu kẻ lừa đảo không thể làm đau lòng người chơi khác thì đừng cấm họ. Rất nhiều người gian lận cũng là người chi tiêu.
• Có sự kiểm soát xã hội đối với những kẻ lừa đảo tức là để những kẻ gian lận trở nên rõ ràng với bạn bè của họ. Nếu bạn có thể có logic phù hợp hơn thì kẻ gian lận sẽ bị loại khỏi cuộc chơi với bạn bè của họ.

Chìa khóa về REST là bạn đang sử dụng các tính năng vốn có trong http:

• NHẬN: chỉ đơn giản là lấy dữ liệu
• POST: để chèn một điểm dữ liệu mới
• PUT: để cập nhật điểm dữ liệu
• XÓA: để xóa một điểm dữ liệu

Một số hướng dẫn khác là các url của bạn phải trực quan, nghĩa là nếu url của bạn dành cho người chơi http://example.com/api/playerthì đó là một cách hợp lý để tiết lộ lịch sử điểm số cuối cùng của họ có thể là http://example.com/api/player/1/scores(ví dụ: điểm cho id người chơi 1).

Về bảo mật, những gì bạn đã đọc từ thông số OAuth là rất đúng ... nếu bạn đang nhúng một loại khóa riêng nào đó vào tệp nhị phân mà người khác có thể có được, bạn không thể cho rằng nó hoàn toàn riêng tư. Tôi sẽ đề nghị rằng nếu bạn có bất kỳ loại khóa riêng nào trong mã của mình, bạn hãy thiết lập nó để bạn có thể hết hạn, sau đó đẩy ra một bản cập nhật để thay đổi nó. Bằng mọi cách, hãy tận dụng cơ hội để bảo vệ nó bằng mã hóa và tất cả phần còn lại, nhưng làm cho nó dễ dàng vô hiệu hóa nếu nó bị hack. Thực tế là twitter et al phải chịu thử thách tương tự, trong đó thỉnh thoảng các khóa bí mật cho các ứng dụng chính thức của họ được phát hiện và đăng trên internet, và họ phải cập nhật ứng dụng của mình.