모바일 앱의 OAuth 비밀

모바일 앱의 OAuth 비밀

OAuth 프로토콜을 사용할 때 위임할 서비스에서 가져온 비밀 문자열이 필요합니다.웹 앱에서 이 작업을 수행하는 경우 데이터베이스나 파일 시스템에 암호를 저장하기만 하면 되지만 모바일 앱(또는 데스크톱 앱)에서 암호를 처리하는 가장 좋은 방법은 무엇입니까?

누군가가 쉽게 찾아서 악용할 수 있기 때문에 앱에 문자열을 저장하는 것은 분명히 좋지 않습니다.

또 다른 접근 방식은 서버에 저장하고 실행할 때마다 앱이 전화기에 저장하지 않고 가져올 수 있도록 하는 것입니다.이는 앱에 URL을 포함해야 하기 때문에 거의 마찬가지입니다.

제가 생각해 낼 수 있는 유일한 해결책은 먼저 정상적으로 액세스 토큰을 얻은 다음(앱 내부의 웹 뷰를 사용하는 것이 좋습니다), 모든 추가 통신을 서버를 통해 라우팅하는 것입니다. 그러면 요청 데이터에 암호를 추가하고 공급자와 통신할 수 있습니다.한편, 저는 보안 전문가입니다. 그래서 저는 이것에 대한 지식 있는 사람들의 의견을 듣고 싶습니다.대부분의 앱들이 보안을 보장하기 위해 이 정도까지 가는 것 같지는 않습니다(예를 들어, Facebook Connect는 앱에서 바로 비밀을 문자열에 입력했다고 가정하는 것 같습니다).

또 다른 것:처음에 액세스 토큰을 요청하는 데는 비밀이 관련되어 있지 않으므로, 자체 서버를 사용하지 않고도 가능합니다.내가 맞나요?

네, 이것은 우리가 직면한 OAuth 디자인의 문제입니다.모든 통화를 자체 서버를 통해 프록시하기로 했습니다.OAuth는 데스크톱 앱과 관련하여 완전히 배제되지 않았습니다.OAuth를 변경하지 않고 제가 찾은 문제에 대한 현 단계의 해결책은 없습니다.

생각해보면 왜 우리에게 비밀이 있는지에 대한 질문은 대부분 앱을 프로비저닝하고 비활성화하기 위한 것입니다.만약 우리의 비밀이 침해된다면, 공급자는 단지 전체 앱을 취소할 수 있습니다.우리는 데스크톱 앱에 우리의 비밀을 포함시켜야 하기 때문에, 우리는 약간 망했습니다.

해결책은 데스크톱 앱마다 다른 비밀을 갖는 것입니다.OAuth는 이 개념을 쉽게 만들지 않습니다.한 가지 방법은 사용자가 직접 가서 비밀을 만들고 데스크톱 앱에 키를 입력하도록 하는 것입니다(일부 페이스북 앱은 사용자가 가서 사용자 지정 퀴즈 및 쓰레기를 설정하도록 하는 등 오랫동안 유사한 작업을 수행했습니다).그것은 사용자에게 좋은 경험이 아닙니다.

저는 OAuth를 위한 위임 시스템에 대한 제안서를 작성하고 있습니다.이 개념은 공급자로부터 받은 자체 암호 키를 사용하여 자체 데스크톱 클라이언트(기본적으로 각 데스크톱 애플리케이션에 대해 하나씩)에 위임된 암호를 발급한 다음 인증 프로세스 중에 해당 키를 최상위 수준의 공급자에게 전송하여 다시 전화를 걸어 확인할 수 있다는 것입니다.이렇게 하면 각 데스크톱 클라이언트에 발급한 자체 암호를 해지할 수 있습니다. (SSL에서 이 암호가 작동하는 방식의 많은 부분을 빌립니다.)이 전체 시스템은 부가가치 웹 서비스를 위한 것일 뿐만 아니라 제3자 웹 서비스로 통화를 전달하는 것입니다.

최상위 공급자가 새로운 위임 암호를 생성하고 취소하는 API를 제공하는 경우 위임 확인 콜백 없이 프로세스를 수행할 수도 있습니다.페이스북은 사용자가 하위 앱을 만들 수 있도록 페이스북 앱을 허용함으로써 비슷한 일을 하고 있습니다.

온라인에서는 이 문제에 대해 몇 가지 이야기를 나누고 있습니다.

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

Twitter and 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 호출을 하려면 비밀이 필요합니다.서버를 통해 통화를 프록시하는 것이 암호가 손상되지 않도록 하는 유일한 방법입니다.

둘 다 서버 구성요소가 클라이언트가 호출한 것으로 알고 있는 메커니즘이 필요합니다.이 작업은 설치 시 수행되고 플랫폼별 메커니즘을 사용하여 서버에 대한 호출에서 특정 종류의 알림을 받는 경우가 있습니다.

