L'offuscamento di un modello di sicurezza ha posto nella sicurezza della password?

Question

Quando si tratta di sicurezza delle password ci sono cose su cui le persone sono d'accordo, come la memorizzazione di hash salati di password, che fornisce una difesa statistica contro un modello e dati compromessi.

Ciò che alcuni non sembrano concordare sono cosa fare con i sali. Ci sono un numero infinito di tecniche che puoi fare per cercare di proteggere anche i sali, ma molti esperti suggeriranno che sono solo un'inutile offuscamento del modello di sicurezza, e che nel tempo il modello verrà esposto, e mi trovo in disaccordo con questo, ma potrei non capire l'altro punto di vista.

Quello che non capisco è se il tuo modello è compromesso, perché dovresti assumere un compromesso completo invece di un parziale? Se il tuo modello di sicurezza è distribuito su diversi pezzi di infrastruttura che non sono ugualmente protetti, un compromesso parziale potrebbe non essere nemmeno un problema. (Se fai qualcosa come, ad esempio, cripta il sale e recuperi la chiave di crittografia da un ambiente altamente protetto che è meno probabile che venga compromessa)

Suppongo che un compromesso non sia sempre al 100% qui . Non ho mai avuto un sistema hackerato o non ho mai violato per non avere il quadro completo.

Answer 1

La grande differenza tra l'offuscamento e la crittografia è che ciò che è offuscato può essere chiarito senza la necessità di nulla al di là delle informazioni offuscato - fino a quando si può capire il tipo di dati che si sta guardando, allora si può trova un modo per chiarirlo.

crittografia, nel frattempo, può essere decifrato solo con il/password/cracking strumento chiave giusta. dati crittografati senza queste cose è molto sicuro.

conseguenza offuscamento può al massimo rallentare un attaccante determinato, anche se potrebbe scoraggiare un determinato meno uno.Ci sono molte cose più facili e più gestibili che puoi fare intorno alla sicurezza del tuo sistema e dei tuoi server per renderli più duri contro gli aggressori meno determinati, quindi a mio parere il costo dell'offuscamento in termini di lavoro aggiuntivo per te e per i tuoi sistemi è raramente giustificato.

Assumere un compromesso non è al 100% quando si verifica uno sforzo molto rischioso, poiché ciò che si sta assumendo in realtà è che si è più intelligenti e più consapevoli del proprio sistema rispetto al proprio aggressore. Potresti avere ragione, ma se si si assume e si ha torto, allora si hanno davvero grossi problemi. Devi dimostrarlo e, dato il problema di provare un risultato negativo, è più sicuro comportarti come se fossi stato completamente compromesso quando si verifica un compromesso e per progettare i tuoi sistemi in modo che fossero il più sicuri possibile anche nella situazione in cui un totale compromesso si è verificato.

Answer 2

La sicurezza attraverso l'oscurità è, nel migliore dei casi, un azzardo. Paga per immagazzinare il sale da qualche altra parte? Probabilmente. Ma devi considerare il costo rispetto alla ricompensa quando inizi a entrare in questi setup di sicurezza multi-step. Direi che se la tua applicazione lo richiede, lo saprai. In caso contrario, l'aggiunta di ulteriori passaggi nell'applicazione al fine di avere una sicurezza superintensa può darti solo mal di testa quando le cose vanno male. Non tutti hanno bisogno della sicurezza a livello NASA per i loro sistemi. Questo non vuol dire che la sicurezza non sia importante. È solo che devi temprarlo nel tuo ambiente attuale.

Answer 3

se il tuo modello è compromesso, perché dovresti assumere un completo compromesso invece di un parziale?

Si dovrebbe sempre assumere il caso peggiore in sicurezza. Questo è l'approccio più sicuro.

un compromesso parziale potrebbe anche non essere un problema

Forse. Ma sei proprio sicuro?
Nel vostro OP si sta basando la sua analisi su troppe supposizioni. Forse in una configurazione molto specifica la tua valutazione che un compromesso parziale potrebbe non essere un problema potrebbe essere giustificabile.
Ma poi di nuovo si assume che l'attaccante non è abbastanza buono per trovare un buco.
Non basare il modello di sicurezza su ipotesi.