Aggiorna

Il fatto che tu debba porre questa domanda è la risposta stessa: non sai cosa c'è di sbagliato nell'impilare queste primitive, e quindi non puoi sapere quali vantaggi o ci sono punti deboli.

Facciamo alcune analisi su ciascuno degli esempi che hai fornito:

md5 (md5 (salt) + bcrypt (password))

Vedo alcuni problemi qui. Il primo è che stai MD5'ing il sale. Che vantaggio offre questo? Nessuna. Aggiunge complessità e il sale è semplicemente pensato per essere unico per prevenire collisioni di password e attacchi di pre-calcolo (ad es. Tabella arcobaleno). L'uso di MD5 qui non ha alcun senso e potrebbe effettivamente indebolire lo schema poiché MD5 ha conosciuto collisioni banali. Pertanto, esiste una piccola possibilità che l'introduzione di MD5 qui possa significare che due sali unici producono lo stesso hash MD5, risultando in un sale effettivamente duplicato. Non va bene.

Successivamente, usi bcrypt sulla password. Ok. Ebbene, la maggior parte delle implementazioni di bcrypt richiede un salt internamente, quindi questo è già tecnicamente non valido. Supponiamo che tu lo sappia e che volessi dire bcrypt (md5 (salt), password) . Questa parte sta ancora cadendo nella debolezza che ho descritto sopra, ma non è troppo malandata: rimuovi l'MD5 ed è un uso standard di bcrypt.

Infine, MD5 il tutto. Perché stai facendo questo? Qual è lo scopo? Che vantaggio porta? Per quanto posso vedere, non c'è alcun vantaggio. Sul lato negativo, aggiunge più complessità. Poiché la maggior parte delle implementazioni di bcrypt usa la notazione $ 2a $ rounds $ salt $ hash , dovrai scrivere del codice per analizzarlo in modo da poter estrarre la parte hash e memorizzare il resto separatamente. Avrai anche bisogno di un'implementazione MD5, che non era necessaria.

Quindi, in termini di impronta del codice per potenziali vettori di attacco, sei passato da una semplice implementazione di bcrypt, a un'implementazione di bcrypt con codice di analisi personalizzato e implementazione MD5 e un po 'di codice collante per incollare tutto insieme. Per zero vantaggi e una potenziale vulnerabilità nella gestione del sale.

Avanti:

scrypt (bcrypt (password + salt))

Questo non è poi così male, ma ancora una volta hai bisogno di un po 'di codice per analizzare i risultati di bcrypt in hash e salt / round count separatamente. In questo caso immagino che ci sia un leggero vantaggio, perché bcrypt e scrypt funzionano in modi diversi per più o meno lo stesso obiettivo, il che renderebbe un po 'più difficile per un hacker estremamente ben finanziato per creare ASIC personalizzati per rompere il tuo schema. Ma è davvero necessario? Stai davvero andando a colpire una situazione in cui uno stato nazione dedicherà qualche milione di dollari solo per rompere il tuo hash? E, se mai si presentasse questo caso, infastidirà davvero l'attaccante dover spendere qualche milione in più per raddoppiare il numero di chip?

Un altro potenziale problema con la combinazione di bcrypt e scrypt in questo modo è che c'è stato molto poco studio su come i due interagiscono. Pertanto, non sappiamo se ci sono casi strani che possono causare problemi. Come esempio più ovvio, prendi l'unico time pad. Calcoliamo c = m ^ k per un messaggio m e una chiave altrettanto lunga perfettamente casuale k e otteniamo una sicurezza perfetta. Quindi facciamolo due volte , per una sicurezza ancora maggiore! Questo ci dà c = m ^ k ^ k ... oh, aspetta, questo ci dà solo m . Quindi, poiché non ci siamo presi il tempo per capire correttamente come funzionavano le parti interne del sistema, ci siamo ritrovati con una vera vulnerabilità di sicurezza. Ovviamente è più complicato nel caso dei KDF, ma vale lo stesso principio.

E infine:

sha1 (md5 (scrypt (password + md5 (salt))) )

Ancora una volta ci stiamo imbattendo nel problema del sale con MD5. Sono anche incuriosito dal fatto che MD5 abbia l'hash SHA1. Quale possibile vantaggio potrebbe avere, se stai già utilizzando un KDF lento come scrypt? I pochi nanosecondi necessari per calcolare quegli hash impallidiscono rispetto alle centinaia di millisecondi necessari per calcolare lo scrypt digest della password. Stai aggiungendo complessità per un livello di "sicurezza" assolutamente irrilevante, che è sempre una cosa negativa. Ogni riga di codice che scrivi è una potenziale vulnerabilità.

