Modifica delle password prima di memorizzarle

Applicare una trasformazione alle password prima di eseguirne l'hashing non arreca alcun danno diretto alla sicurezza fintanto che è iniettivo : due password distinte prima di applicare la trasformazione devono comunque essere distinte una volta che entrambe sono state trasformate. Il tuo "spostamento di caratteri" va bene per quello se lo fai correttamente (cioè fai attenzione a trasformare un byte di valore 255 in un byte di valore 0 che "tronca" la password).

Indirettamente , c'è un po 'di danno nel fatto che la tua trasformazione extra è un codice extra, quindi una complessità extra, e la complessità è sempre negativa per la sicurezza. Inoltre, se la trasformazione è computazionalmente costosa, allora si scontra con il numero di iterazioni usato in PBKDF2 / bcrypt (cioè hai meno CPU disponibile, quindi devi usare un conteggio iterazione inferiore).

Una trasformazione come quella che si immagina fa bene alla sicurezza solo nella misura in cui l'attaccante non ne è a conoscenza, cioè l'attaccante non ha fatto i compiti. Gli attaccanti di bassa potenza di base, che sono appena stati fortunati con un attacco di iniezione SQL, possono in realtà non avere la conoscenza, ma questi attaccanti non sono quelli spaventosi. La tua trasformazione extra non scoraggerà i potenti attaccanti, e questo è un strong attaccante di cui dovresti preoccuparti.

Le trasformazioni applicate dopo hashing non hanno alcuna influenza sulla sicurezza, tranne se stai usando qualcosa come hashing extra, nel qual caso stai solo cercando di creare una funzione hash personalizzata, che, come al solito, è una cattiva idea Quindi non farlo. Il modo corretto di utilizzare la CPU non è sprecarlo in turni di carattere voodoo e altri rituali; invece, usa la tua CPU per avere un conteggio iterazione bcrypt / PBKDF2 il più alto possibile per le prestazioni complessive dell'applicazione.

No.

L'intero principio della crittografia moderna è che dovresti assumere automaticamente che l'hacker conosce il tuo schema crittografico. Stai trattando il tuo schema come segreto, che è una cattiva idea.

Attacca al normale bcrypt / PBKDF2.

Salire le password oscura questi modelli. Fondamentalmente suggerisci di salare due volte. Una volta con il sale fatto in casa e successivamente in bcrypt.

Ciò produrrebbe una sicurezza aggiuntiva solo in uno scenario in cui l'attaker non conosce il sale fatto in casa ma conosce il sale esclusivo che usi con bcrypt.

Un tale scenario non dovrebbe accadere. L'attaccante dovrebbe conoscere il tuo sale unico per bcrypt se ha accesso all'intero sistema e quindi conosce anche il sale fatto in casa.

In generale, è consigliabile affidarsi alla funzione di crittografia anziché provare a implementare la propria. In questo caso significa affidarsi a bcrypt per farlo correttamente, invece di cercare di ottenere la salatura direttamente.

Quello che stai facendo con lo spostamento dei personaggi, sta aggiungendo un segreto al processo di hashing. Un utente malintenzionato deve sapere (o deve scoprire) cosa hai fatto prima di calcolare l'hash, altrimenti non può usare un dizionario per trovare la password originale.

Ci sono modi migliori per aggiungere un segreto sul lato server. È possibile crittografare la password già con hash con un blocco cifrato (crittografia bidirezionale). Per ottenere la chiave, un utente malintenzionato non ha solo bisogno di accedere in lettura al database (SQL-injection), inoltre deve ottenere i privilegi sul server per leggere la chiave.

➽ Con la crittografia dell'hash della password è possibile prevenire gli attacchi del dizionario, a condizione che la chiave rimanga segreta. La chiave rimane segreta, purché l'utente malintenzionato non abbia privilegi sul server.

Questo è lo stesso vantaggio che un peperoncino può darti, ma in contrasto con il pepe, la crittografia dell'hash consente di scambiare la chiave, se necessario.

Ricorda che gli attacchi intelligenti di "forza bruta + dizionario" si basano sulla possibilità di provare milioni di ipotesi al secondo. Implementato correttamente bcrypt / PBKDF2 / scrypt richiederà diversi decimi di secondo per ipotesi, rendendo così la forza bruta poco pratica su larga scala.

L'articolo di Ars Technica chiarisce nella prima pagina che questi attacchi vengono eseguiti contro hash MD5 non salati.

Quindi, se vuoi proteggerti da questi attacchi, la scelta di un conteggio di iterazione elevato per la funzione di derivazione della chiave è più importante di qualsiasi intelligente modifica alla password o all'hash.