Sicurezza password: crittografia sale [duplicato]

Question

Sicurezza password: crittografia sale [duplicato]

#1 da (0 voti)
#2 da (0 voti)
#3 da (-1 voti)

2

Sono nuovo alla sicurezza e sto cercando di capire perché crittografare o nascondere un sale non è considerato utile. Ho letto il precedente post link sul perché nascondere o crittografare sale non è necessario ma la risposta è stata basata sul presupposto

If someone has access to your database, then they have access to the encrypted salts, and they probably have access to your code as well

Domanda

Solo perché un utente malintenzionato ha accesso al tuo database perché dovremmo assumere che abbia accesso al codice che interagisce con esso? Ad esempio, hai le tue password salate su un server MySQL su una macchina insieme ai sali crittografati. E tu hai la chiave per decrittografare i sali o qualche intricata logica di crittografia / decrittografia su un server web su una macchina separata. Un utente malintenzionato accede al database tramite SQL injection o altri mezzi. La crittografia e l'architettura distribuita non hanno salvato il giorno qui?

encryption hash salt

posta Usman Mutawakil 24.10.2012 - 17:53

fonte

3 risposte

Leggi altre domande sui tag encryption hash salt

Cosa succederà al mio PC Windows se visito un sito da una rete contrassegnata come malevola da google safebrowsing [closed] Codice dannoso nell'immagine. Dannoso?

score 0 · Answer 1

Sentirai diversi argomenti qui ma, alla fine della giornata, si tratta di come il tuo sistema funziona nel mondo reale.

È certamente possibile creare un sistema in cui la compromissione del livello del database non comprometta il livello dell'applicazione. Potresti immaginare l'indurimento contro cose come:

L'iniezione di dati arbitrari dal livello db non causa un problema di sicurezza nel front-end (cioè presuppone che recuperi dati non validi)
L'accesso fisico del livello DB non implica l'accesso fisico del livello applicazione.
I servizi di infrastruttura (credenziali di amministrazione, servizi di condivisione per cose come la gestione delle patch, ecc.) sono isolati in modo tale che non ci sia modo di esplorare l'isola tra loro.
La possibilità di inviare codice al livello db non implica la possibilità di inviare codice al livello dell'app.

... e così via.

Quindi sì, potrebbe essere fatto. Pragmaticamente, pochissime app funzionano in questo modo. Ho visto pochissimi nella mia carriera che potrebbero onestamente dire di aver raggiunto questo obiettivo.

IMO, questo è il motivo per cui le persone tendono a non considerarlo estremamente utile, poiché solo poche app sono in grado di fare questo tipo di richiesta di sicurezza.

score 0 · Answer 2

La crittografia dei sali non è molto utile in quanto è necessario memorizzare la chiave da qualche parte . Il più delle volte la chiave (o l'accesso alla chiave) può essere recuperata dal codice. In generale, ogni volta che si pensa a un protocollo utilizzando la crittografia, è necessario specificare come accedere ai tasti. Se non hai una risposta diretta, probabilmente stai per riprogettarlo.

Invece potresti ricavare il sale da un segreto memorizzato nel codice e una parte puramente casuale memorizzata nel database. Poiché non esiste un limite di dimensioni per un sale, è sufficiente concatenare le parti per ottenere il sale pieno. Questo può essere utile in quanto l'attaccante deve ora accedere anche al codice. Naturalmente, il codice non dovrebbe essere disponibile per l'attaccante. Il motivo per cui questo non è distribuito molto è che la maggior parte delle volte l'accesso al database equivale all'accesso al codice.

score -1 · Answer 3

Se l'utente malintenzionato trova le password (e i sali) utilizzando una vulnerabilità di SQL injection, ha solo accesso alle informazioni a cui ha accesso il database. In questo caso non importa se il codice si trova sulla stessa macchina del database, dal momento che il database stesso di solito non può accedere al codice che si connette ad esso.

La situazione è diversa quando l'attaccante ha ottenuto l'accesso alla macchina che esegue il database, in questo caso sarà probabilmente in grado di accedere sia al database che al codice (se il codice si trova sulla stessa macchina).

Quindi, se il server web e il database vengono eseguiti su macchine separate e l'utente malintenzionato ha accesso solo attraverso una vulnerabilità di SQL injection, sarebbe davvero molto difficile craccare quelle password.