모바일 앱의 OAuth 비밀


137

OAuth 프로토콜을 사용하려면 위임하려는 서비스에서 얻은 비밀 문자열이 필요합니다. 웹 응용 프로그램 에서이 작업을 수행하는 경우 단순히 데이터베이스 또는 파일 시스템에 비밀을 저장할 수 있지만 모바일 응용 프로그램 (또는 그 문제에 대한 데스크톱 응용 프로그램)에서 비밀을 처리하는 가장 좋은 방법은 무엇입니까?

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

또 다른 방법은 서버에 서버를 저장하고 앱을 실행 시마다 가져와 휴대 전화에 저장하지 않는 것입니다. 앱에 URL을 포함시켜야하기 때문에 이것은 거의 나쁘다.

내가 취할 수있는 유일한 해결책은 먼저 액세스 토큰을 정상적으로 (권장 앱 내에서 웹보기를 사용하여) 얻은 다음 서버를 통해 모든 추가 통신을 라우팅하여 요청 데이터에 비밀을 추가하고 통신하는 것입니다 공급자와. 다시 한 번 저는 보안 멍청한 사람이므로 이에 대한 지식이 풍부한 사람들의 의견을 듣고 싶습니다. 보안을 보장하기 위해 대부분의 앱이 이러한 길이로 가고있는 것처럼 보이지 않습니다 (예 : Facebook Connect는 비밀을 앱의 문자열에 넣는 것으로 가정합니다).

또 다른 점은 비밀이 처음에 액세스 토큰을 요청하는 것과 관련이 있다고 생각하지 않으므로 자체 서버와 관련없이 수행 할 수 있습니다. 나 맞아?


분명하지 않으면 죄송하지만 응용 프로그램 데이터베이스에 코드를 저장하는 데 어떤 문제가 있습니까? 이러한 토큰은 사용자가 자신의 계정을 인증 한 후에 생성 및 저장되므로, 상기 사용자는 모바일 장치가 액세스 권한을 갖도록 액세스를 저장하기를 원한다고 가정하는 것이 안전해야합니다.
poke

사용자가 자신의 계정에 액세스 할 수 있도록 승인 한 후에도 (예 : Twitter에서) 액세스하려는 서비스에서 얻은 비밀을 사용해야합니다. 이 비밀은 인증 키 및 일부 다른 키와 함께 서버와의 모든 통신에 사용됩니다 . 그래서 그래, 당신은 액세스 키를 저장할 수 있지만, 함께 사용 될 수 있기 때문에 비밀은 저장하지 말아야 어떤 서비스를 남용하는 인증 키. 다시 한 번, 이것에 대해 더 많이 알고있는 사람들이 바로 기뻐할 것입니다.
Felixyz 2009

1
OAuth는 원래 사용자의 로그인 데이터를 보호하는 인증 방법을 제공합니다. 이를 가능하게하기 위해 고유 한 응용 프로그램의 키 조합 과 만 작동 하는 새로운 고유 한 로그인 조합이 생성됩니다 . 사용자의 로그인 데이터를 저장하는 것보다 큰 이점은 첫 번째 인증 후에 는 완전히 안전 하며 위반의 경우 사용자가 단순히 권한 부여의 액세스를 취소 할 수 있다는 것입니다. 물론 비밀을 저장하지 않으면 사용자가 다시 인증해야 할 때 의미가 없습니다 (그리고 응용 프로그램 액세스 권한을 부여 할 때 사용자가 원하는 것이 아닙니다).
poke

@poke 사용자가 공급자와 함께 앱을 승인 할 때 얻은 인증 키는 저장해야하지만, 앱을 출시하기 전에 공급자로부터받은 비밀 토큰은 데스크톱 또는 모바일 앱의 경우에는 제공하지 않아야합니다. 질문에 명시된 바와 같이 서버에 키를 분명히 저장할 수있는 웹 응용 프로그램).
Felixyz

4
데스크톱 응용 프로그램의 oAuth--에서 케이스에 대한 이해에 따라 매우 쉽게 냄새에 / 같은 도구를 사용하여 HTTP / HTTPS 트래픽 모니터링 ieinspector.com/httpanalyzer/index.html 따라서 토큰과 토큰 비밀을 모두 매우 찾을 수 있습니다 용이하게. 따라서 유일한 보호는 소비자의 비밀입니다. 이제 앱 내부의 비밀을 누군가가 찾을 수 있으면 다른 앱을 앱으로 가장하는 어린이 놀이가됩니다. 내가 틀렸다면 나를 바로 잡으십시오.
Varun