Ora ricorda quel punto che ho fatto all'inizio della mia risposta. Se, in qualsiasi momento di questa risposta, hai pensato "oh sì, non ci ho pensato", allora il mio punto è dimostrato.

Ti stai imbattendo in quello che descriverei come La falsa massima di Dave:

Se aggiungo più cose crittografiche, sarà più sicuro.

Questo è un tratto comune tra sviluppatori, e una volta ci credevo anch'io. Va di pari passo con la negazione di altri principi, come il Principio di Kerckhoff. In definitiva, devi capire e accettare che l'oscurità non è un parapetto di sicurezza; è una stampella per criptovalute deboli. Se la tua crittografia è forte, non ha bisogno di stampelle.

Le primitive crittografiche possono essere impilate in modo sicuro e aumentare la sicurezza se, e solo se, conosci le primitive abbastanza bene da comprendere le loro debolezze e come interagiscono queste debolezze. Se non li conosci o non capisci i dettagli, beh, è ​​così che ottieni il protocollo di Dave.

Il problema è che pochissime persone li conoscono tutti abbastanza bene per giudicare se una certa combinazione è sicura. Ecco perché deve essere qualcosa che viene pubblicato e rivisto, se non è stato rivisto non hai modo di sapere se è forte come scrypt o se è più vicino a CRC32.

Quindi, se non sei un esperto, è del tutto possibile che tu abbia qualcosa di più debole della primitiva più debole che hai usato (vedi il protocollo di Dave) e non lo sapresti. O almeno non lo sapresti fino a quando non viene decifrato: trovare le password dei tuoi utenti su Pastebin non è proprio il modo ideale per determinare che lo schema è difettoso.

Sono d'accordo che un certo grado di oscurità può aiuto da una prospettiva di difesa in profondità, ma il sistema sottostante deve essere sicuro.

Tra scrypt , bcrypt e PBDKF2 - almeno uno di essi sarà supportato praticamente su tutte le piattaforme. Questi sono noti e ben testati: offrono diversi livelli di protezione, ma sono comunque molto più sicuri di un bizzarro raggruppamento di md5 e sha1 .

Per la tua domanda specifica sulla combinazione di scrypt e bcrypt, ricorda che queste funzioni hanno un costo configurabile e vuoi aumentare quel costo il più possibile, mantenendolo tollerabile per il tuo utilizzo specifico. Ad esempio, se puoi utilizzare bcrypt con un massimo di X iterazioni (oltre le quali è troppo costoso per il tuo server e il tuo numero medio di connessioni utente al secondo), o scrypt con un massimo di Y iterazioni, quindi non puoi usare scrypt (bcrypt) con X iterazioni per bcrypt poi Y iterazioni per scrypt: questo andrà oltre il budget della CPU.

Quindi, se si sovrappongono scrypt e bcrypt, è necessario utilizzarli entrambi con meno iterazioni di quanto si sarebbe potuto fare con uno solo. Non "ottieni il meglio di entrambi i mondi" semplicemente mettendoli insieme. In effetti, il meglio che puoi sperare è una sorta di media tra i due. E questo ha il prezzo di un codice più complesso, qualcosa che è intrinsecamente negativo quando si parla di sicurezza (o, per quella materia, manutenibilità).

Oltre alla risposta di Adam, vorrei anche menzionare che ogni volta che usi la crittografia, dovresti avere una ragione forte e inevitabile per farlo. Negli esempi precedenti, questo non esiste.

  md5 (md5 (salt) + bcrypt (password)) scrypt (bcrypt (password + salt))  

Gli algoritmi bcrypt e scrypt sono già abbastanza potenti e considerati effettivamente indistruttibili. Che problema stai cercando di risolvere? E perché credi che combinare i loro risultati (in particolare con md5 ) lo risolverà? Nella migliore delle ipotesi, probabilmente hai semplicemente ridotto la difficoltà di crackare la password a quella dell'hash più debole, piuttosto che migliorare effettivamente la sicurezza. E lo scenario peggiore è spaventosamente indefinito.

  md5 (sha1 (md5 (md5 (password) + sha1 (password + salt)) + password))  

Questa soluzione è anche peggiore. Implementa manualmente uno schema di hashing ripetuto, ma senza giri sufficienti per imporre effettivamente un fattore di lavoro significativo agli aggressori.

