2011-08-19 26 views
43

Ứng dụng Android của tôi chứa bí mật người dùng OAuth cho API của Twitter. Hiện tại, tệp này ở dạng .properties tệp ở dạng văn bản thuần túy, vì vậy, sẽ không mất nhiều công sức để ai đó tìm kiếm trong APK.Tôi có nên làm xáo trộn bí mật người dùng OAuth được ứng dụng Android lưu trữ không?

Tôi có nên thực hiện các bước để làm mờ nó (như, rot13 hoặc được lưu trữ trong mã Java bị xáo trộn) không? Hay tôi thực sự nên tránh làm bất cứ điều gì, vì nó sẽ tạo ra cảm giác an toàn sai lầm?

Mọi người thường phân phối/lưu trữ bí mật OAuth trong ứng dụng Android như thế nào? Thông thường bí mật bị đánh cắp và lạm dụng là gì?

+0

Tôi có cùng một chiến lược với ứng dụng iOS và NodeJS + ExpressJS + PassportJS tại chương trình phụ trợ. Tôi sử dụng Twitter auth đảo ngược để xác thực người dùng từ iOS. Nhưng để đảm bảo điều này và ngăn chặn người dùng đánh cắp các gói HTTP ở giữa để tìm hiểu xem có gì trong các tiêu đề, tôi dự định sử dụng HTTPS trên các máy chủ của mình để mã hóa dữ liệu. Kiểm tra điều này để tránh nhúng các khóa bí mật trong ứng dụng của bạn: https: //dev.twitter.com/docs/ios/using-reverse-auth – Maziyar

+0

Lưu ý: Reverse Auth chỉ dành cho iOS –

Trả lời

40

Câu hỏi thực sự là những gì hiện kẻ tấn công có được từ ăn cắp nó ...

Bạn nên cố gắng hết sức để bảo vệ bí mật nhưng cuối cùng, một hacker có động lực cao luôn có thể có được nó trong một ứng dụng được cài đặt. Vì vậy, đó là giá trị của bí mật so với khó khăn của khai thác.

Giá trị của bí mật ứng dụng đang mạo danh ứng dụng. Nó không cung cấp quyền truy cập vào dữ liệu người dùng. Tuy nhiên, vì Twitter hỗ trợ tự động cấp chứng chỉ cho các ứng dụng đã được phê duyệt trước đó (đăng nhập bằng luồng Twitter), kẻ tấn công có thể tạo ứng dụng web với bí mật và lấy cắp dữ liệu người dùng của bạn bằng cách sử dụng chuyển hướng mù.

Vấn đề với việc triển khai của Twitter là họ không hỏi nhà phát triển về bản chất của ứng dụng. Nếu họ đã làm, họ sẽ không đưa cho bạn một bí mật để bắt đầu, và sẽ chặn bất cứ ai xây dựng một ứng dụng web bằng cách sử dụng thông tin khách hàng của bạn và ăn cắp dữ liệu từ những người dùng đã chấp thuận nó.

Làm xáo trộn là một tùy chọn, nhưng là một tùy chọn yếu. Di chuyển bí mật đến máy chủ web hoạt động như một proxy API là một proxy khác, nhưng điều đó chỉ di chuyển vấn đề ở nơi khác vì bây giờ ứng dụng của bạn phải xác thực với máy chủ proxy. Tuy nhiên, mẫu này có thể an toàn hợp lý nếu bạn yêu cầu người dùng đăng nhập vào trang web của bạn (có thể sử dụng, thông qua lượt xem web, Twitter để đăng nhập). Bằng cách này, ai đó đang cố gắng lạm dụng proxy của bạn sẽ cần người dùng của họ mở tài khoản trên dịch vụ của bạn, điều này không hấp dẫn lắm.

Tóm lại, hãy tiếp tục và làm xáo trộn nó. Nó không đau. Cân nhắc sử dụng mẫu proxy. Và có thể cho Twitter biết chính sách bảo mật của họ "không tuyệt vời".

+0

