Primeira regra de segurança do aplicativo: qualquer máquina na qual um invasor obtenha acesso físico ou eletrônico irrestrito agora pertence ao invasor, independentemente de onde ele esteja ou do que você pagou por ele.
Segunda regra de segurança do aplicativo: qualquer software que deixe os limites físicos dentro dos quais um invasor não pode penetrar agora pertence ao invasor, independentemente de quanto tempo você gastou para codificá-lo.
Terceira regra: qualquer informação que deixe os mesmos limites físicos que um invasor não pode penetrar agora pertence ao invasor, por mais valioso que seja para você.
Os fundamentos da segurança da tecnologia da informação são baseados nesses três princípios fundamentais; o único computador verdadeiramente seguro é aquele trancado em um cofre, dentro de uma gaiola de Farraday, dentro de uma gaiola de aço. Existem computadores que passam a maior parte de suas vidas de serviço exatamente nesse estado; uma vez por ano (ou menos), eles geram as chaves privadas para autoridades de certificação raiz confiáveis (na frente de uma série de testemunhas com câmeras gravando cada centímetro da sala em que estão localizadas).
Agora, a maioria dos computadores não é usada nesses tipos de ambientes; eles estão fisicamente abertos, conectados à Internet por um canal de rádio sem fio. Em resumo, eles são vulneráveis, assim como o software deles. Portanto, eles não são confiáveis. Há certas coisas que os computadores e seus softwares precisam saber ou fazer para serem úteis, mas deve-se tomar cuidado para garantir que eles nunca saibam ou façam o suficiente para causar danos (pelo menos não danos permanentes fora dos limites daquela máquina única) )
Você já sabia tudo isso; é por isso que você está tentando proteger o código do seu aplicativo. Mas, aí está o primeiro problema; ferramentas de ofuscação podem tornar o código uma bagunça para um ser humano tentar cavar, mas o programa ainda precisa ser executado; isso significa que o fluxo lógico real do aplicativo e os dados que ele usa não são afetados pela ofuscação. Com um pouco de tenacidade, um invasor pode simplesmente ocultar o código, e isso nem é necessário em certos casos em que o que ele está vendo não pode ser outra coisa senão o que ele está procurando.
Em vez disso, você deve tentar garantir que um invasor não possa fazer nada com seu código, não importa o quão fácil seja para ele obter uma cópia clara dele. Isso significa que não há segredos codificados, porque esses segredos não são secretos assim que o código sai do edifício em que você o desenvolveu.
Esses valores-chave que você codificou permanentemente devem ser removidos do código-fonte do aplicativo. Em vez disso, eles devem estar em um dos três lugares; memória volátil no dispositivo, o que é mais difícil (mas ainda não impossível) para um invasor obter uma cópia offline do; permanentemente no cluster de servidores, ao qual você controla o acesso com mão de ferro; ou em um segundo armazenamento de dados não relacionado ao seu dispositivo ou servidores, como um cartão físico ou nas memórias do usuário (o que significa que eventualmente estará na memória volátil, mas não precisa ser por muito tempo).
Considere o seguinte esquema. O usuário insere suas credenciais para o aplicativo da memória no dispositivo. Infelizmente, você deve confiar que o dispositivo do usuário ainda não foi comprometido por um keylogger ou Trojan; o melhor que você pode fazer nesse sentido é implementar a segurança multifatorial, lembrando informações de identificação difíceis de falsificar sobre os dispositivos que o usuário usou (MAC / IP, IMEI, etc.) e fornecendo pelo menos um canal adicional por qual uma tentativa de login em um dispositivo desconhecido pode ser verificada.
As credenciais, uma vez inseridas, são ofuscadas pelo software cliente (usando um hash seguro) e as credenciais em texto sem formatação são descartadas; eles serviram ao seu propósito. As credenciais ofuscadas são enviadas através de um canal seguro para o servidor autenticado por certificado, que as processa novamente para produzir os dados usados para verificar a validade do logon. Dessa forma, o cliente nunca sabe o que realmente é comparado ao valor do banco de dados, o servidor de aplicativos nunca conhece as credenciais em texto sem formatação por trás do que recebe para validação, o servidor de dados nunca sabe como os dados que armazena para validação são produzidos, e um homem o meio vê apenas palavras sem sentido, mesmo que o canal seguro esteja comprometido.
Uma vez verificado, o servidor transmite de volta um token pelo canal. O token é útil apenas dentro da sessão segura, é composto por ruído aleatório ou uma cópia criptografada (e, portanto, verificável) dos identificadores da sessão, e o aplicativo cliente deve enviar esse token no mesmo canal para o servidor como parte de qualquer solicitação fazer alguma coisa. O aplicativo cliente fará isso muitas vezes, porque não pode fazer nada que envolva dinheiro, dados confidenciais ou qualquer outra coisa que possa ser prejudicial por si só; em vez disso, ele deve solicitar ao servidor para executar esta tarefa. O aplicativo cliente nunca gravará nenhuma informação confidencial na memória persistente no próprio dispositivo, pelo menos não em texto sem formatação; o cliente pode solicitar ao servidor pelo canal seguro uma chave simétrica para criptografar quaisquer dados locais, dos quais o servidor se lembrará; em uma sessão posterior, o cliente pode solicitar ao servidor a mesma chave para descriptografar os dados para uso em memória volátil. Esses dados também não serão a única cópia; tudo o que o cliente armazena também deve ser transmitido de alguma forma para o servidor.
Obviamente, isso torna seu aplicativo fortemente dependente do acesso à Internet; o dispositivo cliente não pode executar nenhuma de suas funções básicas sem conexão e autenticação adequadas pelo servidor. Não é diferente do Facebook, na verdade.
Agora, o computador que o invasor deseja é o seu servidor, porque ele, e não o aplicativo / dispositivo do cliente, é algo que pode lhe render dinheiro ou causar dor a outras pessoas por sua diversão. Isso está ok; você ganha muito mais dinheiro gastando dinheiro e esforço para proteger o servidor do que tentando proteger todos os clientes. O servidor pode estar protegido por todos os tipos de firewalls e outros tipos de segurança eletrônica e, além disso, pode ser protegido fisicamente por proteção contra aço, concreto, acesso por cartão / PIN e vigilância por vídeo 24 horas. Seu invasor precisaria ser muito sofisticado para obter qualquer tipo de acesso diretamente ao servidor, e você (deveria) saberia imediatamente.
O melhor que um invasor pode fazer é roubar o telefone e as credenciais de um usuário e efetuar login no servidor com os direitos limitados do cliente. Caso isso aconteça, assim como a perda de um cartão de crédito, o usuário legítimo deve ser instruído a ligar para um número 800 (de preferência fácil de lembrar, e não no verso de um cartão que levaria na bolsa, na carteira ou na maleta que poderia ser roubados juntamente com o dispositivo móvel) de qualquer telefone que eles possam acessar que os conecte diretamente ao serviço ao cliente. Eles afirmam que o telefone foi roubado, fornecem algum identificador exclusivo básico e a conta está bloqueada, todas as transações que o invasor pode ter sido processado são revertidas e o invasor volta à estaca zero.