(저는 OAuth 2.0 사양의 편집자입니다.)

한 가지 해결책은 OAuth 암호를 코드로 하드 코딩하는 것일 수 있지만 일반 문자열로는 할 수 없습니다.세그먼트로 분할, 문자 간격띄우기, 회전 등의 방법으로 난독화합니다.크래커는 바이트 코드를 분석하고 문자열을 찾을 수 있지만 난독화 코드는 파악하기 어려울 수 있습니다.

그것은 완벽한 해결책이 아니라 저렴한 해결책입니다.

공격의 가치에 따라 일부 천재 크래커는 당신의 비밀 코드를 찾기 위해 더 많은 노력을 할 수 있습니다.이전에 언급한 서버 측 솔루션의 비용, 크래커가 비밀 코드를 찾기 위해 더 많은 노력을 기울이는 동기, 구현할 수 있는 난독화의 복잡성 등의 요인을 고려해야 합니다.

응용프로그램 내부에 암호를 저장하지 마십시오.

https를 통해 응용 프로그램에서 액세스할 수 있는 서버가 있어야 하며 암호를 저장해야 합니다.

다른 사용자가 모바일/데스크톱 응용프로그램을 통해 로그인하려고 하면 응용프로그램이 요청을 서버로 전달하고 서버가 암호를 추가하여 서비스 공급자에게 보냅니다.그런 다음 서버는 응용프로그램의 성공 여부를 알려줄 수 있습니다.

그런 다음 서비스(Facebook, Google, Twitter 등)에서 중요한 정보를 얻어야 하는 경우, 응용 프로그램은 서버에 요청하고 서버는 올바르게 연결된 경우에만 해당 정보를 응용 프로그램에 제공합니다.

서버에 저장하는 것 외에는 다른 옵션이 없습니다.클라이언트 측의 보안 기능은 없습니다.

메모

즉, 이것은 악성 클라이언트로부터만 보호할 뿐 악성 사용자로부터는 클라이언트를 보호할 수 없으며 다른 악성 클라이언트(피싱)로부터는 클라이언트를 보호할 수 없습니다.

OAuth는 브라우저에서 데스크톱/모바일보다 훨씬 더 나은 프로토콜입니다.

인증 코드 부여 유형에 PKCE(Proof Key for Code Exchange)라는 새 확장이 있습니다.이것만 있으면 고객 비밀이 필요 없습니다.

PKCE(RFC 7636)는 클라이언트 암호를 사용하지 않는 공용 클라이언트를 보호하는 기술입니다.

기본적으로 네이티브 및 모바일 앱에서 사용되지만, 이 기술은 모든 공용 클라이언트에도 적용될 수 있습니다.인증 서버의 추가 지원이 필요하므로 특정 공급자에서만 지원됩니다.

https://oauth.net/2/pkce/ 에서

자세한 내용은 RFC 7636 전체 또는 이 간단한 소개를 참조하십시오.

여기 생각해 볼 것이 있습니다.Google은 OAuth의 두 가지 방법을 제공합니다.도메인을 등록하고 고유한 키를 생성하는 웹 앱과 "키"를 사용하는 설치된 앱의 경우.

아마도 제가 읽을 때 뭔가를 얼버무렸을 수도 있지만, 공식적으로 설치된 앱에서 "익명"을 사용하는 것보다 웹 앱의 고유 키를 설치된 앱과 공유하는 것이 아마도 더 안전한 것 같습니다.

OAuth 2.0을 사용하면 클라이언트 측 흐름을 사용하여 액세스 토큰을 얻은 다음 이 액세스 토큰을 사용하여 모든 추가 요청을 인증할 수 있습니다.그럼 비밀은 전혀 필요 없겠네요.

이 기능을 구현하는 방법에 대한 자세한 설명은 https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps 에서 확인할 수 있습니다.

저는 OAuth에 대한 경험이 많지 않습니다. 하지만 모든 요청에는 사용자의 액세스 토큰뿐만 아니라 애플리케이션 소비자 키와 비밀도 필요하지 않습니까?따라서 누군가가 모바일 장치를 훔쳐서 데이터를 빼내려고 해도 실제로 무엇이든 할 수 있는 애플리케이션 키와 비밀이 필요합니다.

저는 항상 OAuth 뒤에 있는 의도는 매쉬업을 하는 모든 Tom, Dick, Harry가 당신의 트위터 자격증을 비밀에 저장하지 않아도 되는 것이라고 생각했습니다.저는 그것이 한계가 있음에도 불구하고 그 문제를 꽤 잘 해결한다고 생각합니다.또한, 그것은 실제로 아이폰을 염두에 두고 설계되지 않았습니다.

