È sicuro archiviare le password nel codice sorgente dell'applicazione Web?

Question

Quindi ho un'applicazione web che si integra con molte altre API e servizi che richiedono l'autenticazione. La mia domanda è, è sicuro memorizzare le credenziali di autenticazione in testo normale nel mio codice sorgente? Cosa posso fare per memorizzare queste credenziali in modo sicuro?

Penso che questo sia un problema comune, quindi mi piacerebbe vedere una soluzione che protegga le credenziali nelle risposte.

In risposta a commentare: Mi capita spesso di uso PHP, Java e RoR

mi piacerebbe vedere alcune più voti per una risposta su questa domanda.

Answer 1

Sembra la risposta è la seguente:

1. Non inserire credenziali in codice sorgente, ma ...
2. Mettere le credenziali in un file di configurazione di log
3. Sanitize file
4. Set corretta autorizzazioni/proprietà su configs

Probabilmente più a seconda della piattaforma ...

Answer 2

Non è raccomandato.

Un encrypted web.config sarebbe un luogo più adatto (ma nota non può essere utilizzato con una web farm)

Answer 3

No, non lo è.

Inoltre, è possibile cambiare la password un giorno e probabilmente cambiare il codice sorgente potrebbe non essere l'opzione migliore.

Answer 4

No. A volte è inevitabile. Un approccio migliore consiste nell'avere un'architettura configurata in cui il servizio si fida implicitamente del codice in esecuzione in base a un altro trust. (Come fidarsi della macchina il codice è in esecuzione, o confidando l'application server che esegue il software)

Se nessuno di questi sono disponibili, sarebbe perfettamente accettabile per scrivere il proprio meccanismo di fiducia, anche se vorrei tenere è completamente separato dal codice dell'applicazione. Inoltre, consiglierei di cercare modi per tenere le password fuori dalla portata dei predatori, anche quando sono archiviate su una macchina locale - ricordando che non è possibile proteggere nulla se qualcuno ha il controllo della macchina fisica su cui si trova.

Answer 5

L'unico motivo per NON memorizzare il PW nel codice è semplicemente a causa del problema di configurazione (ad esempio, è necessario modificare la password e non si desidera ricostruire/compilare l'applicazione).

Ma la fonte è un luogo "sicuro" per contenuti "sensibili alla sicurezza" (come password, chiavi, algoritmi). Ovviamente è.

Ovviamente le informazioni sensibili per la sicurezza devono essere adeguatamente protette, ma questa è una verità di base indipendentemente dal file utilizzato. Che si tratti di un file di configurazione, di un'impostazione di registro o di un file .java o .class.

Da un punto di vista dell'architettura, è una cattiva idea per la ragione sopra menzionata, proprio come non dovresti "hardcoded" qualsiasi dipendenza "esterna" nel tuo codice se puoi evitarlo.

Ma i dati sensibili sono dati sensibili. Incorporare un PW in un file di codice sorgente rende quel file più sensibile di altri file di codice sorgente, e se questo è il tuo esercizio, considererei tutto il codice sorgente sensibile come la password.

Answer 6

Ecco cosa facciamo con le nostre password.

$db['hostname'] = 'somehost.com' 
$db['port'] = 1234; 

$config = array(); 
include '/etc/webapp/db/config.php'; 

$db['username'] = $config['db']['username']; 
$db['password'] = $config['db']['password']; 

Nessuno ma l'utente ha accesso a server web /etc/webapp/db/config.php, in questo modo si protegge il nome utente e la password da parte degli sviluppatori.

Answer 7

Se si controlla il server Web e lo si mantiene per gli aggiornamenti di sicurezza, quindi nel sorgente (preferibilmente in un modulo di configurazione) o in un file di configurazione che l'origine utilizza è probabilmente il migliore.

Se non si controlla il server Web (ad esempio, si è su un server condiviso o addirittura dedicato fornito da una società di hosting), la crittografia non sarà di grande aiuto; se l'applicazione può decrittografare le credenziali su un determinato host, l'host può essere utilizzato per decrittografare le credenziali senza il tuo intervento (pensa al root o all'amministratore guardando il codice sorgente e adattare la routine di decrittografia in modo che possa essere usata per leggere il configurazione). Questa è ancora più una possibilità se si utilizza codice gestito non offuscato (ad es. JVM o .NET) o un linguaggio di scripting Web che risiede in chiaro sul server (come PHP).

Come di solito, c'è un compromesso tra sicurezza e accessibilità. Penserei a quali minacce stai cercando di evitare e trovare un modo per proteggermi dalle situazioni di cui hai bisogno. Se stai lavorando con dati che devono essere protetti, dovresti probabilmente redigere il database abbastanza regolarmente e spostare i dati offline su un server database protetto e ben protetto non appena diventa obsoleto sul sito. Ciò includerebbe dati come numeri di previdenza sociale, informazioni di fatturazione, ecc., Che possono essere referenziati. Ciò significherebbe anche che preferiresti controllare i server della tua rete che forniscono servizi di fatturazione o archiviazione sicura dei dati.

Answer 8

Preferisco tenerli in un file di configurazione separato, che si trova da qualche parte al di fuori della radice del documento del server web.

Sebbene questo non protegga da un utente malintenzionato che sovrascrive il mio codice in modo che possa essere forzato a dirgli la password, ha comunque un vantaggio rispetto al mettere le password direttamente nel codice (o in qualsiasi altro web -accessible file) in quanto elimina la preoccupazione su una errata configurazione del server Web (o bug/exploit) che consente a un utente malintenzionato di scaricare direttamente il file contenente la password.

Answer 9

Nessuno sembra aver ancora menzionato hashing - con un algoritmo hash forte (ad esempio SHA-2 e non MD5), dovrebbe essere molto più sicuro.

Answer 10

Un approccio è quello di crittografare le password prima di mettere la password nel config.web

Answer 11

sto scrivendo questo per il servizio di web app che riceve la password, non cliente: se si salva hash passsword nel codice sorgente qualcuno che vede il codice sorgente non sarà in grado di aiutare se stesso con quell'hash. Il programma riceverà una password semplice e lo cancellerà e confronterà entrambi gli hash. Ecco perché salviamo le password con hash nei database, non in testo semplice. Perché non possono essere invertiti se qualcuno, ad esempio, ruba db o lo visualizza per scopi dannosi, non otterrà tutte le password degli utenti, solo gli hash che sono piuttosto inutili per lui.

L'hashing è un processo a 1 via: produce lo stesso valore dalla stessa origine ma non è possibile calcolare il valore sorgente dall'hash.

Memorizzazione sul client: quando l'utente inserisce il pass u salvarlo in db/file in testo in chiaro, forse offuscare un po 'ma non molto da fare per impedire a qualcuno che ottiene una sospensione di quel computer di ottenere quella password.