Prática recomendada para armazenar e proteger chaves de API privadas em aplicativos [fechado]


373

A maioria dos desenvolvedores de aplicativos integrará algumas bibliotecas de terceiros em seus aplicativos. Se é para acessar um serviço, como Dropbox ou YouTube, ou para falhas de registro. O número de bibliotecas e serviços de terceiros é impressionante. A maioria dessas bibliotecas e serviços é integrada de alguma maneira pela autenticação com o serviço, na maioria das vezes, isso acontece por meio de uma chave de API. Por motivos de segurança, os serviços geralmente geram uma chave pública e privada, geralmente também conhecida como chave secreta. Infelizmente, para se conectar aos serviços, essa chave privada deve ser usada para autenticar e, portanto, provavelmente fazer parte do aplicativo. Escusado será dizer que isso enfrenta um imenso problema de segurança. As chaves de API públicas e privadas podem ser extraídas dos APKs em questão de minutos e podem ser facilmente automatizadas.

Supondo que eu tenha algo parecido com isso, como posso proteger a chave secreta:

public class DropboxService  {

    private final static String APP_KEY = "jk433g34hg3";
    private final static String APP_SECRET = "987dwdqwdqw90";
    private final static AccessType ACCESS_TYPE = AccessType.DROPBOX;

    // SOME MORE CODE HERE

}

Na sua opinião, qual é a melhor e mais segura maneira de armazenar a chave privada? Ofuscação, criptografia, o que você acha?



Eu tinha loja na imagem / png e obter chave através png como BufferReader
Sumit

Eu acho que essa é uma preocupação válida e postou um problema semelhante na página do github do Firebase Android SDK: github.com/firebase/firebase-android-sdk/issues/1583 . Vamos ver se isso é tratado.
grebulon

Respostas:


348
  1. Como está, seu aplicativo compilado contém as cadeias de teclas, mas também os nomes constantes APP_KEY e APP_SECRET. Extrair chaves desse código de auto-documentação é trivial, por exemplo, com a ferramenta Android padrão dx.

  2. Você pode aplicar o ProGuard. Ele deixará as cadeias de teclas intocadas, mas removerá os nomes das constantes. Ele também renomeará classes e métodos com nomes curtos e sem sentido, sempre que possível. A extração das chaves leva mais tempo, para descobrir qual sequência serve para qual finalidade.

    Observe que a instalação do ProGuard não deve ser tão difícil quanto você teme. Para começar, você só precisa ativar o ProGuard, conforme documentado em project.properties. Se houver algum problema com as bibliotecas de terceiros, talvez seja necessário suprimir alguns avisos e / ou impedir que eles sejam ofuscados, em proguard-project.txt. Por exemplo:

    -dontwarn com.dropbox.**
    -keep class com.dropbox.** { *; }

    Essa é uma abordagem de força bruta; você pode refinar essa configuração assim que o aplicativo processado funcionar.

  3. Você pode ofuscar as strings manualmente no seu código, por exemplo, com uma codificação Base64 ou, de preferência, com algo mais complicado; talvez até código nativo. Um hacker precisará, então, fazer engenharia reversa estaticamente na sua codificação ou interceptar dinamicamente a decodificação no local apropriado.

  4. Você pode aplicar um ofuscador comercial, como o irmão especializado do ProGuard, DexGuard . Além disso, ele pode criptografar / ofuscar as strings e classes para você. A extração das chaves leva ainda mais tempo e conhecimento.

  5. Você pode executar partes do seu aplicativo em seu próprio servidor. Se você pode manter as chaves lá, elas são seguras.

No final, é uma troca econômica que você deve fazer: qual a importância das chaves, quanto tempo ou software você pode pagar, qual a sofisticação dos hackers que estão interessados ​​nas chaves e quanto tempo eles desejam gastar, quanto vale um atraso antes que as chaves sejam invadidas, em que escala algum hacker bem-sucedido distribuirá as chaves, etc. Pequenas informações como chaves são mais difíceis de proteger do que aplicativos inteiros. Intrinsecamente, nada do lado do cliente é inquebrável, mas você certamente pode elevar a fasquia.

(Eu sou o desenvolvedor do ProGuard e DexGuard)


2
@EricLafortune não faz diferença se a string da chave privada é armazenada na classe Java vs no XML do recurso String?
Alan

11
@EricLafortune Agora é possível usar o sistema Android Keystore para armazenar as chaves com segurança? ( developer.android.com/training/articles/keystore.html )
David Thomas