In poche parole, il problema è che:

• tu " stai facendo il giro della crittografia senza avere effettivamente un problema che deve essere risolto
• hai notevolmente aumentato la probabilità di introdurre difetti nella tua implementazione
• probabilmente hai diminuito la sicurezza ai più deboli dei algoritmi di hashing e
• hai introdotto uno scenario peggiore sconosciuto in cui non esisteva nessuno

Se applichi operazioni non sicure a un algoritmo sicuro, puoi sicuramente interrompere la funzione di hashing. La tua nuova funzione potrebbe anche essere di gran lunga peggiore dell'anello più debole.

Perché gli aggressori non lo usano per interrompere le funzioni protette? Non li aiuta. Ad esempio, se sovrascrivo i primi 440 bit di una password memorizzata in modo sicuro utilizzando bcrypt con zero, posso facilmente trovare una password corrispondente con la forza bruta, ma quella password funzionerà solo sul mio terribile algoritmo. Un'implementazione sana probabilmente lo rifiuterebbe.

L'azzeramento di grosse porzioni di un hash è chiaramente un male, ma anche le operazioni sicure possono essere combinate in qualcosa di pericoloso. L'aggiunta di due numeri (modulo n per garantire una lunghezza costante) è "sicura". Generalmente, nessuna entropia viene persa. Tuttavia, h (x) + h (x) mod n riduce la qualità dell'hash h (x) di un bit, poiché il risultato è sempre pari. L'operatore altrettanto sicuro XOR fa anche peggio, poiché h (x) XOR h (x) restituisce sempre zero.

Queste insidie ​​sono abbastanza ovvie, ma non tutte lo sono. Tieni presente che, come sempre, è banale inventare uno schema abbastanza buono da non trovare punti deboli da solo, ma molto difficile inventarne uno dove nessun altro può.

Le funzioni hash vengono create dai crittografi e distrutte dai crittografi. Ci sono molte funzioni hash forti e funzioni deboli ancora in uso oggi. I programmatori dovrebbero fidarsi dei crittografi e della funzione hash. Se ci fosse mai una vulnerabilità nella funzione hash, allora ne sentiresti sicuramente parlare su Internet o tramite colleghi e quindi i crittografi faranno sicuramente un'indagine approfondita. Con qualsiasi algoritmo di hash sicuro, è noto che l'unico punto debole potrebbe essere un attacco bruteforce.

La combinazione di funzioni hash non aggiunge quasi nessuna sicurezza extra e qualsiasi cosa tu voglia aggiungere, probabilmente è già implementata nella funzione.

Salare una password è ottimo per ridurre l'efficacia contro le tabelle arcobaleno in modo tale che una password non possa essere semplicemente "cercata". Sia che abbiate hash una funzione due volte o cambiate la funzione hash, essenzialmente sta saltando la password. E la maggior parte delle funzioni include un metodo semplice per il sale, quindi non è davvero necessario implementarlo.

Diciamo che voglio creare il mio hash sicuro perché lo fanno tutti. E poiché non sono un crittografo, ne avrò bisogno "veramente" sicuro, perché ovviamente ogni programmatore sa come creare un hash sicuro invece di usare quelli sicuri già creati. Quindi creo la mia subdola funzione hash, mod10 (md5 (sha1 (bcrypt (password + salt)))).

Come puoi vedere dalla mia funzione hash, è davvero sicura perché ne uso tante diverse cose in esso. Ovviamente in questo stupido esempio, è facile vedere che ci saranno solo 10 diversi output possibili. Ma semplicemente utilizzando una singola funzione hash sicura, l'avrebbe completamente evitato.

Certo, il tuo sistema dovrebbe essere sicuro se l'aggressore ha il codice sorgente, ma è molto probabile che il tuo l'attaccante non avrà accesso al tuo codice sorgente e probabilmente non sarà in grado di indovinare il tuo stravagante hash, rendendo impossibile qualsiasi tentativo di forza bruta

Quindi supponiamo che un utente malintenzionato abbia acquisito la tabella del database che contiene gli hash. Presumo che sia molto probabile che un utente malintenzionato possa ottenere anche i file della pagina Web. I tuoi sistemi che eseguono questi servizi potrebbero essere lo stesso exploit che ti ha permesso di prendere il database. Un server di database è configurato in modo che il pubblico non possa accedervi direttamente. D'altra parte, il tuo server web contenente il tuo codice è in prima linea.

