Diverse API (come Facebook o Amazon S3) richiedono una chiave segreta per autenticare l'accesso al servizio. Ovviamente, se il codice sorgente è pubblico, la chiave non dovrebbe essere nella fonte! Che ne dici di un sito web chiuso?
La mia pratica raccomandata è di non mettere le chiavi nel codice sorgente. L'opzione migliore per la tua situazione particolare dipende da alcuni dettagli.
Generalmente, la preferenza è di mantenere la chiave in un file separato che non è memorizzato nel repository del codice sorgente. Puoi anche avere una cartella secrets se ti piace e memorizzare le chiavi lì. Generalmente si assegnano le chiavi agli utenti appropriati: coloro che devono creare build o build finali in grado di testare la funzionalità che richiede la chiave.
Se hai persone che lavorano con il tuo codice sorgente che non sono completamente fidate con le chiavi (ad esempio, se i programmatori esternalizzati aggiungono al tuo codice) puoi configurare il codice per operare in modalità fallback se non ha i segreti Questo può o non può essere appropriato alla tua situazione.
Vorrei sottolineare che non esiste un modo valido per mantenere la chiave segreta se si distribuisce il codice oggetto. Questo metodo dovrebbe essere utilizzato solo in programmi che non sono solo closed source ma closed distribution. Se devi fare qualche offuscamento, non solo la chiave ma l'obfuscator dovrebbe essere nella directory secrets e la sua distribuzione limitata.
Il ciclo di vita del codice sorgente e la gestione delle chiavi potrebbero essere in conflitto. Ad esempio, potresti (dovresti) usare uno strumento di versionamento come Subversion per memorizzare le successive modifiche eseguite sul codice sorgente; se inserisci la chiave segreta, verrà memorizzata anche la chiave. In sostanza, se si memorizza la chiave nel codice sorgente del sito Web, è necessario rendere il codice sorgente esattamente segreto quanto la chiave; una chiave è piccola e, come tale, è ritenuto più facile mantenere il segreto (ad esempio è possibile scrivere una chiave sulla carta e conservare la carta in una cassastrong, perché la sua digitazione può essere eseguita in pochi secondi), mentre la fonte il codice per un intero sito è molto più ingombrante. Se memorizzi la chiave nel codice sorgente, all'improvviso, ottenere una copia del codice sorgente del sito Web diventa un obiettivo molto prezioso per gli aggressori.
Se con "nel codice sorgente" intendi come parte del codice logico in un file, sarei d'accordo con gli altri: non farlo. Parlando per PHP, parti del tuo codice potrebbero essere mostrate nei rapporti di debug, probabilmente anche sul sito web (almeno nella visualizzazione dev).
Le altre due opzioni sono - un file di configurazione dedicato nel linguaggio di programmazione che stai utilizzando per il progetto. Potresti quindi includerlo dove ti serve o meglio usare qualcosa come il modello di progettazione del Registro. Il vantaggio è che il file viene interpretato quando chiamato direttamente e non produrrà i segreti. - un file conif dedicato al testo semplice. Questo deve essere protetto dalle chiamate dirette, ad esempio posizionandolo all'esterno di DocumentRoot.
Per lo più prendo quest'ultimo e generalmente metto un controller di frontend solo in DocRoot e lasciamo libs, configs, la maggior parte dei dati ecc. in parallelo.
La prima risposta spuntata nella mia testa è NO, non è una pratica corretta.
Però, a volte le persone dovrebbero seguire pratiche che non sono assolutamente perfette, ma richieste per il rilascio anticipato, per il requisito di chiusura del cliente o per un altro miSf (H) IT.
Quindi, se in tali situazioni, prova a prendere in considerazione alcuni punti come:
NON come PLAINTEXT il più importante
Non incorporarlo nel codice sorgente ovunque
crea un file di configurazione con i suoi dettagli e leggi da esso
assegna il permesso al file di configurazione di essere "di sola lettura" e solo dall'utente richiesto
Dipende. Chi ha accesso alle fonti / ai binari? Se riesci a proteggere sufficientemente l'accesso alle fonti, non c'è molto errore nell'avere la chiave nelle fonti da una prospettiva di sicurezza. Vorrei ancora sconsigliarlo. In primo luogo, tale approccio riduce la manutenibilità e, in secondo luogo, è possibile avere keystore specifici dell'utente sulla maggior parte dei sistemi che consentono di leggere tali chiavi da contenitori crittografici. In questo modo puoi proteggere ulteriormente l'accesso a tali chiavi e solo determinati utenti o gruppi possono recuperarle.
Ma se qualcuno esperto lancia un attacco dedicato e ha accesso root o anche accesso fisico alla macchina, allora sarà in grado di recuperare la password prima o poi. Così alcune persone hanno iniziato a crittografare tali routine con una chiave che deve essere ottenuta da un posto diverso durante l'avvio / l'esecuzione dell'applicazione. Questo può introdurre una seconda linea di difesa in quanto è possibile negare l'accesso per le applicazioni che non sono attendibili da una posizione diversa. Ma per la maggior parte delle applicazioni, ritengo che sia eccessivo.
Leggi altre domande sui tag authentication web-application