답변:


38

예, 이것은 우리가 직면하고있는 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가 데스크톱 / 모바일 앱에는 그다지 좋지 않다는 것을 확인했지만 매우 흥미 롭습니다. 물론 공격자는 먼저 비밀을 얻은 다음 누군가의 자격 증명을 스니핑해야하기 때문에 꽤 많은 결정이 필요합니다. 핀 솔루션은 데스크톱에는 적합하지만 모바일 imo에는 적합하지 않습니다.
Felixyz 2018

이 문제는 웹 서비스에 적용되지 않기 때문에 제안 된 체계가 어떻게 부가 가치 웹 서비스에 도움이됩니까? 또한 새 비밀을 생성하는 공급자와 어떻게 작동하는지 알지 못합니다. 새 비밀을 요청하려면 "마스터 비밀"이 필요하기 때문에 적어도 자신의 서버에 대한 호출이 하나 필요합니다. 주요 비밀). 그러나 그것은 물론 자신의 서버를 통해 모든 트래픽을 라우팅 하는 것보다 낫습니다 . 설명을 가장 환영합니다! 제안이 진행되는 동안 여기에서 업데이트하십시오!
Felixyz

5
궁금한 점은 : 프록시 서버를 호출하는 것이 합법적이라고 어떻게 판단합니까?
davidtbernal

1
notJim에 대한 응답 : 소비자의 비밀이 유출 될 수있게하는 주요 위험은 악성 (또는 어리석은) 응용 프로그램을 사용하여 개발할 수 있다는 것입니다. 평판을 손상시키고 API 남용 / 오용으로 인해 합법적 인 응용 프로그램을 종료 할 위험이 높아집니다. 사용자가 제어하는 ​​웹 애플리케이션을 통해 비밀이 필요한 모든 통화를 프록시 처리하면 소비하는 API가 종료하기로 결정하기 전에 악용 패턴을 감시하고 사용자 또는 액세스 토큰 레벨에 대한 액세스를 취소 할 수있는 위치로 돌아갑니다. 전체 서비스를 중단하십시오.
quasistoic

동의어에 동의합니다. oauth 호출을 처리하려면 SSL 지원 브라우저를 사용해야합니다. 이것은 향후 보안 업데이트를 쉽게 관리하는 것을 포함하여 몇 가지 이유에서 좋은 것이며, 실제 응용 프로그램의 어떤 것도 업데이트 할 필요가 없습니다. Zac은 트위터에서 PIN 솔루션을 제안한다고 지적했다.이 솔루션은 코드를 안전하게 얻을 수있는 응용 프로그램을 신뢰할 수 없기 때문에 실제로 생각했다. 웹 서버를 통해 요청을 프록시하기 위해 PIN 및 비밀과 함께 현대 암호화로 'Nonce'를 사용하는 것이 좋습니다.
Mark

18

OAUth 2.0을 사용하면 서버에 비밀을 저장할 수 있습니다. 서버를 사용하여 액세스 토큰을 얻은 다음 앱으로 이동하면 앱에서 리소스로 직접 전화를 걸 수 있습니다.

OAuth 1.0 (Twitter)에서는 API 호출을하기위한 비밀이 필요합니다. 서버를 통한 호출 프록시는 비밀이 손상되지 않도록하는 유일한 방법입니다.

둘 다 서버 구성 요소가 클라이언트를 호출한다는 것을 알고있는 일부 메커니즘이 필요합니다. 이것은 설치 및 플랫폼 특정 메커니즘을 사용하여 서버 호출에서 일종의 앱 ID를 얻는 경향이 있습니다.

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


2
"어떤 종류의 앱 ID를 얻는 플랫폼 별 메커니즘"에 대해 자세히 설명 할 수 있습니까? 서버 구성 요소는 어떻게 클라이언트의 신원을 확인합니까? 나는 이것이 클라이언트 프로비저닝으로 수행 될 수 있다고 생각합니다. 예를 들어 각 클라이언트에 새롭고 고유 한 SSL 인증서를 배포하십시오. 이게 네가 말하는거야? 이보다 더 복잡한 경우 좀 더 깊이있는 글을 참조 할 수 있습니까?
Cheeso