펠릭스의 말에 동의합니다.OAuth는 Basic Auth보다 낫지만 모바일 앱을 위한 좋은 솔루션이 되려면 아직도 갈 길이 멉니다.저는 OAuth를 사용하여 Google App Engine 앱에 휴대폰 앱을 인증하는 놀이를 해왔습니다.모바일 기기에서 소비자 비밀을 안정적으로 관리할 수 없다는 것은 기본적으로 '익명' 액세스를 사용한다는 것을 의미합니다.

Google App Engine OAuth 구현의 브라우저 권한 부여 단계는 다음과 같은 텍스트가 포함된 페이지로 이동합니다. "<some-site> 사이트가 아래 나열된 제품에 대한 Google 계정에 대한 액세스를 요청합니다."

귀하의 앱(yourapp.appspot.com ) - Google과 제휴하지 않음

기타

사용자 지정 스킴을 사용하여 콜백을 가로채는 경우 제공하는 콜백 URL에 사용되는 도메인/호스트 이름에서 <some-site>를 가져옵니다.따라서 '익명' 액세스를 사용하거나 소비자 비밀이 손상되면 누구나 사용자를 속여 gae 앱에 액세스할 수 있도록 하는 소비자를 작성할 수 있습니다.

Google OAuth 권한 부여 페이지에는 사용자가 '익명', 소비자 암호 또는 공개 키를 사용하는지 여부에 따라 세 가지 수준의 심각도를 갖는 많은 경고가 포함되어 있습니다.

기술적인 지식이 없는 일반 사용자에게는 꽤 무서운 것입니다.저는 그런 종류의 것들로 높은 가입 완료율을 기대하지 않습니다.

이 블로그 게시물은 설치된 앱에서 소비자 암호가 실제로 작동하지 않는 방법을 설명합니다.http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

모바일 애플리케이션에 oAuth 정보를 안전하게 저장하는 방법에 대해 답변합니다.

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

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

페이스북은 엄밀히 말하면 OAuth를 구현하지 않지만(아직) 아이폰 앱에 비밀을 포함시키지 않는 방법을 구현했습니다. https://web.archive.org/web/20091223092924/http ://wiki.developers.facebook.com/index.php/Session_Proxy

OAuth에 대해서는, 네, 생각하면 할수록, 우리는 약간 꽉 찼습니다.아마 이것으로 해결할 수 있을 겁니다.

이러한 솔루션 중 어떤 것도 결정된 해커가 모바일 장치(또는 에뮬레이터)에서 전송된 패킷을 스니핑하여 http 헤더의 클라이언트 암호를 보는 것을 방지하지 않습니다.

한 가지 해결책은 개인 양방향 암호화 키 및 알고리즘으로 암호화된 타임스탬프로 구성된 동적 암호화를 갖는 것일 수 있습니다.그런 다음 서비스는 암호를 해독하고 타임스탬프가 +/- 5분인지 확인합니다.

이렇게 하면, 비밀이 손상되더라도 해커는 최대 5분 동안만 비밀을 사용할 수 있습니다.

저는 또한 모바일 OAuth 인증을 위한 해결책을 생각하고 있으며, 일반적으로 애플리케이션 번들 내에 비밀을 저장하고 있습니다.

그리고 말도 안되는 생각이 떠올랐습니다.가장 간단한 방법은 암호화된 암호를 바이너리 내부에 저장하는 것입니다. 하지만 어떻게든 난독화된 암호화된 암호화된 암호를 저장하는 것을 저장하는 것입니다.즉, 암호를 해독하려면 키를 저장해야 한다는 것입니다. 우리는 이 암호를 완전히 해독한 것 같습니다.하지만, 이미 OS에 있는 키를 사용하는 것은 어떨까요? 즉, 애플리케이션이 아닌 OS에 의해 정의됩니다.

그래서 제 생각을 명확히 하기 위해 OS에 의해 정의된 문자열을 선택하는 것입니다. 어떤 문자열을 선택하든 상관없습니다.그런 다음 이 문자열을 키로 사용하여 비밀을 암호화하고 앱에 저장합니다.그런 다음 런타임 중에 OS 상수인 키를 사용하여 변수를 해독합니다.이진 파일을 엿보는 해커는 암호화된 문자열을 볼 수 있지만 키는 볼 수 없습니다.

그것이 통할까요?

다른 사람들이 언급했듯이 장치에 로컬로 암호를 저장하는 데는 실제 문제가 없어야 합니다.

또한 항상 Android의 UNIX 기반 보안 모델을 사용할 수 있습니다. 파일 시스템에 기록한 내용에 액세스할 수 있는 것은 애플리케이션뿐입니다.앱의 기본 공유 기본 설정 개체에 정보를 기록하기만 하면 됩니다.

비밀을 얻기 위해서는 Android 전화기에 대한 루트 액세스 권한을 얻어야 합니다.

언급URL : https://stackoverflow.com/questions/1934187/oauth-secrets-in-mobile-apps