Bí mật OAuth trong ứng dụng di động

Khi sử dụng giao thức OAuth, bạn cần một chuỗi bí mật thu được từ dịch vụ bạn muốn ủy quyền. Nếu bạn đang làm điều này trong một ứng dụng web, bạn chỉ cần lưu trữ bí mật trong cơ sở dữ liệu của mình hoặc trên hệ thống tệp, nhưng cách tốt nhất để xử lý nó trong ứng dụng di động (hoặc ứng dụng máy tính để bàn cho vấn đề đó) là gì?

Lưu trữ chuỗi trong ứng dụng rõ ràng là không tốt, vì ai đó có thể dễ dàng tìm thấy nó và lạm dụng nó.

Một cách tiếp cận khác là lưu trữ nó trên máy chủ của bạn và để ứng dụng tải nó trên mỗi lần chạy, không bao giờ lưu trữ nó trên điện thoại. Điều này gần như là xấu, bởi vì bạn phải bao gồm URL trong ứng dụng.

Giải pháp khả thi duy nhất tôi có thể đưa ra là trước tiên hãy lấy Mã thông báo truy cập như bình thường (tốt nhất là sử dụng chế độ xem web bên trong ứng dụng), sau đó định tuyến tất cả thông tin liên lạc qua máy chủ của chúng tôi, sẽ nối thêm bí mật vào dữ liệu yêu cầu và liên lạc với nhà cung cấp. Sau đó, một lần nữa, tôi là một người không bảo mật, vì vậy tôi thực sự muốn nghe một số ý kiến ​​của người dân về vấn đề này. Đối với tôi, dường như hầu hết các ứng dụng sẽ không đảm bảo tính bảo mật (ví dụ: Facebook Connect dường như cho rằng bạn đặt bí mật vào một chuỗi ngay trong ứng dụng của mình).

Một điều khác: Tôi không tin rằng bí mật có liên quan đến việc yêu cầu Mã thông báo truy cập ban đầu, do đó có thể được thực hiện mà không liên quan đến máy chủ của chúng tôi. Tôi có đúng không?

Vâng, đây là một vấn đề với thiết kế OAuth mà chúng ta đang phải đối mặt. Chúng tôi đã chọn proxy tất cả các cuộc gọi thông qua máy chủ của chúng tôi. OAuth hoàn toàn không bị loại bỏ đối với các ứng dụng máy tính để bàn. Không có giải pháp hoàn hảo cho vấn đề mà tôi đã tìm thấy mà không thay đổi OAuth.

Nếu bạn nghĩ về nó và đặt câu hỏi tại sao chúng tôi có bí mật, chủ yếu là để cung cấp và vô hiệu hóa các ứng dụng. Nếu bí mật của chúng tôi bị xâm phạm, thì nhà cung cấp chỉ có thể thực sự thu hồi toàn bộ ứng dụng. Vì chúng tôi phải nhúng bí mật của mình vào ứng dụng máy tính để bàn, chúng tôi rất khó chịu.

Giải pháp là có một bí mật khác nhau cho mỗi ứng dụng máy tính để bàn. OAuth không làm cho khái niệm này dễ dàng. Một cách là người dùng tự mình tạo một bí mật và tự nhập khóa vào ứng dụng trên máy tính để bàn của bạn (một số ứng dụng facebook đã làm điều tương tự trong một thời gian dài, để người dùng đi và tạo facebook để thiết lập các tùy chỉnh của họ và tào lao). Đó không phải là một trải nghiệm tuyệt vời cho người dùng.

Tôi đang làm việc theo đề xuất cho một hệ thống ủy quyền cho OAuth. Khái niệm là sử dụng khóa bí mật của riêng chúng tôi nhận được từ nhà cung cấp của chúng tôi, chúng tôi có thể phát hành bí mật được ủy quyền của riêng mình cho các khách hàng máy tính để bàn của riêng chúng tôi (một cho mỗi ứng dụng máy tính để bàn) và sau đó trong quá trình xác thực, chúng tôi gửi khóa đó lên cấp cao nhất nhà cung cấp gọi lại cho chúng tôi và xác nhận lại với chúng tôi. Bằng cách đó, chúng tôi có thể thu hồi các bí mật của riêng mình mà chúng tôi đưa ra cho mỗi khách hàng máy tính để bàn. (Mượn rất nhiều cách thức hoạt động của SSL này). Toàn bộ hệ thống này sẽ hoàn hảo cho các dịch vụ web giá trị gia tăng cũng như chuyển các cuộc gọi đến dịch vụ web của bên thứ ba.