11
@ DavidThomas: Você tentou usar o keystore. Quero ofuscar uma chave de API escrita na classe Java. Por favor responda
Sagar Trehan

11
O Android KeyStore é útil para isso? ( developer.android.com/training/articles/… )
Weishi Zeng

11
Eu não entendo # 5. Não tem os mesmos problemas exatos que o problema original?
Pete

80

Poucas idéias, na minha opinião, apenas a primeira dá alguma garantia:

  1. Mantenha seus segredos em algum servidor na Internet e, quando necessário, apenas pegue-os e use-os. Se o usuário estiver prestes a usar o dropbox, nada o impedirá de fazer uma solicitação ao seu site e obter sua chave secreta.

  2. Coloque seus segredos no código jni, adicione algum código de variável para tornar suas bibliotecas maiores e mais difíceis de descompilar. Você também pode dividir as chaves em poucas partes e mantê-las em vários lugares.

  3. use ofuscador, também coloque código hash secreto e mais tarde unhash quando necessário.

  4. Coloque sua chave secreta como os últimos pixels de uma imagem em ativos. Quando necessário, leia-o no seu código. Ofuscar seu código deve ajudar a ocultar o código que o lerá.

Se você quiser dar uma olhada rápida em como é fácil ler o código apk, então pegue o APKAnalyser:

http://developer.sonymobile.com/knowledge-base/tool-guides/analyse-your-apks-with-apkanalyser/


46
se o usuário puder descompilar o aplicativo, provavelmente poderá determinar a solicitação feita ao seu próprio servidor e simplesmente executá-la para se manter em segredo. Nenhuma bala de prata aqui, mas dê alguns passos e eu aposto que você ficará bem! Se seu aplicativo é super popular, talvez não seja .. Ótimas idéias!
Matt Wolfe

3
sim, o número 1 não dá garantia.
marcinj

42
Eu realmente gosto da idéia de esconder as chaves nas imagens. +1
Igor Čordaš

11
@ MarcinJędrzejewski Você gostaria de explicar mais (com exemplo de amostra ou código cortado) sobre a quarta solução? Obrigado.
Dr.jacky

2
@ Mr.Hyde, isso é chamado de esteganografia, é muito complexo para fornecer um código de exemplo aqui, você pode encontrar exemplos no google. Encontrei um aqui: dreamincode.net/forums/topic/27950-steganography . A idéia é ótima, mas como o código apk pode ser descompilado, estraga sua beleza.
marcinj

33

Outra abordagem é não ter o segredo no dispositivo em primeiro lugar! Consulte Técnicas de segurança da API móvel (especialmente a parte 3).

Usando a antiga tradição de indireção, compartilhe o segredo entre o terminal da API e um serviço de autenticação de aplicativos.

Quando seu cliente deseja fazer uma chamada de API , solicita que o serviço de autenticação de aplicativo o autentique (usando técnicas fortes de atestado remoto) e recebe um token de tempo limitado (geralmente JWT ) assinado pelo segredo.

O token é enviado com cada chamada da API em que o terminal pode verificar sua assinatura antes de agir na solicitação.

O segredo real nunca está presente no dispositivo; de fato, o aplicativo nunca tem idéia se é válido ou não, ele solicita autenticação e passa o token resultante. Como um bom benefício da indireção, se você quiser alterar o segredo, poderá fazê-lo sem exigir que os usuários atualizem seus aplicativos instalados.

Portanto, se você deseja proteger seu segredo, não tê-lo em seu aplicativo é um bom caminho.


5
Essa deve ser a resposta aceita.
ortonomy

3
O problema persiste quando você deseja acessar o serviço de autenticação. Ele fornecerá um ID do cliente e um segredo do cliente. Onde devemos salvá-los?
Ashi

não resolve apis particulares onde você precisa se autenticar primeiro na sua API para usá-la. onde você obtém as credenciais para todos os usuários do aplicativo?
Kibotu 20/01

25

Maneira velha não segura:

Siga três etapas simples para proteger a API / chave secreta ( resposta antiga )

Podemos usar o Gradle para proteger a chave da API ou a chave secreta.

1. gradle.properties (Propriedades do projeto): Crie variável com a chave.

GoolgeAPIKey = "Your API/Secret Key"

2. build.gradle (Module: app): defina a variável em build.gradle para acessá-la em atividade ou fragmento. Adicione o código abaixo para buildTypes {}.

