Làm cách nào để lưu trữ khóa tiêu dùng OAuth v1 và bí mật cho máy khách Twitter máy tính để bàn nguồn mở mà không tiết lộ cho người dùng?

Tôi muốn tạo một máy khách dày, máy tính để bàn, máy khách twitter nguồn mở. Tôi tình cờ sử dụng .NET làm ngôn ngữ của tôi và Twitterizer làm trình bao bọc OAuth / Twitter của tôi và ứng dụng của tôi có thể sẽ được phát hành dưới dạng nguồn mở.

Để có được mã thông báo OAuth, cần có bốn thông tin:

1. Mã thông báo truy cập (tên người dùng twitter)
2. Truy cập bí mật (mật khẩu twitter)
3. Khóa tiêu dùng
4. Bí mật người tiêu dùng

Hai thông tin thứ hai không được chia sẻ, như khóa riêng PGP. Tuy nhiên, do cách thức luồng ủy quyền OAuth được thiết kế, những điều này cần phải có trên ứng dụng gốc. Ngay cả khi ứng dụng không phải là nguồn mở và khóa / bí mật của người tiêu dùng được mã hóa, một người dùng có kỹ năng hợp lý có thể có quyền truy cập vào cặp khóa / bí mật của người tiêu dùng.

Vì vậy, câu hỏi của tôi là, làm thế nào để tôi khắc phục vấn đề này? Chiến lược thích hợp cho máy khách Twitter để bàn để bảo vệ khóa và bí mật của người tiêu dùng là gì?

Tôi tìm thấy một câu trả lời phản ánh con đường tôi đang xem xét đi xuống hueniverse . Bài viết, Vượt ra ngoài luồng chuyển hướng web OAuth , đưa ra một số gợi ý, một trong số đó là một url web hỗ trợ quá trình trao đổi mã thông báo. Tôi phải tìm ra cách xác thực chính xác rằng ứng dụng của tôi là thứ đang yêu cầu xác thực cho trang proxy này. Tuy nhiên, điều đó là có thể.

Tôi có thể sai, nhưng nếu bạn bó các khóa với ứng dụng máy tính để bàn hoặc thiết bị di động, nguồn mở hay không, có thể truy cập chúng. Nếu các dịch vụ như Twitter và Tumblr buộc chúng tôi sử dụng API chỉ dành cho OAuth, chúng tôi có hai tùy chọn:

• thiết lập dịch vụ proxy xác thực cho mọi ứng dụng
• gói chìa khóa với ứng dụng

Cái trước khó hơn và tốn kém hơn, không nhất thiết phải duy trì cho các ứng dụng nguồn mở và nhỏ. Cái sau có nghĩa là ứng dụng có thể và sẽ bị chặn, một khi kẻ gửi thư rác lấy cắp chìa khóa. Vì Twitter và Tumblr chưa cung cấp tùy chọn nào tốt hơn và bao gồm tất cả các máy khách máy tính để bàn, bao gồm các máy khách nguồn mở, có một đề xuất để phân phối các khóa "Cá lớn" và sử dụng chúng làm dự phòng .

Cuối cùng, có một tùy chọn để buộc mọi người dùng có được các khóa API.

Mục 4.6 của RFC 5849 , định nghĩa OAuth 1, nói rằng bí mật người tiêu dùng không bao giờ được sử dụng cho người tiêu dùng máy tính để bàn, mặc dù thực tế sử dụng Twitter trong thực tế. Như Nelson Elhage đã chỉ ra trong " Twitter thân mến ", Twitter có thể và chấm dứt các khóa khách hàng của máy khách để bàn, với điều kiện là máy khách không quá lớn để thất bại. Nhưng có hai cách giải quyết để cho phép sử dụng OAuth 1 trong ứng dụng máy tính để bàn hoặc thiết bị di động.

Một cách là ủy quyền toàn bộ giao thức Twitter thông qua một máy chủ mà bạn vận hành. Bằng cách này, bí mật của người tiêu dùng vẫn ở trên máy chủ của bạn. Đây là cách giải quyết được đề xuất bởi Dick Hardt , biên tập viên của thông số OAuth 1. Cách giải quyết này không giải quyết được chi phí vận hành máy chủ này.