Quá trình cũng có thể được thực hiện mà không cần gọi lại xác minh ủy quyền nếu nhà cung cấp cấp cao nhất cung cấp API để tạo và thu hồi các bí mật được ủy quyền mới. Facebook đang làm điều gì đó tương tự bằng cách cho phép các ứng dụng facebook cho phép người dùng tạo các ứng dụng phụ.

Có một số cuộc nói chuyện về vấn đề trực tuyến:

http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/de1071bf4b820c14#de1071bf4b20

Giải pháp của Twitter và Yammer là một giải pháp pin xác thực: https://dev.twitter.com/oauth/pin-basing https://www.yammer.com/api_oauth_security_addendum.html

Với OAUth 2.0, bạn có thể lưu trữ bí mật trên máy chủ. Sử dụng máy chủ để có được mã thông báo truy cập mà sau đó bạn chuyển sang ứng dụng và bạn có thể thực hiện cuộc gọi từ ứng dụng đến tài nguyên trực tiếp.

Với OAuth 1.0 (Twitter), cần có bí mật để thực hiện các cuộc gọi API. Các cuộc gọi ủy quyền qua máy chủ là cách duy nhất để đảm bảo bí mật không bị xâm phạm.

Cả hai đều yêu cầu một số cơ chế mà thành phần máy chủ của bạn biết đó là máy khách của bạn gọi nó. Điều này có xu hướng được thực hiện khi cài đặt và sử dụng một cơ chế cụ thể của nền tảng để có được một id ứng dụng nào đó trong cuộc gọi đến máy chủ của bạn.

(Tôi là biên tập viên của thông số OAuth 2.0)

Một giải pháp có thể là mã cứng bí mật OAuth vào mã, nhưng không phải là một chuỗi đơn giản. Làm xáo trộn nó theo một cách nào đó - chia nó thành các phân đoạn, dịch chuyển các ký tự bằng cách bù, xoay nó - thực hiện bất kỳ hoặc tất cả những điều này. Một cracker có thể phân tích mã byte của bạn và tìm các chuỗi, nhưng mã obfuscation có thể khó tìm ra.

Đó không phải là một giải pháp hoàn hảo, mà là một giải pháp rẻ tiền.

Tùy thuộc vào giá trị khai thác, một số cracker thiên tài có thể đi đến độ dài lớn hơn để tìm mã bí mật của bạn. Bạn cần cân nhắc các yếu tố - chi phí cho giải pháp phía máy chủ được đề cập trước đó, khuyến khích các cracker dành nhiều nỗ lực hơn trong việc tìm kiếm mã bí mật của bạn và mức độ phức tạp của obfuscation mà bạn có thể thực hiện.

Không lưu trữ bí mật bên trong ứng dụng.

Bạn cần phải có một máy chủ có thể được ứng dụng truy cập qua https (rõ ràng) và bạn lưu trữ bí mật trên đó.

Khi ai đó muốn đăng nhập thông qua ứng dụng di động / máy tính để bàn của bạn, ứng dụng của bạn sẽ chỉ cần chuyển tiếp yêu cầu đến máy chủ sau đó sẽ nối thêm bí mật và gửi cho nhà cung cấp dịch vụ. Máy chủ của bạn sau đó có thể cho ứng dụng của bạn biết nó đã thành công hay chưa.

Sau đó, nếu bạn cần nhận bất kỳ thông tin nhạy cảm nào từ dịch vụ (facebook, google, twitter, v.v.), ứng dụng sẽ yêu cầu máy chủ của bạn và máy chủ của bạn sẽ cung cấp cho ứng dụng chỉ khi nó được kết nối chính xác.

Thực sự không có bất kỳ tùy chọn nào ngoại trừ việc lưu trữ nó trên máy chủ. Không có gì ở phía khách hàng là an toàn.

Ghi chú

Điều đó nói rằng, điều này sẽ chỉ bảo vệ bạn chống lại khách hàng độc hại chứ không phải khách hàng chống lại bạn độc hại và không phải khách hàng chống lại các khách hàng độc hại khác (lừa đảo) ...

