L'invio di password in chiaro a un database SQL Server costituisce un rischio per la sicurezza?

SQL Server ha la possibilità di crittografare la connessione tra applicazione e database . Quando si esegue il server SQL in un ambiente non affidabile, si consiglia di abilitarlo. Quando lo fai, esegui l'hashing delle password prima di inviarle al database non è necessario se ti fidi dell'amministratore del database.

Inoltre, la maggior parte delle installazioni di server SQL avrà un server applicazioni in una DMZ e il server SQL nella LAN, il che significa che si opera in un ambiente fidato. A meno che tu non abbia uno standard di sicurezza molto elevato, non avere la crittografia non sarebbe un grosso rischio per la sicurezza.

Non fidarti di nessuno. Usa stringhe sicure per contenere password in chiaro e cancellarle immediatamente. Sono finiti i tempi in cui puoi sperare che il tuo sistema sia sicuro. Non è. È solo questione di tempo / denaro fino a quando un determinato attaccante può accedere al tuo sistema.

Anche quando il traffico viene crittografato con SSL / TLS posso creare diversi scenari, ognuno dei quali porta a perdite di password, ad esempio

• Il governo acquisisce il traffico SSL e "chiede gentilmente" che una chiave privata la decrittografi. È tutto in una rete privata? Sei sicuro che non sia stata configurata alcuna replica esterna al sito?
• La tua organizzazione installa hardware che esegue la decifratura SSL man-in-the-middle per annusare il traffico SSL che passa attraverso la sua rete. Improvvisamente più persone, hardware e software sono coinvolti: ti fidi di loro? Non è stato installato o forse non ancora?
• Il server che contiene le chiavi private SSL viene hackerato e la chiave è trapelata. In privato. Tranquillamente.
• Un dipendente insoddisfatto viene pagato per copiare la chiave privata e venderla al concorrente

Sì, ci sono una varietà di rischi o aumenti di rischio qui.

Prima di tutto, indipendentemente dal fatto che i tuoi DBA possano essere considerati attendibili, dovrebbero essere in grado di dire onestamente a qualsiasi auditor (o investigatore normativo o avvocato) che no, non è possibile che abbiano impersonato l'utente X, perché non sono mai stati , sempre in grado di vedere la password dell'utente X anche se lo desidera, e anche se ha usato la sua copia della chiave privata del server e uno sniffer di pacchetti.

In secondo luogo, se hai password di hashing sul server, dovresti:

• Leggi la canonica Come fare in modo sicuro le password di hash? risposta di Thomas Pornin, che si riduce a "Usa BCrypt , SCrypt o PBDF2 ".
  • Con un numero maggiore di iterazioni che puoi gestire con il carico massimo.
  • Con una lunghezza di uscita non più lunga della lunghezza di output primitiva di hashing di base.
• Poiché si tratta di SQL Server, consulta la mia risposta di implementazione PBKDF2 pura T-SQL .
  • Si noti che è terribilmente lento rispetto alle implementazioni reali, in particolare implementazioni di attacchi come oclHashcat.
• Vedi oclHashcat per le attuali velocità di attacco offline a più macchine e con più GPU. Questo è ciò che useranno aggressori, ricercatori e concorrenti della competizione cracking useranno dopo aver preso una copia delle password con hash da una qualche vulnerabilità front-end, o un laptop con un backup del database su di esso, o (scegli il tuo scenario preferito qui). li>
• Ti rendi conto, in base a quanto sopra, che qualunque sia l'applicazione, può utilizzare molti più cicli di BCrypt, SCrypt o PBKDF2 per eseguire l'hash della password rispetto al database di SQL Server per la stessa quantità di tempo di calcolo.
  • ed è quasi sempre più facile ed economico aggiungere più potenza front-end ridimensionando piuttosto che aggiungere più potenza a SQL Server.

Si noti che una varietà di implementazioni PBKDF2 si trovano in il mio repository Github , incluso una variante C # basata sul lavoro di Jither, che Jither ha rilasciato sotto la licenza MIT.

Quindi dipende dalla dignità di fiducia dell'ambiente. Se non hai fiducia in esso, forse un po 'di crittografia sarebbe buono. Inoltre, il set di configurazione di basso ramo dovrebbe probabilmente limitare solo gli host che richiedono la connettività SQL, anche se ci sono molti diversi motivi per cui vorresti aprirlo per accedere.

TLDR : purché la connessione di rete al DB sia sicura e fintanto che gli hash salati sono memorizzati nelle tabelle, la chiamata di una procedura memorizzata con una password in chiaro è valida. Penso che il tuo tempo e il tuo impegno siano spesi meglio proteggendo il database dall'accesso non autorizzato del tipo che consente di ottenere una traccia di chiamate di stored procedure.

In primo luogo, comprendo che lo scenario in questione è che un utente malintenzionato può recuperare la password in testo semplice esaminando i valori dei parametri passati alla stored procedure, uno dei quali è la password in chiaro, quindi utilizzare tale password per compromettere un account utente in la tua applicazione.

Se ciò è corretto, l'unica soluzione puramente tecnica che vedo è implementare uno schema PK nell'ambito della stored procedure, in modo che la password debba essere crittografata con la chiave pubblica della stored procedure, il testo cifrato passato nello stored procedura e il valore del parametro decrittografato dallo stesso proc memorizzato con una chiave privata prima di essere utilizzato. (O meglio, come TLS stesso, si può negoziare uno scambio Diffie-Hellman usando altri proc memorizzati e usare una chiave di sessione.) A meno che non si possa trovare qualche implementazione open-source di questo, che ci si fida e si usi, questo sarà un ascensore molto pesante. E ora devi proteggere quella chiave privata.

Ma pensa a cosa stai davvero cercando di proteggerti. In questo scenario, l'utente malintenzionato può leggere le chiamate della procedura memorizzata e ottenere i valori passati. Qualsiasi utente con questo privilegio ha anche accesso in lettura a qualsiasi chiave privata utilizzata o seleziona / inserisce / aggiorna l'accesso alle proprie tabelle? Se è così, anche se passi attraverso l'implementazione di PKI a livello di stored procedure, i tuoi sforzi vengono immediatamente sconfitti.

Permettetemi anche di rispondere in modo specifico all'idea di hashing della password, con un sale ovviamente, e passando il valore hash alla stored procedure. Se si esegue questa operazione, il valore hash è ora la password. Tutto ciò che un utente malintenzionato deve fare, se davvero è in grado di leggere i parametri memorizzati del proc, è ripetere questi parametri esattamente come li vede compromettere il sistema. In realtà non ha bisogno di invertire l'hash e imparare cosa sia la "semplice" password; il valore hash è la password in chiaro ora. Quindi questo schema non ha alcun effetto.