Một cách khác, như được đề xuất trong một bài đăng của Raffi Krikorian cho nhóm phát triển Twitter nói về Google và một bài đăng của Chris Steipp vào danh sách gửi thư trên Wikipedia, là "để mỗi người dùng đăng ký bản sao ứng dụng máy tính để bàn của bạn với tư cách là người tiêu dùng của họ." Sau đó, người dùng sẽ sao chép và dán khóa người tiêu dùng mới đăng ký và bí mật người tiêu dùng vào ứng dụng của bạn. Hướng dẫn cho ứng dụng của bạn sau đó sẽ cần bao gồm các hướng dẫn chi tiết về cách đăng ký ứng dụng mới trên trang web dành cho nhà phát triển của Twitter. Giới hạn chính thức này có một vài vấn đề thực tế:

• Khách hàng của bạn sẽ gặp bất lợi về khả năng sử dụng so với các khách hàng độc quyền nổi tiếng.
• Biểu mẫu để tạo một ứng dụng mới dường như không cung cấp một cách để điền trước các trường bắt buộc. Điều này có nghĩa là bạn sẽ phải cập nhật hướng dẫn đăng ký trong hướng dẫn sử dụng của mình bất cứ khi nào Twitter thay đổi quy trình đăng ký ứng dụng.
• Thỏa thuận nhà phát triển yêu cầu người dùng phải đủ tuổi hợp pháp để tham gia hợp đồng ràng buộc. Điều này có nghĩa là người dùng ứng dụng của bạn từ 13 đến 17 tuổi phải có cha mẹ chấp nhận thỏa thuận thay mặt người dùng.
• Chính sách dành cho nhà phát triển của Twitter nghiêm cấm các ứng dụng đăng ký hàng loạt và "squat tên", được định nghĩa là "gửi nhiều ứng dụng có cùng chức năng dưới các tên khác nhau." Tôi không biết về bất kỳ tiền lệ nào về việc liệu Twitter có đối xử với những người dùng không liên quan, những người đã đăng ký các bản sao riêng biệt của một ứng dụng là "kẻ gọi tên" hay không.

Tôi sẽ trả lời nhưng được cảnh báo rằng tôi đã không tự mình giải quyết vấn đề này, tôi sẽ từ bỏ các thực tiễn tốt nhất và kinh nghiệm có liên quan hiện có;

Tôi sẽ không lo lắng về nó quá nhiều. Nếu khách hàng của bạn là mã nguồn mở thì họ sẽ có quyền truy cập vào các nguồn dù sao, và cố gắng để kiểm soát những gì họ làm với chương trình của bạn đi ngược lại bản chất của mã nguồn mở anyway (quan trọng tuy nhiên, những gì bạn đang cố gắng làm không ).

Nếu ai đó có đủ kiến ​​thức để gỡ lỗi chương trình của bạn và trích xuất khóa của bạn, họ có thể biết cách làm nhiều hơn thế và bạn rất có thể đang lãng phí thời gian để cố gắng khóa máy hơn nữa.

Để phòng ngừa, tôi sẽ thay đổi khóa thường xuyên (nếu có thể), nhưng nếu tất cả những gì họ có thể làm là giả vờ là chương trình của bạn thì điều đó nghe có vẻ không quá nghiêm trọng đối với tôi.

Tiết lộ đầy đủ, tôi không quen thuộc với Twitters API, API của twitterizer, các yêu cầu oauth hoặc bất cứ điều gì khác mà tôi nói có vẻ đáng nghi;)

Khóa và bí mật của người tiêu dùng bị ràng buộc bởi ứng dụng và không bị ràng buộc bởi người dùng. Với sự hình thành này, nhà cung cấp OAuth biết ứng dụng đó đang xử lý ứng dụng nào. Phần còn lại, mã thông báo truy cập và bí mật sẽ được lấy sau khi các bước đầu tiên được thực hiện.

Xem bài đăng trên blog này để biết thêm thông tin vì nó cho thấy giao thức hoạt động như thế nào.