2
보안 담당자가 어떻게이 작업을 수행 할 수 있는지 이야기합니다. 서명 된 토큰을 반환하는 OS에 대한 호출이 있는데,이를 서버로 보내고 확인할 수 있습니다. 죄송합니다. 구체적인 내용이 없습니다. 좋은 예를 사용하는 것은 오류입니다.
Dick Hardt

2
@DickHardt 그러나이 scenary에서 모바일 응용 프로그램이 실제로 사기 응용 프로그램이 아닌 응용 프로그램인지 어떻게 확인합니까?
Rafael Membrives

11

한 가지 해결책은 OAuth 비밀을 코드에 하드 코딩하는 것이지만 일반 문자열은 아닙니다 . 어떤 식 으로든 그것을 난독 처리하십시오-세그먼트로 나누고, 오프셋으로 문자를 이동하고, 회전 시키십시오-이러한 것들 중 일부 또는 전부를하십시오. 크래커는 바이트 코드를 분석하고 문자열을 찾을 수 있지만 난독 화 코드를 이해하기 어려울 수 있습니다.

완벽한 솔루션은 아니지만 저렴한 솔루션입니다.

익스플로잇의 가치에 따라 일부 천재 크래커는 더 긴 길이로 비밀 코드를 찾을 수 있습니다. 이전에 언급 한 서버 측 솔루션의 비용, 크래커가 비밀 코드를 찾는 데 더 많은 노력을 기울일 수있는 인센티브 및 구현할 수있는 난독 화의 복잡성을 고려해야합니다.


1
예, 이것이 합리적이라고 생각합니다. 누군가가 먼저 소비자의 비밀을 추출한 다음 사람들의 자격 증명을 포착하여 의미있는 일을하는 것은 많은 결의가 필요합니다. 유명 앱의 경우 이것이 충분할 것이라고 확신하지는 않지만 평균적인 앱의 경우 구현 시간을 약간의 보안 위협과 균형을 이루어야한다고 생각합니다.
Felixyz

7
한 명의 사용자가 노력을 기울이고 비밀을 공개하거나 공유하기 만하면됩니다. 비밀이 밝혀지면 악용 사례로 인해 서비스가 완전히 종료 될 위험이 있으며 통제 할 수 없습니다.
quasistoic

8
난독 화는 전혀 안전하지 않습니다. 이것은 개발자에게 잘못된 보안 감각을 제공하기 때문에 전혀 보안이없는 것보다 나쁩니다. en.wikipedia.org/wiki/Security_through_obscurity
Paul Legato

8
"폐쇄는 전혀 보안이 아닙니다. 이는 개발자에게 잘못된 보안 감각을 제공하기 때문에 전혀 보안이없는 것보다 더 나쁩니다." 무의미한 말. 난독 화가 보안을 강화한다고 말하는 사람은 없습니다. 그러나 내 APK와 함께 OAuth 비밀을 배포하려는 경우 반드시 난독 화하는 것이 좋습니다. 난독 화는 키 / 비밀을 인앱에 저장할 때 Google이 권장하는 것입니다. 다른 방법이 없다면 이러한 조치는 캐주얼 해커를 막아주는 것입니다. 당신과 같은 담요 진술은 보안이없는 완벽한 보안과 같습니다. 그것은 사실이 아닙니다. 불완전은 단지 불완전합니다.
hungryghost

1
얼마나 많은 시프트 또는 인코딩을 수행하더라도 키를 함께 구성하고이를 사용하여 API 요청을 작성하기 때문에 난독 화는 도움이되지 않습니다. HTTPS 암호화 전에 전송중인 요청을 덤프하기 위해 올바른 위치에 API를 동적으로 연결하는 것은 매우 간단합니다. 따라서 가능한 대안이 없다면 앱에 비밀 키를 포함시키지 마십시오.
C0deH4cker

6

응용 프로그램 내부에 비밀을 저장하지 마십시오.

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

누군가가 모바일 / 데스크톱 응용 프로그램을 통해 로그인하려는 경우 응용 프로그램은 요청을 서버로 전달한 다음 비밀을 추가하여 서비스 공급자에게 보냅니다. 그러면 서버는 응용 프로그램이 성공했는지 여부를 알려줄 수 있습니다.

