Dove dovrebbero venire i valori di hash di sale?

Di solito ho una colonna created TIMESTAMP in una tabella utente, quindi posso vedere quando l'utente si è registrato. Non mi piace aggiungere una colonna aggiuntiva per Salt, quindi uso la colonna timestamp come salt:

SHA1(password + created)

È importante?

Il sale ha due scopi. Rende poco pratico l'utilizzo di grandi tabelle di password pre-scalate ("tavole arcobaleno") e rende le password identiche dall'aspetto diverso nella lista degli hash. Rendere diverse le password identiche aiuta a evitare un problema in cui diverse persone utilizzano una particolare password, che è presumibilmente una debole comune.

Pertanto, ogni account dovrebbe avere il proprio sale unico e i sali non dovrebbero essere eccessivamente prevedibili, nel senso che non ci sarà un gruppo di sali che potrebbero verificarsi. (Se molti siti iniziassero a 1 e si contavano, i cattivi potevano costruire tabelle arcobaleno inclusi i sali a basso numero, per esempio.) Non devono essere casuali in nessun senso se non generalmente imprevedibili. Non sono più segreti dell'hash in sé, quindi non hanno bisogno di essere specificamente inaccessibili.

Utilizzare qualsiasi metodo conveniente per generare un sale. Se c'è un sacco di potenziali valori di sale (primi sistemi Unix usati frequentemente due byte, per un possibile numero di 65536) rispetto al numero di account, assegnazione semi-casuale avrebbe quasi mai dare un sale duplicato.

Ogni volta che vuoi memorizzare una nuova password (registrazione, reimpostazione password, aggiornamento password), una buona tecnica è:

• generare nuovo sale
  • usa un generatore di numeri pseudo casuali crittograficamente sicuro
  • usa una dimensione decente salata - un buon valore è la dimensione del blocco dell'algoritmo hash sottostante (potrebbe essere SHA-256)
• genera un nuovo token password
  • crea una funzione hmac dall'algoritmo hash sottostante (potrebbe essere SHA-256) usando il salt come chiave hmac
  • for i in (0...65536) { password = hmac(password) }
  • il risultato delle applicazioni iterate della funzione hmac è il token della password
• memorizza il token della password e del sale
  • non memorizzare la password originale
  • opzionalmente memorizza l'algoritmo di hash sottostante e gli stretch per scopribilità

Sfrutta il framework. In .NET è possibile utilizzare RNGCryptoServoiceProvider ...

        // If salt is not specified, generate it on the fly.
        if (saltBytes == null)
        {
            // Define min and max salt sizes.
            int minSaltSize = 4;
            int maxSaltSize = 8;

            // Generate a random number for the size of the salt.
            Random  random = new Random();
            int saltSize = random.Next(minSaltSize, maxSaltSize);

            // Allocate a byte array, which will hold the salt.
            saltBytes = new byte[saltSize];

            // Initialize a random number generator.
            RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();

            // Fill the salt with cryptographically strong byte values.
            rng.GetNonZeroBytes(saltBytes); 
        }

Gli altri framework dovrebbero avere classi simili che puoi sfruttare. Per ottenere software di casualità, spesso le volte impiega l'utente rispetto a Random come menzionato sopra. Spostare in modo casuale un mouse in un'area definita per fornire il sale è un'opzione utilizzata da TrueCrypt. Si riduce alle vostre esigenze specifiche e al livello di sicurezza; dato che il tuo sale potrebbe essere semplicemente !@#$% .

Si genera un server salt side e lo si assegna a un account utente al momento della sua creazione. È meglio utilizzare alcune API di crittografia disponibili con il framework, ma in linea di principio qualsiasi sequenza verrà eseguita.

Di solito le cose sono memorizzate in questo modo:

User
-------------------
ID
Username
PasswordHashWithSalt

Esempio:

PasswordHashWithSalt =

A15CD9652D4F4A3FB61A2A422AEAFDF0DEA4E703 j5d58k4b56s8744q

Usa bcrypt e leggi questo articolo come per i normali hash da solo non è una protezione seria in questo giorno ed età.

Considera l'utilizzo del protocollo di password di conoscenza zero SDR che ha un sacco di librerie opensource ed è privo di brevetti.

L'SDR richiede sale e il posto migliore per ottenere questo è il client; tempo le loro sequenze di tasti, i movimenti del mouse, hash le loro variabili di ambiente, numeri casuali, tempi di creazione dei file nella loro cartella temporanea, per fare sale alla fine in modo imprevedibile lontano dal server. SDR prende il sale, un grande primo, la password dell'utente e genera un codice di verifica. Non si memorizza una password che non lascia mai la propria macchina, ma è possibile verificare che abbiano la password che accompagna la chiave di verifica e la password. È immune dagli attacchi dell'uomo nel mezzo e del dizionario. Criptare le chiavi e salare nella colonna del database solo per essere sicuro.