OAuth 소비자 비밀을 안전하게 유지하는 방법과 손상되었을 때 대응하는 방법은 무엇입니까?

OAuth 소비자 비밀을 안전하게 유지하는 방법과 손상되었을 때 대응하는 방법은 무엇입니까?

---

이 질문은 Android와 같은 모바일 플랫폼에서 oauth를 구현하는 데 관련된 보안 위험을 이해하려는 것입니다. 여기에서는 코드에 소비자 키 / 비밀이 포함 된 Android 애플리케이션이 있다고 가정합니다.

소비자의 비밀이 손상되었고 해커가이를 확보했다고 가정하면 그 결과는 무엇입니까?

침해 된 소비자 비밀 가정 침해 된 소비자 비밀은 사용자의 보안이나 사용자가 상호 작용하고 있던 OAuth 사용 제공 업체에 저장된 데이터에 영향을 미치지 않는다는 말이 맞습니까? 데이터 자체는 손상되지 않으며 해커가 검색 할 수 없습니다.

해커는 유효한 사용자 액세스 토큰을 가져와야하는데이 토큰을 얻기가 훨씬 더 어렵습니다.

해커는 손상된 소비자 비밀로 무엇을 할 수 있습니까?
나는 또한 다음을 언급하는 것이 맞습니까?

• 해커는 내 앱을 모방하는 애플리케이션을 설정 / 게시 할 수 있습니다.
• 해커는 해커 OAuth 댄스 (손상된 소비자 키 / 비밀 사용)를 통해 액세스 토큰을 검색하여 OAuth 흐름을 거치는 사용자를 끌어들일 수 있습니다.
• 사용자는 인증 프로세스 중에 익숙한 이름 (소비자 키)을 보게되므로 자신이 내 앱을 다루고 있다고 생각할 수 있습니다.
• 소비자가 해커를 통해 요청을 발행하면 해커는 쉽게 액세스 토큰을 가로 챌 수 있으며 이제 소비자 암호와 결합하여 내 리소스에 대한 액세스 권한을 얻기 위해 나를 대신하여 요청에 서명 할 수 있습니다.

최종 사용자에 미치는 영향
가정한다는 점에서

• 해커가 내 소비자 암호를 사용하여 애플리케이션 / 사이트를 설정했습니다.
• 내 사용자 중 한 명이 속아서 해당 애플리케이션 / 사이트에 대한 액세스 권한을 부여했습니다.

다음이 발생할 수 있습니다.

• 최종 사용자는 수상한 일이 벌어지고 있음을인지하고 서비스 제공 업체 (예 : Google)에게 악성 앱에 대해 알릴 수 있습니다.
• 그러면 서비스 공급자는 소비자 키 / 비밀을 취소 할 수 있습니다.

OAuth 소비자 (내 애플리케이션) 영향 :
내 앱 (소비자 비밀 포함)을 업데이트해야합니다. 그렇지 않으면 내 모든 클라이언트가 더 이상 내 애플리케이션을 대신하여 요청을 승인 할 수 없습니다 (내 소비자 비밀이 더 이상 유효).

모든 OAuth 트래픽
위임 중간 웹 서버를 통해 많은 OAuth 상호 작용을 위임 할 수 있지만 (OAuth 댄스를 수행하고 사용자에게 액세스 토큰을 전송) 소비자 키로 모든 서비스 상호 작용을 프록시해야합니다. / secret은 각 요청에 서명하는 데 필요합니다. 이것이 소비자 키 / 비밀을 모바일 앱 외부에 보관하고 중간 웹 서버의 더 안전한 장소에 저장하는 유일한 방법입니까?

대안
이 프록시에 대한 대안이 있습니까? 소비자 비밀을 중간 웹 서버에 저장할 수 있고 Android 애플리케이션 (시장에 게시되고 올바르게 서명 됨)이 중간 웹 서버에 보안 요청을 수행하여 소비자 비밀을 가져와 저장할 수있는 일종의 메커니즘을 가질 수 있습니까? 앱 내부에서? 중간 웹 서버가 이것이 소비자 비밀을 가져 오도록 요청하는 공식 안드로이드 앱이고 중간 웹 서버가 그 특정 안드로이드 앱에 소비자 비밀 만 나눠 줄 것이라는 것을 "인식"하는 메커니즘을 구현할 수 있습니까?

---

