Ao desenvolver aplicativos de desktop ou móveis, ocasionalmente você terá que armazenar credenciais em algum lugar para poder autenticar seu aplicativo. Um exemplo disso é um ID de aplicativo do Facebook + segredo , outros são credenciais do MySQL ou Chave de API e Segredo de API.
Armazenar esse texto simples no código-fonte do aplicativo não fornece nenhuma segurança real, pois não é muito complicado fazer engenharia reversa de um programa . Coletar as credenciais de um servidor também não resolverá o problema, pois os hackers podem facilmente executar as solicitações por conta própria. A criptografia das credenciais armazenadas também não fará diferença, pois o aplicativo precisará acessar a chave de descriptografia para poder usar as credenciais.
Como alguém pode armazenar credenciais específicas de aplicativos com segurança? De preferência cross-OS.
Nunca codifique senhas ou chaves criptográficas em seu programa.
A regra geral é: as únicas credenciais que você deve armazenar na máquina de um usuário são as credenciais associadas a esse usuário , por exemplo, credenciais que permitem que esse usuário faça login em sua conta.
Você não deve armazenar suas credenciais de desenvolvedor na máquina do usuário . Isso não é seguro.
Você deve assumir que qualquer coisa armazenada na máquina do usuário é conhecida pelo usuário ou pode ser facilmente aprendida pelo usuário. (Esta é a suposição correta: não é difícil fazer engenharia reversa de um binário de aplicativo para aprender quaisquer chaves ou segredos que possam estar embutidos nele.)
Depois de entender esse princípio geral, tudo se torna fácil. Basicamente, você precisa projetar o resto do seu sistema e seu protocolo de autenticação para que o software cliente possa se autenticar usando apenas as credenciais seguras para armazenar no cliente.
Exemplo 1. Suponha que você tenha um ID e uma chave de aplicativo do Facebook associados ao seu aplicativo (ou seja, associados à sua conta de desenvolvedor). Você incorpora o ID e a chave do aplicativo no software de desktop que envia aos usuários? Não! Absolutamente não. Você definitivamente não faz isso, porque isso permitiria que qualquer um de seus usuários aprendesse o ID e a chave do aplicativo e enviasse suas próprias solicitações, possivelmente prejudicando sua reputação.
Em vez disso, você encontra outra maneira. Por exemplo, talvez você configure seu próprio servidor que possui o ID e a chave do aplicativo e é responsável por fazer as solicitações para a plataforma do Facebook (sujeito às limitações apropriadas e à limitação de taxa). Em seguida, seu cliente se conecta ao seu servidor. Talvez você autentique cada cliente fazendo com que cada usuário configure sua própria conta de usuário em seu servidor, armazenando as credenciais da conta no cliente e fazendo com que o cliente se autentique usando essas credenciais.
Você pode tornar isso totalmente invisível para o usuário fazendo com que o aplicativo cliente gere uma nova conta de usuário na primeira execução (gerando suas próprias credenciais de login, armazenando-as localmente e enviando-as ao servidor). O aplicativo cliente pode usar essas credenciais armazenadas para se conectar no futuro (digamos, por SSL) e efetuar login automaticamente toda vez que o aplicativo for executado.
Observe como a única coisa armazenada na máquina de um usuário são as credenciais que permitem fazer login na conta desse usuário - mas nada que permita fazer login nas contas de outras pessoas e nada que exponha as chaves do aplicativo do desenvolvedor.
Exemplo 2. Suponha que você escreva um aplicativo que precise acessar os dados do usuário em sua conta do Google. Você solicita o nome de usuário e a senha do Google e os armazena no armazenamento local do aplicativo? Você poderia: tudo bem, porque as credenciais do usuário são armazenadas na máquina do usuário. O usuário não tem incentivo para tentar hackear sua própria máquina, porque já conhece suas próprias credenciais.
Melhor ainda: use OAuth para autorizar seu aplicativo. Dessa forma, seu aplicativo armazena um token OAuth em seu armazenamento local do aplicativo, o que permite que seu aplicativo acesse a conta do Google do usuário. Também evita a necessidade de armazenar a senha do Google do usuário (que é particularmente sensível) no armazenamento local do aplicativo, reduzindo assim o risco de comprometimento.
Exemplo 3. Suponha que você esteja escrevendo um aplicativo que tenha um back-end de banco de dados MySQL compartilhado entre todos os usuários. Você pega o banco de dados MySQL e o incorpora ao binário do aplicativo? Não! Qualquer um de seus usuários pode extrair a senha e obter acesso direto ao seu banco de dados MySQL.
Em vez disso, você configura um serviço que fornece a funcionalidade necessária. O aplicativo cliente se conecta ao serviço, se autentica e envia a solicitação ao serviço. O serviço pode então executar essa solicitação no banco de dados MySQL. A senha do MySQL permanece armazenada com segurança na máquina do servidor e nunca é acessível na máquina de qualquer usuário. O servidor pode impor qualquer restrição ou controle de acesso que você desejar.
Isso requer que seu aplicativo cliente seja capaz de se autenticar no serviço. Uma maneira de fazer isso é fazer com que o aplicativo cliente crie uma nova conta no serviço na primeira execução, gere uma credencial de autenticação aleatória e faça login automaticamente no serviço a cada vez subsequente. Você pode usar SSL com uma senha aleatória ou, melhor ainda, usar algo como SSL com um certificado de cliente exclusivo para cada cliente.
A outra regra é: você não codifica credenciais no programa. Se você estiver armazenando credenciais na máquina do usuário, armazene-as em algum local privado: talvez um arquivo de configuração ou em um diretório, de preferência um que seja legível apenas por este aplicativo ou usuário específico (não um arquivo legível por todos).
Lembre-se por mais seguros que pensamos estar nunca estaremos totalmentes seguros