Come proteggere le password quando il sito è opensource [duplicato]

Una corretta implementazione crittografica non si basa sull'oscurità. Dovrebbe continuare anche quando sono noti i metodi di hashing e / o di crittografia, purché la chiave (ad es .: password) sia ancora protetta.

Come altri hanno sottolineato, non dovresti usare un sale statico per il tuo database delle password. Ciò potrebbe quasi vanificare lo scopo di un salt, consentendo a un utente malintenzionato di calcolare preventivamente una tabella arcobaleno che sarà utile contro un numero elevato di password.

Invece, ogni password dovrebbe avere un sale unico che viene generato casualmente quando viene creato l'account. Il metodo per generare i sali e per l'hashing delle password potrebbe essere pubblico. I sali e gli hash delle password devono essere conservati in un database protetto.

Questa non è una panacea , comunque. È comunque necessario adottare misure adeguate per proteggere la riservatezza del database delle password. Naturalmente, se il tuo sito è vulnerabile all'iniezione SQL, il database delle password potrebbe essere preso. E poi, naturalmente, è solo una questione di tempo prima che tutte le password vengano violate indipendentemente dal meccanismo di salatura o di hashing.

Il sale unico per utente non impedisce completamente che la password venga compromessa. Si limita a ritardarlo aggiungendo un altro elemento al processo di cui un utente malintenzionato non avrà conoscenza anticipata. Confronta i seguenti scenari:

• Hash non salato: l'autore dell'attacco potrebbe già disporre di una tabella arcobaleno pre-calcolata per il tuo meccanismo di hashing e potrebbe avere tutte le password incrinate entro lo stesso giorno del recupero del database.
• Static salt (pubblico o privato): una volta noto il sale statico (tramite inclusione nel codice open source o compromissione del sistema), l'utente malintenzionato deve solo generare una tabella arcobaleno per rompere qualsiasi password nel tuo database. Non ho molta familiarità con il modo in cui vanno queste cose, ma sembra che potrebbe essere qualcosa che vale la pena aspettare se il database delle password di destinazione è abbastanza grande o protegge qualcosa di reale valore.
• Sale unico, memorizzato in modo sicuro: non ci si può aspettare che una quantità di pre-computazione funzioni efficacemente contro questo, a meno che l'attaccante non abbia un database incredibilmente grande contenente tabelle arcobaleno per tutti i possibili sali. In assenza di questo, l'utente malintenzionato dovrà forzare manualmente ciascuna password. Data una corretta implementazione crittografica, probabilmente ci vorrà più tempo di quanto l'aggressore, o qualcuno dei suoi prevedibili discendenti, possa permettersi.

C'è molta buona guida nelle risposte e nei commenti qui. Vi suggerisco caldamente di esaminarlo. Inoltre, ricorda la regola n. 1 di Crittografia: non eseguire il crypto.

Idealmente, dovresti generare un salt casuale per ogni account utente e memorizzare il sale nel database. Mentre il codice per generare i sali potrebbe essere pubblico, i sali stessi non dovrebbero.

La maggior parte dei framework web ha un modo standard e solitamente sicuro per la memorizzazione delle password, quindi la cosa migliore è ricercare prima di implementare qualcosa da zero.

Questo ti farà risparmiare non solo il tempo, ma molto probabilmente sarà più sicuro della tua implementazione, soprattutto se hai poca esperienza nella scrittura di codice specifico per la sicurezza.