Protezione degli hash delle password con stored procedure?

Question

Protezione degli hash delle password con stored procedure?

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

5

Stavo pensando alle recenti violazioni della sicurezza (apparentemente settimanali) che abbiamo visto dove sono stati trapelati milioni di hash delle password e mi chiedevo come si potrebbe proteggere il loro sito contro un dump della password, anche se un hacker ha trovato un'iniezione SQL vulnerabilità.

Cosa succede se l'utente che il sito Web utilizzava per accedere al database disponeva di autorizzazioni più limitate. Diciamo che su tutti i dati non critici l'utente ha le autorizzazioni complete come normale (CRUD). Ma cosa succede se l'utente è stato negato tutte le operazioni CRUD alla tabella che memorizzava gli hash di login, le domande di sicurezza, ecc. E poteva eseguire solo stored procedure su quella tabella. E diciamo che quelle stored procedure non hanno mai restituito gli hash delle password al livello dell'applicazione, ma piuttosto passeresti l'hash alla procedura e la procedura restituirebbe un valore booleano che indica se c'era una corrispondenza.

Mi sembra che questa configurazione eliminerebbe completamente la possibilità di un dump di hash della password tramite SQL injection. Questa configurazione fornisce ulteriore sicurezza, è consigliabile?

Aggiorna

Vedi questa domanda per maggiori dettagli:

Vale la pena dal punto di vista della sicurezza per limitare l'utente del server database per il sito Web ASP.NET alla sola esecuzione di EXECUTE sulle stored procedure?

sql-injection passwords password-management

posta John 10.05.2013 - 17:40

fonte

2 risposte

1

Un modo diverso di considerare il problema è che il database sarà compromesso. Se il database è compromesso e si ottiene la tabella delle password, come può ridurre il valore dell'attacco rendendo i dati privi di significato?

Per prima cosa, ovviamente, si desidera utilizzare un algoritmo di hashing crittografico strong ( bcrypt, scrypt, ecc. ). Si desidera utilizzare un sale casuale per ridurre la possibilità di utilizzare la tabella arcobaleno in modo efficace. Puoi anche utilizzare un meccanismo di peppering e utilizzare la separazione attraverso un altro server o modulo di sicurezza hardware (HSM) , senza il pepe, ottenere qualcosa di significativo dall'elenco hash sarà molto meno probabile. È possibile eseguire questa operazione in misura minore utilizzando un server bloccato con solo la tabella delle password presente, assicurando che ci sia una corretta crittografia e autenticazione tra il server richiedente e il server di verifica password.

risposta data 10.05.2013 - 19:08

fonte

Leggi altre domande sui tag sql-injection passwords password-management

Un paio di reindirizzamenti dopo aver fatto clic su un link, cosa stanno cercando? HMAC Qual è il modo sicuro per distribuire il segreto condiviso tra client e server?

score 3 · Accepted Answer

Lo schema che descrivi è simile nel concetto di creare un server di verifica password dedicato (server locale, non aperto al mondo in generale) con un proprio database completamente distinto per la memorizzazione di password con hash. Questo può funzionare. In realtà l'hai già sotto l'aspetto di "integrazione di sistema" quando gli account utente vengono mappati, ad esempio, su un server Active Directory o su account Unix locali.

L'utilizzo di una procedura memorizzata nel database per questo, fa affidamento sul database che impone un isolamento appropriato: una scommessa alquanto rischiosa, poiché si prevede una situazione in cui l'autore dell'attacco possa includere le proprie istruzioni SQL.