Ogni volta che aumenti la complessità di un algoritmo o addirittura aggiungi più righe di codice, aumenti i punti di errore nella tua applicazione. Potrebbero esserci conseguenze indesiderate della combinazione di algoritmi. Ciò può portare a determinati tell o altri segni che possono effettivamente indebolire la forza crittografica del sistema.

Più librerie usi nella tua applicazione, maggiore è il rischio per la tua applicazione in generale. Se viene rilevato un difetto in un'implementazione che consente una debolezza, l'esecuzione di codice, ecc., La tua applicazione è vulnerabile. Se per fortuna ti è capitato di selezionare un altro algoritmo che non è stato attaccato, sei al sicuro per il momento (ovviamente potresti anche essere dalla parte sfortunata della fortuna).

Ricorda BACIO : mantienilo semplice, stupido, altrimenti potresti perderti nella complessità.

Non sono d'accordo con un intero gruppo di persone che sono più intelligenti di me e più esperte in sicurezza di me. Quindi probabilmente mi sbaglio.

Improvvisare la tua funzione hash è una buona idea, se lo fai bene. Segui questi 3 semplici passaggi.

1. Identifica un punto debole o un difetto nelle funzioni hash esistenti.
2. Improvvisa la tua funzione hash che non ha questo difetto.
3. Verifica che la tua funzione hash improvvisata abbia tutti i punti di forza delle funzioni hash esistenti.

Dopo aver completato il passaggio 3, saresti un pazzo a non usare la tua funzione hash improvvisata.

Quando si concatenano diverse funzioni hash perché si è preoccupati di quella è vitale che si riapplichi il sale prima di applicare l'algoritmo di hashing successivo, quindi qualsiasi punto debole di collisione in uno degli algoritmi non contaminerà la seconda funzione hash che sei utilizzando:

scrypt (bcrypt (password + salt) + salt)

Ma penso che scrypt sia una tecnica consolidata ora, Argon 2i ha vinto la competizione di hashing delle password e si crede che lo sia più sicuro e bcrypt esiste da molto tempo e si è dimostrato sicuro contro banali bypass.

Pertanto quanto segue avrebbe più senso e combinerebbe la forza di argon 2i, ma ricadrebbe su bcrypt se un futuro attaccante mostrasse come rompere banalmente l'argon 2i, cosa che al momento si pensa sia difficile:

bcrypt (Argon2i (password + salt) + salt)

Ma tu sei meno probabile commettere un errore se lo fai semplicemente:

scrypt (password + salt) Orbcrypt (password + salt)

Ricorda, la maggior parte delle violazioni sono dovute all'erro umano r nel codice, è molto meglio mantenerlo semplice e rivedere completamente il codice con analisi statiche dinamiche e revisori di codice umano, per assicurarsi che nessun attacco sql injection sfugga (ricorda sempre di parametrizzare le query del database!)

Ho imparato molto con questo thread, quindi ho pensato in modo da comprendere facilmente il possibile risultato quando si combinano metodi diversi (ovviamente, non si adatta a tutti i casi):

[W = debole, S = forte]:

  Formula | Esempio --------------- | ----------------- W (W) = W | md5 (sha1 (pwd)) W (S) = W | md5 (bcrypt (pwd)) S (W) = W | bcrypt (md5 (pwd)) S (S) = S- | bcrypt (scrypt (pwd)) // la loro interazione è sconosciuta W + S = W | md5 (pwd) + brcypt (pwd) S + S = W | bcrypt (pwd) + scrypt (pwd) W '+ S "= S | md5 (pwd1) + brcypt (pwd2) // pwd1! = pwd2S' + S" = 2S | bcrypt (pwd1) + scrypt (pwd2) // pwd1! = pwd2SUBSTR (W) = W | substr (md5 (pwd), n); // Più corta la stringa, più deboleSUBSTR (S) = S- | substr (bcrypt (pwd), n); // Più corta la stringa, più debole S + x = S + | bcrypt (pwd) + x // x = Variabile str. non correlato a pwdS (S + x) = S- | bcrypt (scrypt (pwd) + x) // x = Variable str. non correlato a pwdROT13 (S) = S | ROT13 (bcrypt (pwd)) 

Quello che voglio ottenere qui è mostrare in modo semplice che quelle combinazioni non aggiungeranno ulteriore sicurezza nella maggior parte dei casi (quindi la complessità aggiunta è non degno).