In alcune circostanze, i peperoni possono essere utili.

Come esempio tipico, supponiamo che tu stia creando un'applicazione web. Consiste di codice webapp (in esecuzione in alcuni framework webapp, ASP.NET MVC, Pyramid on Python, non importa) e un database SQL per l'archiviazione. La webapp e il database SQL vengono eseguiti su server fisici diversi .

L'attacco più comune contro il database è un attacco SQL Injection riuscito. Questo tipo di attacco non ottiene necessariamente l'accesso al codice della tua webapp, perché la webapp viene eseguita su un altro server ID utente &.

Devi memorizzare le password in modo sicuro nel database e trova qualcosa sotto forma di:

  $ hashed_password = hash ($ salt. $ password)  

dove $ salt è memorizzato come testo normale nel database, insieme alla rappresentazione $ hashed_password e scelto a caso per ogni password nuova o modificata .

Il l'aspetto più importante di ogni schema di hashing delle password è che hash è una funzione hash crittograficamente sicura lenta , vedi https: //security.stackexchange .com / a / 31846/10727 per una maggiore conoscenza di base.

La domanda è quindi, dato che è quasi nullo aggiungere un valore costante al codice dell'applicazione e che il codice dell'applicazione non sarà in genere compromesso dur durante un attacco SQL Injection, quanto segue è quindi sostanzialmente migliore di quanto sopra?

  $ hashed_password = hash ($ pepper. $ sale. $ password)  

dove $ salt è memorizzato in testo normale nel database e $ pepper è una costante memorizzata in testo normale nel codice dell'applicazione (o configurazione se il codice viene utilizzato su più server o l'origine è pubblica).

Aggiungere questo $ pepper è facile: stai solo creando una costante nel tuo codice, inserendo un grande valore casuale crittograficamente sicuro (ad esempio 32 byte da / dev / urandom hex o base64 codificato) in esso e utilizzando quella costante nella funzione di hashing della password. Se hai utenti esistenti, hai bisogno di una strategia di migrazione, ad esempio modifica la password all'accesso successivo e memorizza un numero di versione della strategia di hashing della password insieme all'hash.

Risposta:

L'uso di $ pepper non aggiunge alla forza dell'hash della password se la compromissione del database non implica la compromissione dell'applicazione. Senza la conoscenza del pepe le password rimangono completamente sicure. A causa del salt specifico per la password non puoi nemmeno scoprire se due password nel database sono uguali o meno.

Il motivo è che hash ($ pepper. $ Salt. $ Password) crea efficacemente una funzione pseudo casuale con $ pepper come chiave e $ salt. $ password come input (per candidati hash sani come PBKDF2 con SHA *, bcrypt o scrypt). Due delle garanzie di una funzione pseudo casuale sono che non è possibile dedurre l'input dall'output sotto una chiave segreta e nemmeno l'output dall'input senza la conoscenza della chiave. Questo suona molto come la proprietà unidirezionale delle funzioni hash, ma la differenza sta nel fatto che con valori di entropia bassi come le password puoi enumerare efficacemente tutti i valori possibili e calcolare le immagini sotto la funzione hash pubblica e quindi trovare il valore il cui l'immagine corrisponde alla pre-immagine. Con una funzione pseudo casuale non puoi farlo senza la chiave (cioè senza il pepe) in quanto non puoi nemmeno calcolare l'immagine di un singolo valore senza la chiave.