buildTypes.each {
    it.buildConfigField 'String', 'GoogleSecAPIKEY', GoolgeAPIKey
}

3. Acesse-o em Activity / Fragment pelo BuildConfig do aplicativo:

BuildConfig.GoogleSecAPIKEY

Atualização:

A solução acima é útil no projeto de código aberto para confirmar sobre o Git. (Obrigado a David Rawson e riyaz-ali pelo seu comentário).

De acordo com os comentários de Matthew e Pablo Cegarra, a maneira acima não é segura e o Decompiler permitirá que alguém veja o BuildConfig com nossas chaves secretas.

Solução:

Podemos usar o NDK para proteger as chaves da API. Podemos armazenar chaves na classe nativa C / C ++ e acessá-las em nossas classes Java.

Siga este blog para proteger as chaves da API usando NDK.

Um acompanhamento sobre como armazenar tokens com segurança no Android


4
armazenar uma chave no arquivo gradle é seguro?
Google

4
@Google gradle.propertiesnão deve ser verificado para Git por isso esta é uma forma de manter a fora segredo do código fonte comprometida, pelo menos
David Rawson

4
Isso não impede que a chave da API seja empacotada no resultado apk(será adicionada ao BuildConfigarquivo gerado ), embora seja definitivamente uma boa idéia gerenciar diferentes chaves da API (por exemplo, em um projeto de código aberto)
riyaz-ali

5
Usando uma Java Decompiler vai permitir que alguém para ver o ficheiro BuildConfig e "GoogleSecAPIKEY"
Matthew

3
Seu BuildConfig.javaarquivo terá a chave em forma de texto sem formatação. Isso não é melhor do que o que o OP já está fazendo.
iceman

16

A chave App-Secret deve ser mantida em sigilo - mas, ao liberar o aplicativo, elas podem ser revertidas por alguns caras.

para aqueles caras que não vai esconder, bloqueie ProGuardo código. É um refator e alguns ofuscadores pagos estão inserindo alguns operadores bit a bit para recuperar a jk433g34hg3 String. Você pode aumentar de 5 a 15 minutos os hackers se trabalhar 3 dias :)

A melhor maneira é mantê-lo como está, imho.

Mesmo se você armazenar no lado do servidor (seu PC), a chave poderá ser invadida e impressa. Talvez isso demore mais? De qualquer forma, é uma questão de alguns minutos ou algumas horas, na melhor das hipóteses.

Um usuário normal não descompilará seu código.


