Controllare la manomissione del database

Perché salt ?

Nella mia mente, un sale è un piccolo supplemento per rendere più sapore. Normalmente, il sale è memorizzato nello stesso database rispetto al valore dell'hashed stesso.

L'aggiunta di un sale non aggiungerà sicurezza e non ridurrà al minimo il rischio di collisione. Se le collisioni sono possibili, saranno solo spostate ! Non pensare di risarcire il metodo hash sbagliato aggiungendo sale!

Se combini i primi 3 campi con tale secret phrase , sarai in grado di effettuare la verifica. Ma la possibilità di ottenere collisioni è chiaramente correlata al numero di file. Se il tuo obiettivo è quello di rendere difficile a un hacker di costruire un hash corretto, devi usare una frase segreta . Principalmente se stai aspettando molte righe nel tuo database!

Più database sei più grande è facile craccarli da forza bruta ! Quindi attenzione al metodo hash!

Altri modi

Utilizzo della funzione del server, come mysql binlogs per segnalare ogni operazione in un server di backup protetto (potrebbe essere un NAS in solo scrittura ).

Un modo più semplice potrebbe essere quello di rendere sicuri backup differenziali e osservare i pacchetti di transazioni diffs (la procedura di backup potrebbe essere attivata molto da vicino se l'intero database potrebbe rimanere nella RAM).

O infine, potresti aggiungere trigger al motore di database per essere avvisati e controllare le alterazioni sui file di database, usando strumenti di sistema come FAM ou Inotify .

Oltre all'utilizzo di HMAC per verificare l'integrità delle righe, utilizzare il sistema di autorizzazione DB per impedire UPDATE e DELETE delle righe in questa tabella / db. Consenti solo INSERT e SELECT.

La memorizzazione degli hash nella stessa tabella dei dati consente solo a un hacker di vedere che è in atto un meccanismo anti-manomissione. Se un utente malintenzionato ottiene l'accesso alle informazioni della tabella, è probabile che capisca che hai qualcosa in corso e agisci di conseguenza. L'uso degli hash non è una cattiva idea, tuttavia è necessario memorizzarli in un database separato su un sistema separato poiché non è necessario fornire informazioni. Per quanto riguarda il sale (più di una chiave in realtà), non sono sicuro di cosa avessi in mente, ma penso che sia una buona idea come se avessi gli hash su un DB separato il sale è un altro strato di protezione antimanomissione: se l'attaccante rileva che hai un DB di hash che dovranno ancora capire cosa sia il sale (IV, chiave, qualunque cosa sia).

Non hai menzionato chi stai proteggendo il tuo database e quali sono le loro capacità. Se il tuo piano di hashing è adeguato dipende dal livello di accesso dell'attaccante.

1. L'utente malintenzionato ha un account "normale" sul database . Questo potrebbe essere attraverso un'iniezione SQL. @ Il suggerimento di Matrix di consentire solo i privilegi INSERT e SELECT funziona correttamente per questo caso, anche se ciò significa che l'app non può DELETE o UPDATE o REPLACE o TRUNCATE o DROP o ALTER o molti altri comandi.
2. L'utente malintenzionato ha un account di superutente nel database . Poiché ora l'utente malintenzionato ha i privilegi UPDATE, la segretezza dell'algoritmo / chiave / sale è l'unica cosa che gli impedisce di ricalcolare l'hash quando cambia gli altri valori. Ovviamente, ciò significa che le chiavi non possono essere memorizzate nel database. Possono essere archiviati in un altro database o sul server delle applicazioni.
3. L'utente malintenzionato ha un account shell sul server delle applicazioni . Ciò potrebbe verificarsi attraverso una vulnerabilità legata al codice nell'applicazione. In questo caso, la chiave segreta o il sale o l'algoritmo non sono più segreti. Ha accesso al codice dell'applicazione e ovunque sia possibile memorizzare le chiavi segrete, l'applicazione deve essere in grado di accedervi, in modo che anche l'autore dell'attacco sia in grado di farlo.

Il modo in cui raggiungere il tuo obiettivo è spedire immediatamente un log di tutte le modifiche dal database e su un server di registrazione dedicato. Se stiamo parlando di MySQL, l'impostazione di un server di replica farà il lavoro. Il thread SQL non deve essere in esecuzione sullo slave poiché i file di log del relay sono il registro di tutte le modifiche. I log binari MySQL sono un log di tutte le query di scrittura in un database. È possibile visualizzare il contenuto di un log binario MySQL (o un log relay, che è quello che viene chiamato quando uno slave lo ha trasferito dal master) con il comando mysqlbinlog .

Il tuo server di registrazione deve essere protetto bene. Idealmente, dovresti avere il numero minimo di account utente possibile e qualsiasi account utente su di esso dovrebbe avere una password diversa o una chiave SSH per il resto dei tuoi server.

Questo schema ha il vantaggio che non solo è possibile rilevare che è stata apportata una modifica, ma è anche possibile guardare più indietro nei registri per scoprire quali erano i valori prima della modifica. Può essere superato da un utente malintenzionato che riesce ad acquisire un account shell root sul server database principale.