Strategia per mantenere informazioni segrete come le chiavi API fuori dal controllo del codice sorgente?

Sto lavorando su un sito Web che consentirà agli utenti di accedere utilizzando le credenziali OAuth come Twitter, Google, ecc. Per fare questo, devo registrarmi con questi vari provider e ottenere una chiave API super segreta che ho per proteggere con impegni contro varie parti del corpo. Se la mia chiave viene strappata, la parte viene strappata.

La chiave API deve viaggiare con la mia fonte, poiché viene utilizzata in fase di esecuzione per eseguire richieste di autenticazione. Nel mio caso, la chiave deve esistere all'interno dell'applicazione in un file di configurazione o all'interno del codice stesso. Questo non è un problema quando creo e pubblico da una singola macchina. Tuttavia, quando gettiamo il controllo del codice sorgente nel mix, le cose diventano più complicate.

Dato che sono un bastardo economico, preferirei di gran lunga utilizzare i servizi di controllo del codice sorgente gratuiti come TFS nel cloud o GitHub. Questo mi lascia con un leggero enigma:

Come posso mantenere intatto il mio corpo quando le mie chiavi API sono nel mio codice e il mio codice è disponibile in un repository pubblico?

Posso pensare a diversi modi per gestirlo, ma nessuno di loro è così soddisfacente.

• Potrei rimuovere tutte le informazioni private dal codice e modificarle nuovamente dopo la distribuzione. Questo sarebbe un grave dolore da implementare (non descriverò in dettaglio i molti modi) e non è un'opzione.
• Potrei crittografarlo. Ma come devo decifrarlo, chiunque abbia la fonte potrebbe capire come farlo. Inutile.
• Potrei pagare per il controllo della fonte privata. LOL j / k spendi soldi? Per favore.
• Potrei usare le funzionalità del linguaggio per separare le informazioni sensibili dal resto della mia fonte e quindi mantenerle dal controllo della fonte. Questo è quello che sto facendo ora, ma potrebbe essere facilmente rovinato controllando erroneamente il file segreto.

Sto davvero cercando un modo garantito per assicurarmi di non condividere i miei privati ​​con il mondo (tranne su Snapchat) che funzioneranno senza problemi attraverso lo sviluppo, il debug e l'implementazione e che siano anche infallibili. Questo è completamente irrealistico. Quindi cosa realisticamente posso fare?

_{Dettagli tecnici: VS2012, C # 4.5, il controllo del codice sorgente sarà TF service o GitHub. Attualmente si utilizza una classe parziale per dividere le chiavi sensibili in un file .cs separato che non verrà aggiunto al controllo del codice sorgente. Penso che GitHub possa avere il vantaggio in quanto .gitignore potrebbe essere usato per garantire che il file di classe parziale non sia archiviato, ma l'ho rovinato prima. Spero in un "oh, problema comune, ecco come lo fai", ma potrei accontentarmi di "che non fa schifo quanto potrebbe avere",: /}

Non inserire le tue informazioni segrete nel tuo codice. Inseriscilo in un file di configurazione che viene letto dal tuo codice all'avvio. I file di configurazione non dovrebbero essere messi sul controllo versione, a meno che non siano "valori predefiniti di fabbrica" ​​e quindi non dovrebbero avere alcuna informazione privata.

Vedi anche la domanda Controllo della versione e file di configurazione personale per come farlo bene.

È possibile inserire tutte le chiavi private / protette come variabili di ambiente di sistema. Il tuo file di configurazione sarà simile al seguente:

private.key=#{systemEnvironment['PRIVATE_KEY']}

Questo è il modo in cui gestiamo questi casi e niente va nel codice. Funziona molto bene combinato con diversi file di proprietà e profili. Utilizziamo file di proprietà diversi per ambienti diversi. Nel nostro ambiente di sviluppo locale inseriamo le chiavi di sviluppo nei file delle proprietà per semplificare l'installazione locale:

private.key=A_DEVELOPMENT_LONG_KEY

Modo Git puro

• .gitignore file incluso con dati privati
• Utilizzare una filiale locale, in cui si sostituisce TEMPLATEconDATA
• Utilizza i filtri di sfumatura / pulizia, in cui lo script del filtro (locale) esegue la sostituzione bidirezionale TEMPLATE<->DATA

Modo mercuriale

• Patch MQ sopra il codice fittizio, che sostituisce TEMPLATEcon DATA(i changeset sono pubblici, la patch è privata)
• Estensione delle parole chiave con parole chiave appositamente progettate (espanse solo nella directory di lavoro )

Modo agnostico SCM

• Sostituzione delle parole chiave come parte del processo di compilazione / distribuzione

Ho messo segreti in file crittografati che poi commetto. La passphrase viene fornita all'avvio del sistema oppure viene archiviata in un piccolo file che non eseguo il commit. È bello che Emacs gestirà allegramente questi file crittografati. Ad esempio, il file emacs init include: (carica "secrets.el.gpg"), che funziona e mi chiede la password in quelle rare occasioni quando avvio l'editor. Non mi preoccupo che qualcuno rompa la crittografia.

Questo è molto specifico per Android / Gradle ma potresti definire le chiavi nel tuo gradle.propertiesfile globale che si trova in user home/.gradle/. Ciò è utile anche in quanto è possibile utilizzare proprietà diverse a seconda di buildType o flavour, ad esempio API per sviluppo e diverso per rilascio.

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"
            }
        }

Nel codice faresti riferimento in questo modo

String myAPI = BuildConfig.GOOGLE_VERIFICATION_API_KEY;

Non dovresti distribuire quella chiave con la tua applicazione o archiviarla nel repository del codice sorgente. Questa domanda è chiedersi come farlo, e non è quello che si fa normalmente.