11
Bem - não é a resposta que eu esperava obter =) ... Eu pensei que você poderia obter uma grande segurança :(
Coder básico

desculpe, não é como você queria uma solução brilhante e ultra segura, mas para quem pode usar o compilador, o descompilador não existe código java seguro: até o código nativo pode ser visualizado com visualizador hexa e decriptografado. Pelo menos vale a pena tentar ...

11
O programa não ofusca a chave real ...? A melhor coisa a fazer é uma rotina simples de encriptar / descriptografar, que ofuscará a ocultação.
Doomsknight

3
é "visível" a rotina de descriptografia, é fácil fazer o inverso e você tem a string original

14

Uma solução possível é codificar os dados no seu aplicativo e usar a decodificação em tempo de execução (quando você deseja usar esses dados). Também recomendo usar progaurd para dificultar a leitura e a compreensão do código-fonte descompilado do seu aplicativo. por exemplo, coloquei uma chave codificada no aplicativo e usei um método de decodificação no meu aplicativo para decodificar minhas chaves secretas em tempo de execução:

// "the real string is: "mypassword" "; 
//encoded 2 times with an algorithm or you can encode with other algorithms too
public String getClientSecret() {
    return Utils.decode(Utils
            .decode("Ylhsd1lYTnpkMjl5WkE9PQ=="));
}

O código fonte descompilado de um aplicativo programado é este:

 public String c()
 {
    return com.myrpoject.mypackage.g.h.a(com.myrpoject.mypackage.g.h.a("Ylhsd1lYTnpkMjl5WkE9PQ=="));
  }

Pelo menos é bastante complicado para mim. é dessa maneira que faço quando não tenho escolha, além de armazenar um valor no meu aplicativo. É claro que todos sabemos que não é o melhor caminho, mas funciona para mim.

/**
 * @param input
 * @return decoded string
 */
public static String decode(String input) {
    // Receiving side
    String text = "";
    try {
        byte[] data = Decoder.decode(input);
        text = new String(data, "UTF-8");
        return text;
    } catch (UnsupportedEncodingException e) {
        e.printStackTrace();
    }
    return "Error";
}

Versão descompilada:

 public static String a(String paramString)
  {
    try
    {
      str = new String(a.a(paramString), "UTF-8");
      return str;
    }
    catch (UnsupportedEncodingException localUnsupportedEncodingException)
    {
      while (true)
      {
        localUnsupportedEncodingException.printStackTrace();
        String str = "Error";
      }
    }
  }

e você pode encontrar muitas classes de criptografia com uma pequena pesquisa no google.


13

Adicionando à solução @Manohar Reddy, o firebase Database ou o firebase RemoteConfig (com valor padrão Nulo) pode ser usado:

  1. Codifique suas chaves
  2. Armazene-o no banco de dados firebase
  3. Obtê-lo durante a inicialização do aplicativo ou sempre que necessário
  4. decifrar chaves e usá-lo

O que é diferente nesta solução?

  • sem credenciais para firebase
  • o acesso ao firebase é protegido, portanto, apenas o aplicativo com certificado assinado tem privilégio de fazer chamadas de API
  • cifrar / decifrar para impedir a interceptação do intermediário. No entanto, já chama https para firebase

com todos respeitamos esta solução, ainda somos o primeiro quadrado. Em vez de usar credenciais, você sugere usar um certificado. Quem é capaz de roubar suas credenciais é capaz de roubar seu certificado assinado.
Ashi

Uma vantagem, porém, com a solução sugerida, estamos adicionando mais uma complicação na frente do hacker.
Ashi

11

Este exemplo possui vários aspectos diferentes. Mencionarei alguns pontos que acho que não foram explicitamente abordados em outro lugar.

Protegendo o segredo em trânsito

A primeira coisa a observar é que o acesso à API do dropbox usando o mecanismo de autenticação de aplicativos exige que você transmita sua chave e segredo. A conexão é HTTPS, o que significa que você não pode interceptar o tráfego sem conhecer o certificado TLS. Isso evita que uma pessoa intercepte e leia os pacotes em sua jornada do dispositivo móvel para o servidor. Para usuários normais, é realmente uma boa maneira de garantir a privacidade de seu tráfego.

O que não é bom é impedir que uma pessoa mal-intencionada baixe o aplicativo e inspecione o tráfego. É realmente fácil usar um proxy intermediário para todo o tráfego que entra e sai de um dispositivo móvel. Não seria necessária desmontagem ou engenharia reversa de código para extrair a chave e o segredo do aplicativo nesse caso, devido à natureza da API do Dropbox.

Você pode fazer a pinagem, verificando se o certificado TLS que você recebe do servidor é o esperado. Isso adiciona uma verificação ao cliente e dificulta a interceptação do tráfego. Isso tornaria mais difícil inspecionar o tráfego em voo, mas a verificação de fixação ocorre no cliente, portanto, provavelmente ainda seria possível desativar o teste de fixação. Isso torna ainda mais difícil.

Protegendo o segredo em repouso

Como primeiro passo, usar algo como proguard ajudará a tornar menos óbvio onde os segredos são mantidos. Você também pode usar o NDK para armazenar a chave e o segredo e enviar solicitações diretamente, o que reduziria bastante o número de pessoas com as habilidades apropriadas para extrair as informações. Ocultação adicional pode ser alcançada não armazenando os valores diretamente na memória por um período de tempo; você pode criptografá-los e descriptografá-los imediatamente antes do uso, conforme sugerido por outra resposta.

Opções mais avançadas

Se você está paranóico em colocar o segredo em qualquer lugar do seu aplicativo e tem tempo e dinheiro para investir em soluções mais abrangentes, considere armazenar as credenciais em seus servidores (presumindo que você tenha alguma). Isso aumentaria a latência de qualquer chamada para a API, pois ela teria que se comunicar por meio do servidor e poderia aumentar os custos de execução do serviço devido ao aumento da taxa de transferência de dados.

Você precisa decidir a melhor forma de se comunicar com seus servidores para garantir que eles estejam protegidos. Isso é importante para evitar que todos os mesmos problemas surjam novamente com sua API interna. A melhor regra de ouro que posso dar é não transmitir nenhum segredo diretamente por causa da ameaça do homem do meio. Em vez disso, você pode assinar o tráfego usando seu segredo e verificar a integridade de todas as solicitações que chegam ao seu servidor. Uma maneira padrão de fazer isso é calcular um HMAC da mensagem digitada em segredo. Eu trabalho em uma empresa que possui um produto de segurança que também opera nesse campo e é por isso que esse tipo de coisa me interessa. De fato, aqui está um artigo de blog de um dos meus colegas que analisa a maior parte disso.

Quanto devo fazer?

Com conselhos de segurança como esse, você precisa tomar uma decisão de custo / benefício sobre a dificuldade com que alguém entra. Se você é um banco que protege milhões de clientes, seu orçamento é totalmente diferente de alguém que apóia um aplicativo em sua conta. tempo livre. É praticamente impossível impedir que alguém quebre sua segurança, mas na prática poucas pessoas precisam de todos os sinos e assobios e com algumas precauções básicas, você pode percorrer um longo caminho.


11
Você acabou de copiar e colar isso aqui: hackernoon.com/mobile-api-security-techniques-682a5da4fe10 sem reconhecer a fonte.
ortonomy

11
@ortonomy Concordo que ele deveria ter citado o artigo é ligada, mas ele pode ter esquecido, porque ambos trabalham no mesmo lugar ...
Exadra37

2
Também o artigo de Skip e o post do blog em que foram publicados foram publicados uma semana após a minha resposta.
ThePragmatist

8

A solução mais segura é manter as chaves em um servidor e rotear todas as solicitações que precisam dessa chave pelo servidor. Dessa forma, a chave nunca sai do seu servidor, desde que ele esteja seguro, sua chave também. Obviamente, há um custo de desempenho com esta solução.


32
O problema é - para alcançar o servidor que contém todos os segredos, devo usar outra chave secreta - será que vou guardar isso? ;) O que estou tentando dizer é: - Essa também não é a melhor solução (não pense que exista aqui uma solução ideal)
Mercury