그런 다음 서비스 (페이스 북, 구글, 트위터 등)에서 민감한 정보를 얻으려면 응용 프로그램이 서버에 요청하면 서버는 응용 프로그램에 올바르게 연결되어있는 경우에만 정보를 제공합니다.

실제로 서버에 저장하는 것 외에는 어떤 옵션도 없습니다. 클라이언트 측의 보안은 없습니다.

노트

즉, 이것은 악의적 인 클라이언트로부터 만 보호하지만 악의적 인 사용자로부터의 클라이언트는 아닌 다른 악의적 인 클라이언트 (파이 싱)에 대한 클라이언트는 아닙니다

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


1
이것이 해커의 삶을 더 쉽게 만들지 않습니까?! 이제 서버 리소스에 액세스하려면 기술적으로 클라이언트 ID가 필요합니다. 서버는 어쨌든 요청에 ​​비밀을 추가하기 때문입니다. 뭔가 빠졌습니까?
Hudi Ilfeld

@HudiIlfeld 네, 뭔가 빠졌습니다 : 클라이언트가 서버에 로그인해야합니다. 그가 로그인하지 않는 한 서버는 아무것도 반환하지 않습니다. 이를 관리하는 한 가지 방법은 처음으로 자격 증명을 전송 한 후 서버가 클라이언트에 액세스 토큰을 반환 한 다음 클라이언트가 이후의 모든 요청과 함께이 액세스 토큰을 전송하는 것입니다. 여기에는 많은 옵션이 있습니다.
Gudradain

4

PKCE (Proof Key for Code Exchange) 라는 인증 코드 부여 유형에 새로운 확장이 있습니다 . 그것으로, 당신은 클라이언트 비밀이 필요하지 않습니다.

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

기본 및 모바일 앱에서 주로 사용되지만이 기술은 모든 공용 클라이언트에도 적용될 수 있습니다. 권한 부여 서버의 추가 지원이 필요하므로 특정 제공자에서만 지원됩니다.

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

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


2

생각해 볼 점이 있습니다. Google은 도메인을 등록하고 고유 키를 생성하는 웹 앱과 "익명"키를 사용하는 설치된 앱에 대해 두 가지 OAuth 방법을 제공합니다.

어쩌면 나는 독서에서 무언가를 좋아했지만 웹 응용 프로그램의 고유 키를 설치된 앱과 공유하는 것이 공식 설치된 앱 방법에서 "익명"을 사용하는 것보다 더 안전한 것 같습니다.


2

OAuth 2.0에서는 단순히 클라이언트 측 흐름을 사용하여 액세스 토큰을 얻은 다음이 액세스 토큰을 사용하여 모든 추가 요청을 인증 할 수 있습니다. 그럼 당신은 전혀 비밀이 필요하지 않습니다.

이것을 구현하는 방법에 대한 좋은 설명은 여기에서 찾을 수 있습니다 : https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps


서비스가 "클라이언트 측 흐름"을 지원합니다. 많은 사람들이 대신이 액세스 토큰을 얻기 위해 클라이언트 ID와 클라이언트 시크릿을 요구하지 않습니다.
Damian Yerrick

0

OAuth에 대한 경험이 많지 않지만 모든 요청에 ​​사용자의 액세스 토큰뿐만 아니라 응용 프로그램 소비자 키와 비밀도 필요합니까? 따라서 누군가가 모바일 장치를 훔쳐서 데이터를 가져 오려고 시도하더라도 실제로 어떤 작업을 수행하려면 응용 프로그램 키와 비밀이 필요합니다.

나는 항상 OAuth의 의도는 매시업을 한 모든 Tom, Dick 및 Harry가 트위터 자격 증명을 명확하게 저장할 필요가 없도록 생각했다. 나는 그것이 한계에도 불구하고 그 문제를 아주 잘 해결한다고 생각합니다. 또한 실제로 iPhone을 염두에두고 설계되지 않았습니다.


맞습니다. OAuth는 주로 웹 앱을 염두에두고 설계되었으며 잘 작동합니다. 예, 각 요청에 서명하려면 소비자 토큰과 비밀이 필요하며 문제는 비밀을 저장할 위치입니다. 누군가가 액세스 키를 훔치는 경우 취소 할 수 있기 때문에 큰 문제는 아니지만 누군가가 소비자 키를 얻는 경우 모든 앱 사본이 손상되었습니다.
Felixyz