OAuth là một giao thức tốt hơn nhiều trong trình duyệt so với trên máy tính để bàn / thiết bị di động.

Có một phần mở rộng mới cho Loại Cấp phép Mã ủy quyền được gọi là Khóa chứng minh cho trao đổi mã (PKCE) . Với nó, bạn không cần một bí mật khách hàng.

PKCE (RFC 7636) là một kỹ thuật để bảo mật các máy khách công cộng không sử dụng bí mật của máy khách.

Nó chủ yếu được sử dụng bởi các ứng dụng gốc và di động, nhưng kỹ thuật này cũng có thể được áp dụng cho bất kỳ khách hàng nào. Nó yêu cầu hỗ trợ bổ sung bởi máy chủ ủy quyền, vì vậy nó chỉ được hỗ trợ trên một số nhà cung cấp nhất định.

từ https://oauth.net/2/pkce/

Để biết thêm thông tin, bạn có thể đọc RFC 7636 đầy đủ hoặc phần giới thiệu ngắn này .

Đây là một cái gì đó để suy nghĩ. Google cung cấp hai phương pháp OAuth ... cho các ứng dụng web, nơi bạn đăng ký tên miền và tạo một khóa duy nhất và cho các ứng dụng đã cài đặt nơi bạn sử dụng khóa "ẩn danh".

Có thể tôi đã xem qua một cái gì đó trong bài đọc, nhưng dường như việc chia sẻ khóa duy nhất của ứng dụng web của bạn với một ứng dụng đã cài đặt có thể an toàn hơn so với sử dụng "ẩn danh" trong phương thức ứng dụng được cài đặt chính thức.

Với OAuth 2.0, bạn chỉ cần sử dụng luồng phía máy khách để lấy mã thông báo truy cập và sử dụng mã thông báo truy cập này để xác thực tất cả các yêu cầu tiếp theo. Sau đó, bạn không cần một bí mật nào cả.

Một mô tả hay về cách thực hiện điều này có thể được tìm thấy ở đây: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

Tôi không có nhiều kinh nghiệm với OAuth - nhưng không phải mọi yêu cầu đều yêu cầu không chỉ mã thông báo truy cập của người dùng, mà còn cả khóa và bí mật của người tiêu dùng ứng dụng? Vì vậy, ngay cả khi ai đó đánh cắp thiết bị di động và cố gắng lấy dữ liệu ra khỏi thiết bị, họ sẽ cần một khóa ứng dụng và bí mật để có thể thực sự làm bất cứ điều gì.

Tôi luôn nghĩ rằng ý định đằng sau OAuth là để mọi Tom, Dick và Harry có bản mashup không phải lưu trữ thông tin đăng nhập Twitter của bạn một cách rõ ràng. Tôi nghĩ rằng nó giải quyết vấn đề đó khá tốt mặc dù có những hạn chế. Ngoài ra, nó không thực sự được thiết kế dành cho iPhone.

Tôi đồng ý với Felixyz. OAuth mặc dù tốt hơn Basic Auth, vẫn còn một chặng đường dài để trở thành một giải pháp tốt cho các ứng dụng di động. Tôi đã chơi với OAuth để xác thực ứng dụng điện thoại di động với ứng dụng Google App Engine. Việc bạn không thể quản lý bí mật người tiêu dùng trên thiết bị di động một cách đáng tin cậy có nghĩa là mặc định là sử dụng quyền truy cập 'ẩn danh'.

Bước ủy quyền trình duyệt OAuth của Google App Engine sẽ đưa bạn đến một trang có chứa văn bản như: "Trang web <some-site> đang yêu cầu quyền truy cập vào Tài khoản Google của bạn cho (các) sản phẩm được liệt kê bên dưới"

YourApp (yourapp.appspot.com) - không liên kết với Google

Vân vân

Nó lấy <some-site> từ tên miền / tên máy chủ được sử dụng trong url gọi lại mà bạn cung cấp có thể là bất cứ thứ gì trên Android nếu bạn sử dụng lược đồ tùy chỉnh để chặn cuộc gọi lại. Vì vậy, nếu bạn sử dụng quyền truy cập 'ẩn danh' hoặc bí mật người tiêu dùng của bạn bị xâm phạm, thì bất kỳ ai cũng có thể viết một người tiêu dùng đánh lừa người dùng để cấp quyền truy cập vào ứng dụng gae của bạn.