Isso não é verdade, seu servidor está completamente sob seu controle. O que exige é inteiramente de sua responsabilidade.
Bernard Igiri 27/01

5
Você pode explicar aqui como o cliente pode criptografar os dados que ele deseja enviar para o servidor, enquanto as chaves estão no lado do servidor? e se sua resposta for - O servidor envia chaves para o cliente - Portanto, isso também deve ser protegido! então novamente não há solução mágica! você não pode ver ?!
Mercury

2
@BardardIgiri e, novamente, voltamos à praça 1. Vamos supor que o telefone crie um login aleatório e o servidor aceite e envie um alfinete (este é o chamado servidor privado que estamos falando). A pessoa que desmonta seu aplicativo vê que tudo o que é necessário para acessar seu servidor privado é apenas um login aleatório que ele mesmo pode criar. Diga-me o que o impede de criar um e acessar seu servidor? Na verdade o que é a diferença entre a sua solução e, na verdade, armazenar um login ou api chave para o servidor principal (cujas credenciais queríamos loja em nosso servidor privado)
Ken

3
@ken O número aleatório é autenticado com base no número de telefone e no acesso físico às suas mensagens de texto. Se alguém te enganar, você terá as informações deles. Se isso não for bom o suficiente, force-os a criar uma conta de usuário e senha completas. Se isso não for bom o suficiente, compre também um cartão de crédito. Se isso não for bom o suficiente, peça para eles ligarem. Se isso não for bom o suficiente, encontre-os cara a cara. Quão seguro / inconveniente você quer ser?
Bernard Igiri 8/03

7

Mantenha o segredo firebase databasee obtenha informações quando o aplicativo for iniciado. É muito melhor do que ligar para um serviço da web.


13
mas e as credenciais para firebase?
28418

2
Infelizmente, o banco de dados Firebase não funciona na China.
Konjengbam

9
Não faz sentido, os atacantes podem vê-lo Firebase detalhes de código decompiled e obter todos os dados do seu datababse
user924

3
Eu acho que essa é a melhor solução, pois o Firebase Apps usa SHA1 para permitir o acesso ao servidor. A descompilação do código não ajudará a fazer uma chamada para o firebase porque o novo aplicativo hacker deve usar o carimbo exato do aplicativo para acessar o firebase. Além disso, a chave armazenada deve ser criptografada antes de armazenar no banco de dados do firebase DB e decifrada uma vez recebida para evitar a interceptação do intermediário.
Ayman Al-Absi 12/09

Quando você obtém o segredo do banco de dados do firebase pela rede, como isso é mais seguro do que obter o mesmo segredo de outro serviço da web por meio de um canal (https) seguro? Você pode explicar?
Csaba Toth

6

