Soluzione per calcolare e memorizzare un hash salt in un'applicazione open source?

Sembra che tu pensi che il sale e / o l'algoritmo di salatura e hashing debbano essere tenuti segreti. Loro non. Salt protegge solo contro scenari di minacce molto specifici.

Ricorda che il calcolo di un hash su un valore restituisce sempre lo stesso valore di hash (altrimenti sarebbe inutile.) Ma ciò significa che un utente malintenzionato può usare quella proprietà per testare i valori hash nel tuo database mediante ipotesi di hashing. Se la sua ipotesi ha lo stesso valore di un hash nel tavolo, la sua ipotesi era corretta e lui conosce quella password. Salting aiuta a prevenire che questo sia un problema in due modi.

1. Aggiungendo una password lunga saltuale alla password prima dell'hashing, essa protegge da qualcuno che pre-calcola i valori hash delle ipotesi di password. (Questo è chiamato "rainbow table attack", puoi andare online e acquistare un disco rigido da 1TB con miliardi di hash precomputer già in una tabella di ricerca.)

2. Usando un salt unico per ogni password, proteggi contro qualcuno che individua le collisioni nel tuo database. Senza usare un unico salt per ogni password, se la mia password era ABC e ha cancellato a 123, e se ti è capitato di usare ABC come password, sarebbe anche hash a 123. Chiunque guardi il database vedrebbe che entrambi condividiamo una password comune

In nessun caso l'algoritmo di salt and hashing deve essere tenuto segreto per preservare queste protezioni, quindi puoi open source tutto questo lavoro.

Per maggiore sicurezza, alcune persone aggiungono ciò che viene chiamato "pepe" in questo algoritmo; 'pepe' è un nome carino per un valore salato comune che viene applicato a tutte le password in un sistema e tenuto segreto.

Ciò che è importante anche per proteggere le tue password in uno scenario di violazione è che l'algoritmo di hashing delle password è costoso dal punto di vista computazionale. Questo aiuta a prevenire gli attacchi di forza bruta, perché l'attaccante in genere non può spendere abbastanza tempo della CPU per testare miliardi di ipotesi. Il modo in cui questo viene raggiunto è attraverso la ripetizione di un algoritmo di hashing crittograficamente sicuro. Un computer moderno con una scheda GPU può calcolare 10 s di miliardi di hash SHA-1 al secondo. Se hai usato SHA-1 come algoritmo di hashing della password, significa che un utente malintenzionato potrebbe testare 10 miliardi di tentativi di password al secondo. Usando una funzione di hashing della password come PBKDF2, si ripete l'hash migliaia di volte, assicurandosi che l'autore dell'attacco possa testare solo alcune centinaia di ipotesi al secondo.

I sali vengono comunemente memorizzati con password (in genere nel campo adiacente). Il ragionamento è semplice, il software richiede il sale per determinare se salt + algorithm + provided data = stored hash .

Quello che stai descrivendo è Sicurezza attraverso l'oscurità ed è un grande no no nel mondo di oggi. Semplicemente non funziona e fornisce poca o nessuna sicurezza significativa sulla soluzione.

La sicurezza della memorizzazione della password dovrebbe provenire da:

• Ricordare agli utenti finali di scegliere password complesse.
• Utilizzo di un algoritmo appropriato per memorizzare la password.
• Salting, utilizzando una stringa / numero una sola volta, per password per impedire attacchi pre-calcolo.
• Garantire che la password "clear" non sia archiviata in memoria.
• Utilizzo del privilegio minimo per accedere a una conferma di sola lettura della corrispondenza dell'hash.
• Cripta la memoria hash a riposo o sul filo.

In base alla tua domanda, presumo che tu abbia intenzione di memorizzare il sale nel tuo codice sorgente e sei preoccupato che chiunque possa recuperare quel sale?

In questo caso ci sono alcuni malintesi. Prima di tutto un sale è un valore non segreto. Non è pensato per essere segreto, è semplicemente un valore unico per impedire che gli attacchi arcobaleno siano efficienti. Un sale deve avere le seguenti proprietà:

• Globalmente unico (ovvero sicuro generato casualmente in modo che non ci siano altre password che utilizzano lo stesso sale)
• Il sale dovrebbe essere lungo 128 bit

Il sale è memorizzato nel database accanto alla password in modo non offuscato.

Se vuoi saperne di più, ho scritto un post sul blog qualche tempo fa su hashing delle password sicure che puoi trovare qui: link

Modifica

In base al tuo commento qui sotto, lascia che elabori: L'algoritmo di hashing e il sale non sono segreti, puoi farli fuoriuscire in sicurezza senza compromettere la sicurezza del sistema. Devi solo assicurarti che il tuo algoritmo di hashing sia accettabile (solo poche implementazioni di algoritmi di hashing sono utilizzabili per l'hashing della password sono sicure). In generale non è nemmeno necessario prendersi cura di generare il sale da soli. La maggior parte dei framework che supportano algoritmi di hashing come PBKDF2, bcrypt, argon2 o scrypt si prenderanno cura di questo per voi.