Trang ủy quyền OAuth của Google cũng chứa nhiều cảnh báo có 3 mức độ nghiêm trọng tùy thuộc vào việc bạn đang sử dụng 'ẩn danh', bí mật người tiêu dùng hay khóa công khai.

Những thứ khá đáng sợ cho người dùng trung bình không am hiểu về kỹ thuật. Tôi không hy vọng sẽ có tỷ lệ hoàn thành đăng ký cao với loại công cụ đó.

Bài đăng trên blog này làm rõ cách thức bí mật của người tiêu dùng không thực sự hoạt động với các ứng dụng đã cài đặt. http://hueniverse.com/2009/02/should-twitter-discContue-their-basic-auth-api/

Tôi cũng đang cố gắng đưa ra giải pháp xác thực OAuth trên thiết bị di động và lưu trữ bí mật trong gói ứng dụng nói chung.

Và một ý tưởng điên rồ đã đánh vào tôi: Ý tưởng đơn giản nhất là lưu trữ bí mật bên trong nhị phân, nhưng bị che khuất bằng cách nào đó, hay nói cách khác, bạn lưu trữ một bí mật được mã hóa. Vì vậy, điều đó có nghĩa là bạn phải lưu trữ một khóa để giải mã bí mật của mình, điều này dường như đã đưa chúng ta vào vòng tròn đầy đủ. Tuy nhiên, tại sao không chỉ sử dụng một khóa đã có trong HĐH, tức là nó được xác định bởi HĐH chứ không phải bởi ứng dụng của bạn.

Vì vậy, để làm rõ ý tưởng của tôi là bạn chọn một chuỗi được xác định bởi HĐH, nó không thành vấn đề. Sau đó, mã hóa bí mật của bạn bằng cách sử dụng chuỗi này làm khóa và lưu trữ trong ứng dụng của bạn. Sau đó, trong thời gian chạy, giải mã biến bằng khóa, đây chỉ là hằng số HĐH. Bất kỳ hacker nào nhìn trộm vào nhị phân của bạn sẽ thấy một chuỗi được mã hóa, nhưng không có khóa.

Công việc vừa ý?

Ở đây tôi đã trả lời cách an toàn để lưu trữ thông tin oAuth của bạn trong ứng dụng di động

https://stackoverflow.com/a/17359809/998483

https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication

Facebook không thực hiện OAuth một cách nghiêm túc (nhưng), nhưng họ đã thực hiện một cách để bạn không nhúng bí mật của mình vào ứng dụng iPhone của mình: https://web.archive.org/web/20091223092924/http://wiki. developers.facebook.com/index.php/Session_Proxy

Đối với OAuth, yeah, tôi càng nghĩ về nó, chúng tôi có một chút nhồi nhét. Có lẽ điều này sẽ khắc phục nó.

Không có giải pháp nào trong số này ngăn chặn tin tặc xác định đánh hơi các gói được gửi từ thiết bị di động (hoặc trình giả lập) của chúng để xem bí mật của máy khách trong các tiêu đề http.

Một giải pháp có thể là có một bí mật động được tạo thành từ dấu thời gian được mã hóa bằng khóa & thuật toán mã hóa 2 chiều riêng tư. Sau đó, dịch vụ sẽ giải mã bí mật và xác định xem dấu thời gian là +/- 5 phút.

Bằng cách này, ngay cả khi bí mật bị xâm phạm, tin tặc sẽ chỉ có thể sử dụng nó trong tối đa 5 phút.

Như những người khác đã đề cập, sẽ không có vấn đề thực sự với việc lưu trữ bí mật cục bộ trên thiết bị.

Trên hết, bạn luôn có thể dựa vào mô hình bảo mật dựa trên UNIX của Android: chỉ ứng dụng của bạn mới có thể truy cập vào những gì bạn ghi vào hệ thống tệp. Chỉ cần viết thông tin vào đối tượng SharedPreferences mặc định của ứng dụng của bạn.

Để có được bí mật, người ta sẽ phải có quyền truy cập root vào điện thoại Android.