Cảm ơn câu trả lời. Các ứng dụng tôi đang làm việc trên sẽ không được ứng dụng xã hội cao hồ sơ, tweeting từ nó là một tính năng phụ. Vì vậy, tôi nghĩ rằng tôi sẽ đi với một số obfuscation, nhưng sẽ bỏ qua sự phức tạp thêm của mô hình proxy. –

+0

Tuyệt vời để xem điểm của tôi được tăng cường bởi một người nào đó trong biết. Trong khi proxy đang di chuyển vấn đề ở nơi khác, một hacker sẽ phải viết một chương trình cụ thể để lạm dụng proxy của bạn. Trong thực tế, họ sẽ đơn giản thu hoạch bí mật của người tiêu dùng từ các ứng dụng khác - có [hơn một triệu ứng dụng của bên thứ ba] (http://techcrunch.com/2011/08/19/twitter-releases-bootstrap-a-set-of- công cụ-xây dựng-web-ứng dụng-sử dụng-css /? utm_source = feedburner & utm_medium = feed & utm_campaign = Nguồn cấp dữ liệu% 3A + Techcrunch +% 28TechCrunch% 29) trên mạng, sau khi tất cả. –

+1

Có một URL CallBack trong Twitter Apps, điều này sẽ đủ để ngăn chặn tin tặc từ việc xây dựng ứng dụng web ăn cắp dữ liệu? Nó phải là miền bạn đặt vào cài đặt ứng dụng của bạn nếu không nó sẽ không cho phép bất cứ điều gì bạn gửi. – Maziyar

-3

Điểm chính của 0Auth là bạn không lưu trữ bất kỳ thông tin nhạy cảm quý giá nào trên thiết bị - để lưu trữ bí mật trên thiết bị (tốt hơn là thông tin xác thực người dùng thực). Trong trường hợp bí mật thiết bị của bạn bị đánh cắp, người dùng luôn có thể vô hiệu hóa quyền truy cập mà không cần phải thay đổi thông tin đăng nhập của mình

+0

Rất tiếc nhưng nếu ai đó tìm thấy bí mật người tiêu dùng của ứng dụng của bạn, họ có thể giả vờ là ứng dụng của bạn. Bạn có thể thay đổi chìa khóa và bí mật nhưng sau đó tất cả các cài đặt của bạn trong lĩnh vực này không thể tweet nữa. – funkybro

+0

Không có cách nào để ẩn nội dung nào đó bên trong ứng dụng của bạn từ người được xác định (thậm chí OS 360 được thiết kế ngược và được vá bằng mã máy ở Nga). Và ngay cả khi ai đó giả vờ là ứng dụng của bạn, người dùng sẽ vẫn phải xác thực mình chống lại dịch vụ - vì vậy không có sự thỏa hiệp thực sự ở đó. –

+2

Tôi nghĩ câu trả lời này đã nhầm lẫn bí mật người tiêu dùng với mã thông báo oauth. –

4

Tôi chắc chắn sẽ đọc this analysis bởi một trong những tác giả OAuth, Eran Hammer-Lahav, trích dẫn một số khác article dissecting Twitter's OAuth secret problems.

Lời khuyên của tôi sẽ là làm xáo trộn khóa để nó không thể được trích xuất một cách bình thường và bạn nên an toàn với các vũ công và người gửi spam.

Ý kiến ​​của Hammer-Lahav là không nên thu hồi bí mật OAuth và chỉ nên sử dụng để thu thập số liệu thống kê. Hy vọng rằng Twitter đang theo lời khuyên này.

+2

Bài báo nói "không sử dụng bí mật của khách hàng trong các ứng dụng đã cài đặt", và lời khuyên của bạn là làm ngược lại ... –

+0

@Graham Điểm tuyệt vời - Tôi nên rõ ràng hơn một chút. Nếu OP đang có kế hoạch tiến hành thì obfuscation * là * imporant. Nếu không, tôi đoán bạn cần triển khai nơi bí mật được lưu trữ trên máy chủ từ xa và dịch vụ web hoạt động như một proxy cho các cuộc gọi OAuth. Tôi không biết thực hành tốt nhất là gì cho phương pháp này. –

Các vấn đề liên quan