O que você fizer para proteger suas chaves secretas não será uma solução real. Se o desenvolvedor puder descompilar o aplicativo, não há como proteger a chave, ocultá-la é apenas segurança pela obscuridade, assim como a ofuscação do código. O problema de proteger uma chave secreta é que, para protegê-la, você precisa usar outra chave e ela também precisa ser protegida. Pense em uma chave escondida em uma caixa que está bloqueada com uma chave. Você coloca uma caixa dentro de uma sala e trava a sala. Você fica com outra chave para proteger. E essa chave ainda será codificada dentro do seu aplicativo.

Portanto, a menos que o usuário insira um PIN ou uma frase, não há como ocultar a chave. Mas para fazer isso, você teria que ter um esquema para gerenciar PINs que acontecem fora da banda, o que significa através de um canal diferente. Certamente não é prático para proteger chaves de serviços como APIs do Google.


5

Idade pós antigo, mas ainda é bom o suficiente. Eu acho que escondê-lo em uma biblioteca .so seria ótimo, usando NDK e C ++, é claro. Os arquivos .so podem ser visualizados em um editor hexadecimal, mas boa sorte é descompilar: P


9
Os usuários podem facilmente fazer chamadas de função para a biblioteca compartilhada e obter o que está oculto lá. Não há necessidade de decopilar.
David72 3/11

5
De acordo com androidauthority.com/…, não há uma maneira segura de fazê-lo no Android no momento.
David72 3/11

11
@AhmedAwad Não entendo por que isso está tendo 3 votos positivos. qualquer um poderia facilmente descompilar o aplicativo e ver como o ponto de entrada do ndk está sendo chamado: /
Johny19

11
Essa resposta é quase uma das melhores opções, mas o autor deve mencionar que é muito importante incluir uma chamada (dentro da sua biblioteca NDK) para ver se a soma de verificação corresponde ao seu APK, caso contrário, alguém pode ligar para a sua biblioteca NDK fora de seu aplicativo
Stoycho Andreev

@ Sniper que seria ótimo, exceto que tem um grande problema. Como você sabe qual arquivo está "chamando" o método nativo? Se você codificar o nome do apk para verificar, ótimo, mas e se eu fizer meu apk "hackear" a mesma pasta que o apk "bom"? Ele verificará se o apk "bom" possui uma boa soma de verificação e me permitirá executar esse método nativo. A menos que haja uma maneira de conhecer o arquivo de chamada do lado do JNI / C ++, não fará sentido as outras opções.
precisa saber é o seguinte

5

A única maneira verdadeira de manter essas informações privadas é mantê-las no servidor e fazer com que o aplicativo envie o que quer que seja para o servidor, e o servidor interage com o Dropbox. Dessa forma, você NUNCA distribuirá sua chave privada em qualquer formato.


11
Mas como você evita que o resto do mundo chame o servidor?
user2966445

Se por "servidor" você se refere ao servidor da web onde estão as credenciais - você pode usar qualquer método que desejar. autenticação simples com nome de usuário / senha, oauth, diretório ativo, etc. etc. Depende muito da sua aplicação.
Nick

Talvez esteja faltando alguma coisa, mas isso ainda não exige o armazenamento de credenciais no aplicativo?
user2966445

3
Certo, mas você disse que o aplicativo se autentica primeiro com o servidor. Isso não significa armazenar outro conjunto de credenciais no aplicativo? Entendo que o servidor lidaria com as chamadas reais da caixa de depósito.
User2966445 9/09/16

4
Bem, isso pode significar isso, mas é uma autorização completamente separada. Mas você não precisa. O caso de uso do qual estou falando é que o usuário do seu aplicativo teria um login no seu aplicativo, digamos, usando o facebook ou o twitter. Você não armazena as credenciais delas no seu aplicativo, nem as conhece. Esse processo de autorização permite que eles acessem o servidor da API, que possui credenciais para a caixa de depósito, mas nenhum aplicativo ou usuário tem acesso direto a eles.
Nick

0

Com base na experiência amarga, e após consultar um especialista do IDA-Pro, a melhor solução é mover uma parte importante do código para um DLL / SharedObject, buscá-lo em um servidor e carregar em tempo de execução.

Os dados confidenciais devem ser codificados, pois é muito fácil fazer algo assim:

$ strings libsecretlib.so | grep My
  My_S3cr3t_P@$$W0rD

3
E onde você está armazenando as credenciais para esse servidor?
ZX9
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.