Estou trabalhando em um site que permitirá que os usuários façam login usando credenciais OAuth dos tipos Twitter, Google etc. Para fazer isso, preciso registrar-me com esses vários provedores e obter uma chave de API super secreta que tenho que proteger com promessas contra várias partes do corpo. Se minha chave for ganked, a peça é arrancada.
A chave da API precisa viajar com minha origem, pois é usada em tempo de execução para executar solicitações de autenticação. No meu caso, a chave deve existir dentro do aplicativo em um arquivo de configuração ou dentro do próprio código. Isso não é um problema quando eu construo e publico de uma única máquina. No entanto, quando lançamos o controle de origem no mix, as coisas ficam mais complicadas.
Como sou um bastardo barato, prefiro muito mais usar serviços gratuitos de controle de código-fonte, como o TFS na nuvem ou o GitHub. Isso me deixa com um pequeno enigma:
Como posso manter meu corpo intacto quando minhas chaves de API estão no meu código e meu código está disponível em um repositório público?
Eu posso pensar em várias formas de lidar com isso, mas nenhuma delas é satisfatória.
Estou realmente procurando uma maneira garantida de garantir que não compartilhe minhas privações com o mundo (exceto no snapchat), que funcionará sem problemas durante o desenvolvimento, a depuração e a implantação, além de ser à prova de falhas. Isso é completamente irrealista. Então o que realisticamente posso fazer?
Detalhes técnicos: VS2012, C # 4.5, controle de origem será TF service ou GitHub. Atualmente usando uma classe parcial para dividir as chaves sensíveis em um arquivo separado .cs que não será adicionado ao controle de origem. Eu acho que o GitHub pode ter a vantagem, pois o .gitignore pode ser usado para garantir que o arquivo de classe parcial não seja verificado, mas eu estraguei tudo antes. Estou esperando por um "oh, problema comum, é assim que você faz", mas eu posso ter que se contentar com "que não chupa tanto quanto poderia ter",: /
Não coloque suas informações secretas em seu código. Coloque-o em um arquivo de configuração que é lido pelo seu código na inicialização. Os arquivos de configuração não devem ser colocados no controle de versão, a menos que sejam os "padrões de fábrica", e então eles não devem ter nenhuma informação privada.
Veja também a pergunta Controle de versão e arquivo de configuração pessoal . como fazer isso bem.
Você pode colocar todas as chaves privadas / protegidas como variáveis de ambiente do sistema. Seu arquivo de configuração ficará assim:
private.key=#{systemEnvironment['PRIVATE_KEY']}
É assim que lidamos com esses casos e nada entra no código. Ele funciona muito bem combinado com diferentes arquivos e perfis de propriedades. Usamos arquivos de propriedades diferentes para diferentes ambientes. Em nosso ambiente de desenvolvimento local, colocamos as chaves de desenvolvimento nos arquivos de propriedades para simplificar a configuração local:
private.key=A_DEVELOPMENT_LONG_KEY
.gitignore incluiu o arquivo com dados privados TEMPLATE por DATA
TEMPLATE < - > %código%
DATA por TEMPLATE (conjuntos de alterações são públicos, o patch é privado) Isso é muito específico para Android / Gradle, mas você pode definir as chaves em seu arquivo global gradle.properties localizado em user home/.gradle/ . Isso também é útil, já que você pode usar diferentes propriedades, dependendo do tipo de buildType ou sabor, ou seja, API para dev e outro diferente para release.
gradle.properties
MY_PRIVATE_API_KEY=12356abcefg
build.gradle
buildTypes {
debug{
buildConfigField("String", "GOOGLE_VERIFICATION_API_KEY", "\"" + MY_PRIVATE_API_KEY +"\"")
minifyEnabled false
applicationIdSuffix ".debug"
}
}
No código você faria referência a isso
String myAPI = BuildConfig.GOOGLE_VERIFICATION_API_KEY;
Eu coloco segredos no (s) arquivo (s) criptografado (s). A frase secreta é fornecida quando o sistema é iniciado ou é armazenada em um arquivo pequeno que eu não confirmo. É legal que o Emacs gerencie alegremente esses arquivos criptografados. Por exemplo, o arquivo init do emacs inclui: (load "segredos.el.gpg"), que simplesmente funciona - solicitando a senha nas raras ocasiões em que inicio o editor. Eu não me preocupo com alguém quebrando a criptografia.
Você não deve distribuir essa chave com seu aplicativo ou armazená-lo no repositório do código-fonte. Esta pergunta está perguntando como fazer isso, e isso não é o que normalmente é feito.
Para Android / iPhone, o dispositivo deve solicitar a KEY do seu próprio serviço da Web quando o aplicativo for executado pela primeira vez. A chave é então armazenada em um local seguro. A chave deve ser alterada ou revogada pelo editor. Seu serviço da web pode publicar uma nova chave.
Os clientes que usam uma licença do seu software precisarão inserir a chave manualmente ao configurar o software pela primeira vez. Você pode dar a todos a mesma chave, chaves diferentes ou eles próprios.
Você armazena seu código-fonte em um repositório público, mas não na KEY. Na configuração do arquivo, você adiciona as linhas * chave de lugar aqui * . Quando um desenvolvedor usa seu código-fonte, ele faz uma cópia do arquivo sample.cfg e adiciona sua própria chave.
Você não mantém seu arquivo config.cfg usado para desenvolvimento ou produção no repositório.
Acho que esse é um problema que todos tiveram problemas em algum momento.
Aqui está um fluxo de trabalho que usei, que pode funcionar para você. Ele usa .gitignore com uma torção:
Agora, você pode clonar o repositório de configuração em qualquer sistema de desenvolvimento e implantação. Basta executar o script para copiar os arquivos para a pasta correta e pronto.
Você ainda recebe todos os doces do GitHub, compartilha seu código com o mundo e os dados confidenciais nunca estão no repositório principal, para que eles não sejam públicos. Eles ainda são apenas uma atração e uma cópia de qualquer sistema de implantação.
Eu uso uma caixa de 15 $ / ano para o servidor git privado, mas você também pode configurar uma em casa, de acordo com o requisito do cheapskate; -)
PS: Você também pode usar um submódulo git ( link ), mas eu sempre esqueço os comandos, então quick & regras sujas!
Use criptografia, mas forneça uma chave mestra na inicialização, como uma senha no console, em um arquivo que apenas o usuário do processo possa ler ou em um armazenamento de chaves fornecido pelo sistema, como o keychain do Mac OS ou o keystore do Windows.
Para uma entrega contínua, você precisará de várias chaves gravadas em algum lugar. A configuração deve ser demarcada do código, mas faz muito sentido mantê-la sob controle de revisão.
3 Estratégias, ainda não mencionadas (?)
No check-in ou em uma pré-verificação do VCS no gancho
Estratégias já mencionadas
Mantenha informações privadas fora do seu controle de origem. Crie um padrão não carregado para distribuição e faça com que seu VCS ignore o real. Seu processo de instalação (manual, configure / build ou wizard) deve manipular a criação e o preenchimento do novo arquivo. Como opção, modifique as permissões no arquivo para garantir que apenas o usuário necessário (servidor da Web?) Possa lê-lo.
Benefícios:
Se você já estiver fazendo isso e estiver verificando isso acidentalmente, adicione-o ao .gitignore do seu projeto. Isso tornará impossível fazer novamente.
Existem muitos hosts Git gratuitos que fornecem repositórios privados. Embora você nunca deva versionar suas credenciais, você pode ser barato e ter repositórios privados também. ^ _ ^
Em vez de ter a chave OAuth armazenada como dados brutos em qualquer lugar, por que não executar a cadeia por meio de algum algoritmo de criptografia e armazená-la como um hash salgado? Em seguida, use um arquivo de configuração para restaurá-lo em tempo de execução. Dessa forma, a chave não é armazenada em nenhum lugar, seja armazenada em uma caixa de desenvolvimento ou no próprio servidor.
Você pode até mesmo criar uma API para que seu servidor gere automaticamente uma nova chave de API com salgados e hash por solicitação, assim nem sua equipe poderá ver a origem do OAuth.
Editar: Talvez tente a Biblioteca de criptografia de Javascript da Stanford , ela permite uma criptografia / descriptografia simétrica bastante segura.