L'importante ruolo di $ salt in questa impostazione entra in gioco se hai accesso al database per un periodo di tempo prolungato e puoi ancora lavorare normalmente con l'applicazione dall'esterno. Senza $ salt potresti impostare la password di un account che controlli su un valore noto $ passwordKnown e confrontare l'hash con la password di una password sconosciuta $ passwordSecret . Come hash ($ pepper. $ PasswordKnown) == hash ($ pepper. $ PasswordSecret) se e solo se $ passwordKnown == $ passwordSecret puoi confrontare una password sconosciuta con qualsiasi valore scelto (come tecnicismo presumo la resistenza alle collisioni della funzione hash). Ma con il salt si ottiene hash ($ pepper. $ Salt1. $ PasswordKnown) == hash ($ pepper. $ Salt2. $ PasswordSecret) se e solo se $ salt1. $ passwordKnown == $ salt2. $ passwordSecret e come $ salt1 e $ salt2 sono stati scelti casualmente per $ passwordKnown e rispettivamente $ passwordSecret i sali non saranno mai gli stessi (assumendo valori casuali abbastanza grandi come 256 bit) e non potrai più confrontare le password tra loro.

(Nota: usare un salt è solo metà del lavoro; devi anche rallentare la funzione hash, in modo che attaccare una singola password a bassa entropia sia ancora difficile. La lentezza si ottiene solitamente attraverso più iterazioni o hashing la concatenazione di 10000 copie di salt e password.)

Quello che fa il tuo "pepe" è che trasforma l'hash in un MAC. Creare un MAC buono e sicuro da una funzione hash non è facile, quindi è meglio usare HMAC invece di un costrutto fatto in casa (il modo teorico di definirlo è che una funzione hash resistente alle collisioni è non necessariamente indistinguibile da un oracolo casuale).

Con un MAC, potresti guadagnare un po 'di sicurezza nel seguente senso: forse, l'accesso in lettura al database da parte dell'attaccante potrebbe cessare di essere un vero problema. La chiave MAC (il "pepe") può concentrare la necessità di riservatezza. Tuttavia, ciò si basa sul fatto che il MAC è anche una funzione unidirezionale, che è una proprietà che otterrai da molte costruzioni MAC (incluso HMAC) ma che non è realmente garantita crittograficamente parlando (ci sono sottigliezze).

Il "pepe" implica che hai una chiave da gestire, inclusa l'archiviazione sicura in un modo che resista ai riavvii. Una chiave è piccola e si adatta alla RAM, ma, a causa dei requisiti di archiviazione, non è chiaro se migliori la sicurezza. Un utente malintenzionato in grado di leggere l'intero database di solito può anche leggere l'intero disco rigido, incluso qualsiasi file "protetto". Le dimensioni ridotte della chiave possono consentire alcune impostazioni avanzate, ad es. la chiave viene memorizzata su smartcard che vengono utilizzate all'avvio ma non lasciate collegate in seguito. Per riassumere, se valga la pena pepare lo sforzo dipende completamente dal contesto: in generale, lo sconsiglierei per evitare la complessità aggiuntiva.

Vorrei sottolineare cosa può fare veramente un peperone.

Quando aiuta un peperone?

Come gli altri hanno già sottolineato, l'aggiunta di un peperone è solo un vantaggio , fintanto che l'aggressore ha accesso ai valori hash nel database, ma non ha alcun controllo sul server e quindi non conosce il pepe . Questo è tipico dell'iniezione SQL, probabilmente uno degli attacchi più usati, perché è così facile da fare.

Cosa migliora un pepper?

  $ hashValue = bcrypt ('12345', $ cost, $ salt);  

Questa password la puoi ottenere facilmente con un attacco al dizionario, anche se hai usato correttamente una funzione di derivazione della chiave lenta. Metti le password più utilizzate in un dizionario e forza bruta con queste password deboli. È molto probabile che troviamo la password in (troppi) casi.

  $ hashValue = bcrypt ('12345anm8e3M-83 * 2cQ1mlZaU', $ cost, $ salt);  

Con il pepe, la password debole cresce in lunghezza, ora contiene caratteri speciali e, cosa più importante, la troverai in nessun dizionario. Quindi, finché il pepe rimane segreto, previene gli attacchi ai dizionari , in questo caso può proteggere le password deboli.

Modifica:

un modo migliore per aggiungere una chiave lato server, piuttosto che usarlo come pepe. Con un peperoncino un utente malintenzionato deve ottenere ulteriori privilegi sul server per ottenere la chiave. Lo stesso vantaggio si ottiene calcolando prima l'hash e successivamente crittografando l'hash con la chiave lato server (crittografia a due vie). Questo ci dà la possibilità di scambiare la chiave ogni volta che è necessario.

  $ hash = bcrypt ($ passwort, $ salt); $ encryptedHash = encrypt ($ hash, $ serverSideKey);  codice> 

Il documento sull'invenzione del salting e delle iterazioni, per le password Unix ( Password Security: A Case History, Morris & Thompson, 1978), descriveva anche l'equivalente di un peperone:

I primi otto caratteri della password dell'utente sono usati come chiave per il DES; quindi l'algoritmo viene utilizzato per crittografare una costante. Sebbene questa costante al momento sia zero, è facilmente accessibile e può essere resa dipendente dall'installazione.

Non ne ho mai sentito parlare. Qualcun altro?

Solo a proposito, le nuove linee guida sull'identità digitale del NIST (Draft) consigliano vivamente di utilizzare anche Pepper:

https://pages.nist.gov/800-63-3/ sp800-63b.html # sec5

5.1.1.2 Memorized Secrets Verifier:

... Una funzione hash con chiave (ad esempio, HMAC [FIPS198-1 ]), con la chiave memorizzata separatamente dagli autenticatori con hash (ad esempio, in un modulo di sicurezza hardware) DOVREBBE essere utilizzata per resistere ulteriormente agli attacchi del dizionario contro gli autenticatori con hash memorizzati.

Considera questo scenario:

Sto per entrare in un sito web X usando un'iniezione SQL per recuperare un elenco di utenti, con le loro password hash e salt. Supponiamo che anche il sito Web X utilizzi un pepe globale.

Tutto ciò che dovrei fare sarebbe registrare un utente sul sito Web X con un nome utente e una password a me noti prima dell'iniezione SQL. Vorrei quindi conoscere, per un particolare record nel database, l'hash della password, la password in testo normale, il salt (memorizzato come testo normale) e sarebbe computazionalmente banale per me rompere il pepe globale sulla base di questo record .

Quindi, davvero, un peperone sarebbe un modo per rallentare un attaccante per una quantità insignificante di tempo di overhead. Non dovrebbero forzare brutemente la password + sale + pepe, come previsto, solo il pepe.

Quanto sopra è una forma di attacco di testo in chiaro scelto . Finché gli aggressori conoscono l'algoritmo (hash ()), l'output ($ hashed_password) e tutti gli input tranne uno ("costanti" $ salt & $ password e "variabile" $ pepe), possono "risolvere per x "come un'equazione di algebra lineare (h = s + p + x == hsp = x), ma naturalmente con la forza bruta. Rendere il pepper più lungo di 56 byte (448 bit), il limite di bcrypt, aumenta il costo del tempo ed è buono come bcrypt ma potrebbe non essere buono come scrypt. Quindi, finché il pepe è sufficientemente lungo, è un miglioramento.

Non ho molta familiarità con il modo in cui un server sarebbe in grado di nascondere una costante di pepe globale, ma la mia opinione è che prima o poi un hacker che è penetrato nel server capirà come catturare il valore di pepe. sicuro richiederebbe hardware speciale. Un modo per farlo sarebbe utilizzare una scheda FPGA installata nel server. L'FPGA conterrebbe il codice utilizzato per eseguire l'hash compreso il valore del pepe e tutti i calcoli dell'hash avvengono all'interno dell'FPGA. Con l'FPGA, la programmazione può essere una funzione unidirezionale. Il peperone può essere programmato ma non ci sono istruzioni che possono essere inviate per leggerlo nuovamente. Il pepe sarebbe stato conservato su un pezzo di carta chiuso in una cassaforte. Se il pepe è 128 bit generati in modo casuale, non ci sarebbe alcun modo pratico per determinarlo.
Non sono sicuro di quanto sarebbe pratico in quanto aumenterebbe il costo dell'hardware del server.