Làm cách nào để giữ bí mật người dùng OAuth và cách phản ứng khi bị xâm nhập?

Question

Câu hỏi này là về việc tìm hiểu các rủi ro bảo mật liên quan đến việc triển khai oauth trên nền tảng di động như Android. Giả định ở đây là chúng ta có một ứng dụng Android có khóa/mật khẩu người tiêu dùng được nhúng trong mã.

Giả sử bí mật của người tiêu dùng đã bị xâm phạm và tin tặc đã nắm giữ nó, hậu quả của việc này là gì?

giả định

xâm Bí mật người dùng
Tôi thích hợp trong tuyên bố rằng một mật của người dùng bị tổn thương như vậy không ảnh hưởng đến an ninh của người dùng, hoặc bất kỳ dữ liệu được lưu trữ tại các nhà cung cấp cho phép OAuth mà người dùng đã tương tác với. Bản thân dữ liệu không bị xâm nhập và hacker không thể truy lục dữ liệu.

Hacker sẽ cần giữ mã thông báo truy cập người dùng hợp lệ và điều đó khó khăn hơn nhiều.

Tin tặc có thể làm gì với bí mật của người tiêu dùng bị xâm phạm?
Tôi cũng đúng trong đó nêu như sau:

• Các hacker có thể thiết lập/phát hành một ứng dụng mà bắt chước ứng dụng của tôi.
• Tin tặc có thể thu hút người dùng sẽ truy cập thông qua luồng OAuth, truy xuất mã thông báo truy cập qua tin tặc OAuth khiêu vũ (sử dụng khóa/bí mật của người tiêu dùng bị xâm nhập ).
• Người dùng có thể nghĩ rằng anh ấy đang xử lý ứng dụng của tôi, vì anh ta sẽ xem tên quen thuộc (khóa người dùng) trong quá trình ủy quyền.
• Khi một người tiêu dùng đưa ra một yêu cầu qua các hacker, các hacker có thể dễ dàng đánh chặn access token, và kết hợp với bí quyết của người tiêu dùng có thể tại ký yêu cầu thay mặt tôi để tăng quyền truy cập vào các nguồn tài nguyên của tôi.

End-user tác động
Trong giả định rằng

• một hacker đã cài đặt một ứng dụng/ trang web sử dụng của người tiêu dùng của tôi bí mật
• một trong những người dùng của tôi đã bị lừa vào phép truy cập vào ứng dụng/trang web đó

Theo dõi g có thể xảy ra:

• người dùng cuối có thể là nhận thấy rằng một cái gì đó tanh đang xảy ra, và thông báo cho nhà cung cấp dịch vụ (ví dụ: Google) về ứng dụng độc hại
• cung cấp dịch vụ thì có thể thu hồi chìa khóa tiêu dùng/bí mật

OAuth tiêu dùng (ứng dụng của tôi) tác động:
ứng dụng của tôi (có chứa các bí mật của người tiêu dùng) sẽ cần phải được cập nhật, nếu không tất cả các khách hàng của tôi sẽ không thể cho phép ứng dụng của tôi làm gì để yêu cầu thay mặt họ nữa (vì bí mật người tiêu dùng của tôi sẽ không còn hợp lệ nữa).

ủy thác tất cả giao thông OAuth
Mặc dù nó sẽ có thể để ủy thác rất nhiều sự tương tác OAuth thông qua một máy chủ web trung gian (thực hiện điệu nhảy OAuth và gửi thẻ truy cập cho người dùng), người ta sẽ có để proxy tất cả tương tác dịch vụ cũng như yêu cầu khóa/bí mật của người tiêu dùng để ký từng yêu cầu. Đây có phải là cách duy nhất để giữ bí mật/khóa người dùng bên ngoài ứng dụng dành cho thiết bị di động và được lưu trữ ở một nơi an toàn hơn trên máy chủ web trung gian không?

Giải pháp thay thế
Có các lựa chọn thay thế cho proxy này không? Có thể lưu trữ bí mật của người tiêu dùng tại máy chủ web trung gian hay không và có một số loại cơ chế mà ứng dụng Android (xuất bản trên thị trường và được ký hợp đồng), có thể thực hiện yêu cầu an toàn tới máy chủ web trung gian để tìm bí mật người tiêu dùng và lưu trữ nó trong ứng dụng? Cơ chế có thể được thực hiện là máy chủ web trung gian "biết" rằng đây là ứng dụng Android chính thức yêu cầu tìm nạp bí mật của người tiêu dùng và máy chủ web trung gian sẽ chỉ tiết lộ bí mật của người tiêu dùng cho ứng dụng android cụ thể đó không?

Answer 1

Tóm tắt: Tôi sẽ chỉ mạo hiểm và giữ bí mật trong ứng dụng khách.

Proxy server thay thế:

