모바일 앱의 OAuth 비밀
OAuth 프로토콜을 사용하려면 위임하려는 서비스에서 얻은 비밀 문자열이 필요합니다. 웹 응용 프로그램 에서이 작업을 수행하는 경우 단순히 데이터베이스 또는 파일 시스템에 비밀을 저장할 수 있지만 모바일 응용 프로그램 (또는 그 문제에 대한 데스크톱 응용 프로그램)에서 비밀을 처리하는 가장 좋은 방법은 무엇입니까?
누군가가 쉽게 그것을 찾아 남용 할 수 있기 때문에 앱에 문자열을 저장하는 것은 분명히 좋지 않습니다.
또 다른 방법은 서버에 서버를 저장하고 모든 실행에서 앱을 가져와 휴대 전화에 저장하지 않는 것입니다. 앱에 URL을 포함시켜야하기 때문에 이것은 거의 나쁘다.
내가 취할 수있는 유일한 해결책은 먼저 액세스 토큰을 정상적으로 (권장 앱 내에서 웹보기를 사용하여) 얻은 다음 서버를 통해 모든 추가 통신을 라우팅하여 요청 데이터에 비밀을 추가하고 통신하는 것입니다. 공급자와. 다시 한 번 저는 보안 멍청한 사람이므로 이에 대한 지식이 풍부한 사람들의 의견을 듣고 싶습니다. 보안을 보장하기 위해 대부분의 앱이 이러한 길이로 가고있는 것처럼 보이지 않습니다 (예 : Facebook Connect는 비밀을 앱의 문자열에 넣는 것으로 가정합니다).
또 다른 점은 비밀이 처음에 액세스 토큰을 요청하는 것과 관련이 있다고 생각하지 않으므로 자체 서버와 관련없이 수행 할 수 있습니다. 나 맞아?
예, 이것은 우리가 직면하고있는 OAuth 디자인의 문제입니다. 우리는 자체 서버를 통해 모든 통화를 프록시하기로 결정했습니다. OAuth는 데스크톱 앱과 관련하여 완전히 플러시되지 않았습니다. OAuth를 변경하지 않고 찾은 문제에 대한 완벽한 해결책은 없습니다.
당신이 그것에 대해 생각하고 왜 우리에게 비밀이 있는지에 대한 질문을한다면, 대부분 앱을 프로비저닝하고 비활성화하는 것입니다. 우리의 비밀이 손상되면 공급자는 실제로 전체 앱만 취소 할 수 있습니다. 우리는 비밀을 데스크톱 앱에 포함시켜야하기 때문에 다소 혼란에 빠집니다.
해결책은 각 데스크톱 앱마다 다른 비밀을 유지하는 것입니다. OAuth는이 개념을 쉽게 만들지 않습니다. 한 가지 방법은 사용자가 직접 비밀을 만들고 데스크탑 앱에 키를 직접 입력하도록하는 것입니다 (일부 페이스 북 앱은 오랫동안 비슷한 작업을 수행하여 사용자가 페이스 북을 만들어 사용자 지정 Quiise를 설정하고 쓰레기). 사용자에게는 좋은 경험이 아닙니다.
OAuth 위임 시스템 제안을 준비 중입니다. 개념은 공급자로부터 얻은 자체 비밀 키를 사용하여 자체 데스크톱 클라이언트 (기본적으로 각 데스크톱 앱마다 하나씩)에 자체 위임 된 비밀을 발급 한 다음 인증 프로세스 중에 해당 키를 최상위 수준으로 보냅니다. 우리에게 전화를 걸어 우리와 다시 확인하는 공급자. 그렇게하면 각 데스크톱 클라이언트에 발급 한 비밀을 취소 할 수 있습니다. (SSL에서 작동하는 방식을 많이 모색). 이 전체 시스템은 타사 웹 서비스에 대한 호출을 전달하는 부가 가치 웹 서비스에 적합합니다.
최상위 공급자가 새로운 위임 된 비밀을 생성 및 취소하는 API를 제공하는 경우 위임 확인 콜백없이 프로세스를 수행 할 수도 있습니다. Facebook은 페이스 북 앱이 사용자가 하위 앱을 만들 수 있도록 허용함으로써 비슷한 일을하고 있습니다.
온라인으로이 문제에 대한 대화가 있습니다.
http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/de1071bf4b820c14#de1071bf4b820c14
트위터와 Yammer의 솔루션은 인증 핀 솔루션입니다 : https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html
OAUth 2.0을 사용하면 서버에 비밀을 저장할 수 있습니다. 서버를 사용하여 액세스 토큰을 얻은 다음 앱으로 이동하면 앱에서 리소스로 직접 전화를 걸 수 있습니다.
OAuth 1.0 (Twitter)에서는 API 호출을하기위한 비밀이 필요합니다. 서버를 통한 호출 프록시는 비밀이 손상되지 않도록하는 유일한 방법입니다.
둘 다 서버 구성 요소가 클라이언트를 호출한다는 것을 알고있는 일부 메커니즘이 필요합니다. 이것은 설치 및 플랫폼 특정 메커니즘을 사용하여 서버 호출에서 일종의 앱 ID를 얻는 경향이 있습니다.
(저는 OAuth 2.0 사양의 편집자입니다)
한 가지 해결책은 OAuth 비밀을 코드에 하드 코딩하는 것이지만 일반 문자열은 아닙니다 . 어떤 식 으로든 그것을 난독 처리하십시오-세그먼트로 나누고, 오프셋으로 문자를 이동하고, 회전 시키십시오-이러한 것들 중 일부 또는 전부를하십시오. 크래커는 바이트 코드를 분석하고 문자열을 찾을 수 있지만 난독 화 코드를 이해하기 어려울 수 있습니다.
완벽한 솔루션은 아니지만 저렴한 솔루션입니다.
익스플로잇의 가치에 따라 일부 천재 크래커는 더 긴 길이로 비밀 코드를 찾을 수 있습니다. 이전에 언급 한 서버 측 솔루션의 비용, 크래커가 비밀 코드를 찾는 데 더 많은 노력을 기울일 수있는 인센티브 및 구현할 수있는 난독 화의 복잡성을 고려해야합니다.
응용 프로그램 내부에 비밀을 저장하지 마십시오.
https를 통해 응용 프로그램에서 액세스 할 수있는 서버가 있어야하며 분명히 암호를 저장해야합니다.
누군가가 모바일 / 데스크톱 응용 프로그램을 통해 로그인하려는 경우 응용 프로그램은 요청을 서버로 전달한 다음 비밀을 추가하여 서비스 공급자에게 보냅니다. 그러면 서버는 응용 프로그램이 성공했는지 여부를 알려줄 수 있습니다.
그런 다음 서비스 (페이스 북, 구글, 트위터 등)에서 민감한 정보를 얻으려면 응용 프로그램이 서버에 요청하면 서버가 응용 프로그램에 올바르게 연결되어있는 경우에만 정보를 제공합니다.
실제로 서버에 저장하는 것 외에는 어떤 옵션도 없습니다. 클라이언트 측의 보안은 없습니다.
노트
즉, 이것은 악의적 인 클라이언트로부터 만 보호하지만 악의적 인 사용자로부터의 클라이언트는 아닌 다른 악의적 인 클라이언트 (파이 싱)의 클라이언트는 아닙니다 ...
OAuth는 데스크톱 / 모바일보다 브라우저에서 훨씬 더 나은 프로토콜입니다.
생각해 볼 점이 있습니다. Google은 도메인을 등록하고 고유 키를 생성하는 웹 앱과 "익명"키를 사용하는 설치된 앱에 대해 두 가지 OAuth 방법을 제공합니다.
어쩌면 나는 독서에서 무언가를 좋아했지만 웹 응용 프로그램의 고유 키를 설치된 앱과 공유하는 것이 공식 설치된 앱 방법에서 "익명"을 사용하는 것보다 더 안전한 것 같습니다.
OAuth 2.0에서는 단순히 클라이언트 측 흐름을 사용하여 액세스 토큰을 얻은 다음이 액세스 토큰을 사용하여 모든 추가 요청을 인증 할 수 있습니다. 그럼 당신은 전혀 비밀이 필요하지 않습니다.
이것을 구현하는 방법에 대한 좋은 설명은 여기에서 찾을 수 있습니다 : https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps
PKCE (Proof Key for Code Exchange) 라는 인증 코드 부여 유형에 새로운 확장이 있습니다 . 그것으로, 당신은 클라이언트 비밀이 필요하지 않습니다.
PKCE (RFC 7636)는 클라이언트 암호를 사용하지 않는 공용 클라이언트를 보호하는 기술입니다.
It is primarily used by native and mobile apps, but the technique can be applied to any public client as well. It requires additional support by the authorization server, so it is only supported on certain providers.
from https://oauth.net/2/pkce/
For more information, you can read the full RFC 7636 or this short introduction.
I don't have a ton of experience with OAuth - but doesn't every request require not only the user's access token, but an application consumer key and secret as well? So, even if somebody steals a mobile device and tries to pull data off of it, they would need an application key and secret as well to be able to actually do anything.
I always thought the intention behind OAuth was so that every Tom, Dick, and Harry that had a mashup didn't have to store your Twitter credentials in the clear. I think it solves that problem pretty well despite it's limitations. Also, it wasn't really designed with the iPhone in mind.
I agree with Felixyz. OAuth whilst better than Basic Auth, still has a long way to go to be a good solution for mobile apps. I've been playing with using OAuth to authenticate a mobile phone app to a Google App Engine app. The fact that you can't reliably manage the consumer secret on the mobile device means that the default is to use the 'anonymous' access.
The Google App Engine OAuth implementation's browser authorization step takes you to a page where it contains text like: "The site <some-site> is requesting access to your Google Account for the product(s) listed below"
YourApp(yourapp.appspot.com) - not affiliated with Google
etc
It takes <some-site> from the domain/host name used in the callback url that you supply which can be anything on the Android if you use a custom scheme to intercept the callback. So if you use 'anonymous' access or your consumer secret is compromised, then anyone could write a consumer that fools the user into giving access to your gae app.
The Google OAuth authorization page also does contain lots of warnings which have 3 levels of severity depending on whether you're using 'anonymous', consumer secret, or public keys.
Pretty scary stuff for the average user who isn't technically savvy. I don't expect to have a high signup completion percentage with that kind of stuff in the way.
This blog post clarifies how consumer secret's don't really work with installed apps. http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/
I'm also trying to come up with a solution for mobile OAuth authentication, and storing secrets within the application bundle in general.
And a crazy idea just hit me: The simplest idea is to store the secret inside the binary, but obfuscated somehow, or, in other words, you store an encrypted secret. So, that means you've got to store a key to decrypt your secret, which seems to have taken us full circle. However, why not just use a key which is already in the OS, i.e. it's defined by the OS not by your application.
So, to clarify my idea is that you pick a string defined by the OS, it doesn't matter which one. Then encrypt your secret using this string as the key, and store that in your app. Then during runtime, decrypt the variable using the key, which is just an OS constant. Any hacker peeking into your binary will see an encrypted string, but no key.
Will that work?
Here I have answer the secure way to storing your oAuth information in mobile application
https://stackoverflow.com/a/17359809/998483
Facebook doesn't implement OAuth strictly speaking (yet), but they have implemented a way for you not to embed your secret in your iPhone app: https://web.archive.org/web/20091223092924/http://wiki.developers.facebook.com/index.php/Session_Proxy
As for OAuth, yeah, the more I think about it, we are a bit stuffed. Maybe this will fix it.
None of these solutions prevent a determined hacker from sniffing packets sent from their mobile device (or emulator) to view the client secret in the http headers.
One solution could be to have a dynamic secret which is made up of a timestamp encrypted with a private 2-way encryption key & algorithm. The service then decrypts the secret and determines if the time stamp is +/- 5 minutes.
In this way, even if the secret is compromised, the hacker will only be able to use it for a maximum of 5 minutes.
As others have mentioned, there should be no real issue with storing the secret locally on the device.
On top of that, you can always rely on the UNIX-based security model of Android: only your application can access what you write to the file system. Just write the info to your app's default SharedPreferences object.
In order to obtain the secret, one would have to obtain root access to the Android phone.
참고URL : https://stackoverflow.com/questions/1934187/oauth-secrets-in-mobile-apps
'IT' 카테고리의 다른 글
| Xcode에서 더 이상 사용되지 않는 경고 억제 (0) | 2020.07.03 |
|---|---|
| 저장소를 Github의 폴더로 정렬 할 수 있습니까? (0) | 2020.07.03 |
| .Net 4.5의 비동기 HttpClient가 집중로드 애플리케이션에 적합하지 않습니까? (0) | 2020.07.03 |
| PHP의 죽음의 하얀 화면 (0) | 2020.07.02 |
| Python-고유 한 사전 목록 (0) | 2020.07.02 |