Ho ragione modificando l'algoritmo predefinito su un'app Web?

Question

Ho ragione modificando l'algoritmo predefinito su un'app Web?

#1 da (6 voti)

1

Numerosi clienti mi hanno detto che il mio suggerimento su come cambiare l'algoritmo su un'app Web non aumenta la sicurezza. Ho provato a ragionare che se i file non sono stati esposti, l'attaccante deve indovinare all'algoritmo.

Qualche giorno fa stavo valutando il sito di un amico e ho indicato alcune vulnerabilità SQLi. Non ho avuto alcun accesso ai file. Come sopra, il mio amico mi ha detto che ho sbagliato a suggerire un algoritmo diverso anche se è in grado di gestire i compromessi con un algoritmo diverso.

Il mio ragionamento con lui era che un utente malintenzionato non conosceva il tuo algoritmo, quindi hai escluso una minoranza di aggressori semplicemente cambiando algo. Se hanno usato uno strumento come hashcat e hanno provato a decifrare l'hash con un preset, non li portano da nessuna parte. Anche se si tratta di sicurezza attraverso l'oscurità, funziona in un modo che ti sei difeso solo un po 'se hai un altro SQLi.

Ha insistito per non cambiare l'algoritmo perché chiunque sfrutta il sito è una bandiera bianca automatica. Assume che se viene recuperato un hash, tutti si prenderanno il tempo di craccarlo.

L'hash predefinito è md5. Ho suggerito PBKDF2 o bcrypt.

Proprio come una doppia opinione: Chi, in teoria e in atto, è corretto in questa situazione?

È corretto che dovrebbe mettere una bandiera bianca se qualcuno recupera l'hash di un amministratore? Sarei corretto nel dire che questo è un uso pratico della sicurezza attraverso l'oscurità? ... O se non è affatto la sicurezza attraverso l'oscurità?

sql-injection hash

posta JAP 13.01.2014 - 16:20

fonte

1 risposta

Leggi altre domande sui tag sql-injection hash

Questo dimostra la necessità di un'autenticazione a due fattori? Iniezione SQL con istruzione "INSERT"

score 6 · Answer 1

Cambiare l'algoritmo "perché l'attaccante non lo saprà" è un motivo molto scarso per cambiare un algoritmo. Per cominciare, l'utente malintenzionato può dedurre che si utilizzerà un algoritmo per il quale esiste un supporto nel codice, che limita le possibili scelte, e l'algoritmo può quindi essere spesso disambiguato sulla base di ciò che può essere visto sull'output (se l'output è 160 bit, questo è SHA-1, non MD5).

Sarebbe una grave illusione che la modifica dell'algoritmo porti davvero, dal fatto che il ragionamento di "attaccante non lo indovina", aumenta significativamente la sicurezza. Gli algoritmi non possono essere considerati segreti, perché le informazioni sull'algoritmo si diffondono ovunque: nel codice, nel codice comportamento (ad es. Tempo di esecuzione), nella testa degli sviluppatori ... e nello spazio del possibile gli algoritmi sono piccoli.

Ora passare da MD5 a PBKDF2 o bcrypt è una idea molto buona . Non perché l'autore dell'attacco assuma che sia MD5 e "mai indovinare" che è stato usato bcrypt; infatti, l'output di bcrypt tende ad essere ovvio sotto questo aspetto (hanno una codifica specifica di output + salt come una stringa che indica chiaramente che bcrypt è stato usato). Ma perché un MD5 di base è un modo terribile per le password di hash. Se desideri archiviare le password con hash, almeno esegui correttamente , che significa, in questo momento, PBKDF2 o bcrypt.