Cách duy nhất bạn có thể hợp lý giảm thiểu những vấn đề tôi liệt kê dưới đây và làm cho công việc proxy-ing, sẽ được đi trong chín bãi cả - di chuyển tất cả các logic kinh doanh ngành nghề với các tài nguyên trên webservice của bên thứ ba tới máy chủ proxy của bạn và làm cho ứng dụng khách câm thiết bị đầu cuối có giao diện người dùng phong phú. Bằng cách này, các hành động duy nhất mà ứng dụng độc hại có thể làm cho proxy thực hiện thay mặt cho nó sẽ chỉ là những gì logic kinh doanh của bạn cần hợp pháp.

Nhưng giờ đây, bạn đã ở trong lĩnh vực toàn bộ các vấn đề khác phải đối phó với độ tin cậy và khả năng mở rộng.

thảo luận dài về việc tại sao Proxy đơn giản sẽ không làm việc:

Một số người, khi phải đối mặt với một vấn đề , suy nghĩ: “Tôi biết, tôi sẽ thêm máy chủ proxy của riêng tôi” Bây giờ họ có hai sự cố . (với lời xin lỗi tới Jamie Zawinski)

Giả định của bạn phần lớn là đúng. Phải xuống đến điểm bạn bắt đầu nghĩ về máy chủ của riêng mình, cho dù nó giữ bí mật và proxy các cuộc gọi cho ứng dụng khách hay nó cố gắng xác định xem ứng dụng có hợp pháp hay không và cho nó bí mật. Trong cả hai cách tiếp cận, bạn vẫn phải giải quyết vấn đề "là yêu cầu này đến từ một đoạn mã tôi đã viết"?

Để tôi lặp lại - không có cách nào để phân biệt trên dây mà phần mềm cụ thể đang chạy. Nếu dữ liệu trong các thông báo có vẻ đúng, không có gì có thể chứng minh đó là một ứng dụng khác đang gửi tin nhắn đó.

Vào cuối ngày, nếu tôi đang viết một ứng dụng độc hại, tôi không quan tâm nếu tôi thực sự biết bí mật thực sự, miễn là tôi có thể làm cho ai đó biết điều đó làm một công việc thay cho tôi. Vì vậy, nếu bạn cho rằng ứng dụng độc hại có thể mạo danh ứng dụng của bạn đến máy chủ OAuth của bên thứ ba, tại sao bạn chắc chắn ứng dụng đó không thể mạo danh ứng dụng của bạn với proxy?

Nhưng chờ đợi, có nhiều hơn. Miền mà dịch vụ proxy của bạn nằm ở đó, là danh tính của bạn cho cả khách hàng của bạn và nhà cung cấp OAuth (như được hiển thị cho người dùng cuối bởi nhà cung cấp OAuth). Nếu một ứng dụng độc hại có thể làm cho máy chủ của bạn hoạt động không tốt, không chỉ là khóa của bạn bị thu hồi, nhưng danh tính web công khai của bạn cũng không đáng tin cậy nữa.

---

Tôi sẽ bắt đầu với điều hiển nhiên - không có cách nào để phân biệt trên dây mà phần mềm cụ thể đang chạy. Nếu dữ liệu trong các thông báo có vẻ đúng, không có gì có thể chứng minh đó là một ứng dụng khác đang gửi tin nhắn đó.

Do đó, bất kỳ thuật toán nào dựa vào bí mật được lưu trữ bên ứng dụng đều có thể bị giả mạo. Sức mạnh của OAuth là nó không bao giờ cung cấp thông tin đăng nhập của người dùng cho ứng dụng, thay vào đó cung cấp thông tin đăng nhập tạm thời cho ứng dụng của riêng nó mà người dùng có thể thu hồi nếu cần.

Tất nhiên, điểm yếu ở đây là ứng dụng đủ tốt có thể khiến người dùng tin tưởng và không thu hồi thông tin xác thực trước khi hoàn thành hành động bất chính của mình.

Tuy nhiên, một cách để giảm thiểu điều này là cách tiếp cận của Google khi sử dụng OAuth mạng-máy chủ, thay vì tiêu chuẩn 2 chân. Trong OAuth mạng-máy chủ 3, không có bí mật được chỉ định trước, nhưng trên mọi xác thực, một bí mật mã thông báo truy cập mới được phát hành cùng với mỗi mã thông báo truy cập. Trong khi cuối cùng điều này cũng bị hạn chế, vì một ứng dụng tồi có thể đọc bí mật mã thông báo của ứng dụng tốt từ quá trình của nó, điều đó dẫn đến việc người dùng phải phê duyệt quyền truy cập ứng dụng mỗi khi cần mã thông báo truy cập mới.

Và tất nhiên, điều này cũng có nghĩa là nó hơi bất tiện và khó chịu hơn cho người dùng.