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.