요약 : 나는 위험을 감수하고 클라이언트 앱에 비밀을 유지합니다.

프록시 서버 대안 :

아래에 나열한 문제를 합리적으로 완화하고 프록시 작업을 수행 할 수있는 유일한 방법은 9 야드 전체를 이동하는 것입니다. 타사 웹 서비스의 리소스를 처리하기위한 모든 비즈니스 논리를 프록시 서버로 이동하고 풍부한 UI로 클라이언트 앱을 바보 터미널로 만듭니다. 이렇게하면 악성 앱이 프록시를 대신하여 수행 할 수있는 유일한 작업은 비즈니스 논리에 합법적으로 필요한 것뿐입니다.

그러나 이제는 안정성과 확장 성을 처리해야하는 다른 수많은 문제의 영역에 들어갑니다.

간단한 프록시가 작동하지 않는 이유에 대한 긴 숙고 :

어떤 사람들은 문제에 직면했을 때“알아요, 내 프록시 서버를 추가하겠습니다”라고 생각합니다. 이제 두 가지 문제가 있습니다. (Jamie Zawinski에게 사과)

귀하의 가정은 대체로 옳습니다. 서버가 비밀을 유지하고 클라이언트 앱에 대한 호출을 프록시하는지 또는 앱이 합법적인지 확인하고 비밀을 제공하는지 여부에 관계없이 자신의 서버에 대해 생각하기 시작하는 지점까지 바로 내려갑니다. 두 가지 방법 모두 "이 요청이 내가 작성한 코드에서 오는 것"이라는 문제를 해결해야합니까?

반복하겠습니다. 특정 소프트웨어가 실행되고 있음을 유선상에서 구별 할 방법이 없습니다. 메시지의 데이터가 올바르게 보인다면 해당 메시지를 보내는 다른 앱임을 증명할 수있는 것은 없습니다 .

하루가 끝날 때 내가 악성 앱을 작성하는 경우 내가 아는 사람이 나를 대신해 작업을 수행하도록 할 수 있다면 내가 진짜 비밀을 알고 있든 상관하지 않습니다. 따라서 악성 앱이 앱을 타사 OAuth 서버로 가장 할 수 있다고 생각한다면 앱을 프록시로 가장 할 수없는 이유는 무엇입니까?

그러나 잠깐, 더 있습니다. 프록시 서비스가있는 도메인은 클라이언트와 OAuth 공급자 모두에 대한 ID입니다 (OAuth 공급자가 최종 사용자에게 표시 함). 악의적 인 앱으로 인해 서버가 나쁜 일을 할 수있는 경우 키가 취소 될뿐만 아니라 공용 웹 ID도 더 이상 신뢰할 수 없습니다.

---

나는 명백한 것부터 시작할 것이다. 특정 소프트웨어가 실행되고 있다는 것을 유선상에서 구별 할 방법이 없다. 메시지의 데이터가 올바르게 보인다면 해당 메시지를 보내는 다른 앱임을 증명할 수있는 것은 없습니다.

따라서 앱 측 저장된 비밀에 의존하는 모든 알고리즘이 스푸핑 될 수 있습니다. OAuth의 강점은 앱에 사용자의 자격 증명을 제공하지 않고 대신 사용자가 필요한 경우 취소 할 수있는 자체 임시 자격 증명을 제공한다는 것입니다.

물론 여기서 약점은 충분히 좋은 앱이 악의적 인 행위를 끝내기 전에 사용자가 자격 증명을 취소하지 않고 신뢰하게 할 수 있다는 것입니다.

그러나이를 완화하는 한 가지 방법은 표준 2-legged 대신 3-legged OAuth를 사용하는 Google의 접근 방식입니다. 3-legged OAuth에는 사전 할당 된 비밀이 없지만 모든 인증에서 각 액세스 토큰과 함께 새로운 액세스 토큰 비밀이 발급됩니다. 궁극적으로 이것은 동일한 단점을 가지고 있지만 나쁜 앱은 프로세스에서 좋은 앱의 토큰 비밀을 읽을 수 있기 때문에 사용자는 새로운 액세스 토큰이 필요할 때마다 앱 액세스를 승인해야합니다.

물론 이것은 사용자에게 조금 더 불편하고 성가시다는 것을 의미하기도합니다.

참고 URL : https://stackoverflow.com/questions/4419915/how-to-keep-the-oauth-consumer-secret-safe-and-how-to-react-when-its-compromis