Applicazione Web mobile

Per Android / iPhone il dispositivo deve richiedere il TASTO al proprio servizio Web al primo avvio dell'app. La chiave viene quindi memorizzata in un luogo sicuro. La chiave deve essere modificata o revocata dall'editore. Il tuo servizio web può pubblicare una nuova chiave.

Applicazione Web ospitata

I clienti che utilizzano una licenza del proprio software dovranno inserire manualmente la chiave al momento della prima configurazione del software. Puoi dare a tutti la stessa chiave, chiavi diverse o ottengono le proprie.

Codice sorgente pubblicato

Memorizzi il tuo codice sorgente in un repository pubblico ma non KEY. Nella configurazione del file aggiungi le righe * inserisci la chiave qui * . Quando uno sviluppatore utilizza il codice sorgente, crea una copia del sample.cfgfile e aggiunge la propria chiave.

Non conservare il config.cfgfile utilizzato per lo sviluppo o la produzione nel repository.

Utilizzare le variabili di ambiente per cose segrete che cambiano per ciascun server.

http://en.wikipedia.org/wiki/Environment_variable

Come usarli dipende dalla lingua.

Penso che questo sia un problema con cui tutti hanno avuto qualche problema ad un certo punto.

Ecco un flusso di lavoro che ho usato, che potrebbe funzionare per te. Usa .gitignore con una svolta:

1. Tutti i file di configurazione vanno in una cartella speciale (con file di configurazione di esempio - facoltativo)
2. Tutti i file di configurazione sono inclusi in .gitignore, in modo che non diventino pubblici
3. Imposta un server gitolite (o il tuo server git preferito) su una casella privata
4. Aggiungi un repository con tutti i file di configurazione nel server privato
5. Aggiungi uno script per copiare i file di configurazione nella cartella speciale nel repository principale (opzionale)

Ora puoi clonare il repository di configurazione su qualsiasi sistema di sviluppo e distribuzione. Basta eseguire lo script per copiare i file nella cartella corretta e il gioco è fatto.

Ricevi ancora tutte le caramelle GitHub, condividi il tuo codice con il mondo e i dati sensibili non sono mai nel repository principale, quindi non diventano pubblici. Sono ancora solo un tiro e una copia di distanza da qualsiasi sistema di distribuzione.

Uso una scatola da 15 $ / anno per il server privato git, ma puoi anche installarne uno a casa, secondo il requisito del cheapskate ;-)

PS: potresti anche usare un sottomodulo git ( http://git-scm.com/docs/git-submodule ), ma dimentico sempre i comandi, regole così veloci e sporche!

Utilizza la crittografia, ma fornisci una chiave master all'avvio, come password sulla console, in un file che solo l'utente del processo può leggere o da un archivio chiavi fornito dal sistema come il portachiavi Mac OS o l'archivio chiavi di Windows.

Per la consegna continua, ti consigliamo di registrare varie chiavi da qualche parte. La configurazione dovrebbe essere delimitata dal codice, ma ha molto senso tenerlo sotto controllo di revisione.

3 strategie, non ancora menzionate (?)

Al check-in o in un gancio di pre-check-in VCS

• cerca stringhe con elevata entropia, esempio -detect-secrets
• regex cerca modelli chiave API ben noti. Le chiavi AKIA * di AWS sono un esempio, git-secrets è uno strumento basato su questo. Inoltre, nomi di variabili come "password" con assegnazione costante.
• cerca segreti conosciuti, conosci i tuoi segreti, cercali nel testo. O usa uno strumento, ho scritto questa prova di concetto .

Strategie già menzionate

• memorizza nel file al di fuori dell'albero dei sorgenti
• averlo nell'albero dei sorgenti, ma di 'a VCS di ignorarlo
• le variabili di ambiente sono una variazione sulla memorizzazione dei dati all'esterno dell'albero di origine
• semplicemente non dare i preziosi segreti agli sviluppatori

Tieni le informazioni private fuori dal controllo del codice sorgente. Crea un valore predefinito non caricato per la distribuzione e fai in modo che il tuo VCS ignori quello reale. Il processo di installazione (manuale, configura / build o procedura guidata) dovrebbe gestire la creazione e il popolamento del nuovo file. Facoltativamente, modificare le autorizzazioni sul file per garantire che solo l'utente richiesto (server web?) Possa leggerlo.

Benefici:

• Non presuppone un'entità di sviluppo == entità di produzione
• Non presuppone che tutti i collaboratori / revisori del codice siano affidabili
• Prevenire errori facili tenendolo fuori dal controllo della versione
• Installazioni facili da automatizzare con configurazione personalizzata per QA / build

Se lo stai già facendo e lo accedi accidentalmente, aggiungilo a quello del tuo progetto .gitignore. Ciò renderà impossibile farlo di nuovo.

Ci sono molti host Git gratuiti in giro che forniscono repository privati. Anche se non dovresti mai versioni delle tue credenziali, puoi essere economico e avere anche repository privati. ^ _ ^

Invece di avere la chiave OAuth memorizzata come dati non elaborati ovunque, perché non eseguire la stringa tramite un algoritmo di crittografia e archiviarla come hash salato? Quindi utilizzare un file di configurazione per ripristinarlo in fase di esecuzione. In questo modo la chiave non viene archiviata da nessuna parte, sia che si trovi in ​​una casella di sviluppo, sia sul server stesso.

Puoi persino creare un'API in modo tale che il tuo server generi automaticamente una nuova chiave API salata e con hash su una base per richiesta, in questo modo nemmeno il tuo team può vedere l'origine OAuth.

Modifica: Forse prova la Stanford Javascript Crypto Library , consente una crittografia / decrittazione simmetrica abbastanza sicura.