OAuth 1은 각 요청에 서명해야합니다. OAuth 2에는 액세스 토큰 만 필요합니다. 토큰을 획득 할 때 키와 비밀이 필요합니다.
Dick Hardt

0

나는 Felixyz에 동의합니다. OAuth는 Basic Auth보다 낫지 만 여전히 모바일 앱을위한 훌륭한 솔루션이 될 수있는 길이 멀다. OAuth를 사용하여 Google App Engine 앱에 대한 휴대 전화 앱을 인증하고 있습니다. 모바일 장치에서 소비자 암호를 안정적으로 관리 할 수 ​​없다는 것은 기본적으로 '익명'액세스를 사용하는 것입니다.

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

YourApp (yourapp.appspot.com)-Google과 제휴하지 않음

기타

사용자 정의 구성표를 사용하여 콜백을 가로채는 경우 Android에서 제공 할 수있는 콜백 URL에 사용 된 도메인 / 호스트 이름에서 <일부 사이트>를 가져옵니다. 따라서 '익명'액세스를 사용하거나 소비자의 비밀이 손상되면 누구나 사용자를 속여 앱에 대한 액세스 권한을 부여하는 소비자를 작성할 수 있습니다.

Google OAuth 인증 페이지에는 '익명', 소비자 비밀 또는 공개 키 사용 여부에 따라 심각도가 3 단계 인 경고가 많이 포함되어 있습니다.

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

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


0

또한 모바일 OAuth 인증을위한 솔루션을 고안하고 일반적으로 응용 프로그램 번들 내에 비밀을 저장하려고합니다.

그리고 미친 아이디어가 나에게 맞았습니다. 가장 간단한 아이디어는 이진 안에 비밀을 저장하는 것이지만 어쨌든 난독 화되거나, 다시 말해 암호화 된 비밀을 저장하는 것입니다. 즉, 비밀을 해독하기위한 키를 저장해야한다는 의미입니다. 그러나 이미 OS에있는 키를 사용하십시오. 즉, 키가 응용 프로그램이 아닌 OS에 의해 정의 된 이유는 무엇입니까?

따라서 내 생각을 분명히하기 위해 OS에 의해 정의 된 문자열을 선택한다는 것이 중요합니다. 그런 다음이 문자열을 키로 사용하여 비밀을 암호화하고 앱에 저장하십시오. 그런 다음 런타임 중에 OS 상수 인 키를 사용하여 변수를 해독하십시오. 바이너리로 엿보는 해커는 암호화 된 문자열을 볼 수 있지만 키는 없습니다.

작동합니까?


3
좋은 생각이지만 아닙니다. 크래커는 바이너리가 OS 상수의 주소를 가리키는 것을 볼 수 있습니다.
GrayB



0

이러한 솔루션 중 어느 것도 결정된 해커가 자신의 모바일 장치 (또는 에뮬레이터)에서 보낸 패킷을 스니핑하여 http 헤더에서 클라이언트 시크릿을 보지 못하게합니다.

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

이런 식으로 비밀이 손상 되더라도 해커는 최대 5 분 동안 만 암호를 사용할 수 있습니다.


-2

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

또한 Android의 UNIX 기반 보안 모델을 항상 사용할 수 있습니다. 응용 프로그램 만 파일 시스템에 쓰는 내용에 액세스 할 수 있습니다. 앱의 기본 SharedPreferences 객체에 정보를 작성하십시오.

비밀을 얻으려면 안드로이드 폰에 대한 루트 액세스 권한을 얻어야합니다.


3
누가 언급 했습니까? poke의 의견을 의미하는 경우 내 대답은 비밀입니다! = 인증 키. 후자는 안전하게 보관할 수 있지만 전자는 보관할 수 없습니다. 나는 안드로이드에 대해 모른다.하지만 아이폰에 대한 루트 액세스 권한을 얻는 것은 결코 어렵지 않습니다. 비밀은 앱의 모든 인스턴스에서 동일하므로 공격자는 하나의 바이너리에만 액세스하면됩니다. 그리고 장치에서 루트 액세스 권한을 얻지 못하더라도 바이너리에 손을 대고 비밀 토큰을 꺼낼 수 있습니다.
Felixyz

1
추가하는 것만으로도 안드로이드 폰을
루팅
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.