Un fattore di lavoro casuale è un aumento o una diminuzione della sicurezza?

Ho intenzione di darti due risposte, nessuna delle quali è teoricamente corretta dal punto di vista delle informazioni, ognuna delle quali dovrebbe illustrare il motivo per cui non dovresti preoccuparti.

1. Entropy.
   Fondamentalmente, il tuo schema aggiunge un elemento di casualità: tra 5 e 15 cicli di hash. Quindi, qualsiasi numero casuale X tale che 5 <= X <= 15 ... in altre parole, X ha 11 possibili valori casuali ... che ti dà poco più di 3,5 bit di entropia.
   Anche se lo chiamiamo 4 bit, questo non è davvero un miglioramento sostanziale, sicuramente non abbastanza da danneggiare UX per questo.
   Ergo, lascia stare i cani.

2. Raffinazione d'attacco.
   Nel tuo schema, l'attaccante è a conoscenza del tuo schema, ma semplicemente non sa quante volte per eseguire il ciclo dell'hash. In altre parole, se cercasse di forzare i tuoi hash, dovrebbe prima averlo hash per 5 volte, quindi cancellarlo per 6 volte, quindi forse cancellarlo per 7 volte ... fino al peggiore dei casi deve farlo 15 volte.

   E allora? Prenderà la mira per 15 volte l'hashing e controllerà lungo la strada per vedere se potrebbe fermarsi presto.

   Che cosa hai appena fatto?
   Hai dato all'attaccante una facile via d'uscita, se il numero di cicli era inferiore al massimo. Quindi, perché non dare a tutti il massimo e impedire la scorciatoia?

Una risposta più corretta alla teoria delle informazioni potrebbe essere quella di puntare al principio di Kerckhoffs , che in sostanza afferma che l'unico segreto in un criptosistema dovrebbe mai essere la chiave (o, in questo caso, la password). Non la scelta dell'algoritmo, dettagli di implementazione, numero di round, ecc., Nessuno di questi dovrebbe mai essere considerato segreto.
Ma penso che sia semplicemente pedante qui.

Ecco alcuni punti su cui riflettere:

Non tirare il tuo.
C'è una ragione per cui tutti i crittografi sono un gruppo di snob e non è la loro marca speciale di caffè.
In realtà, non tentare di creare il proprio algoritmo, protocollo, schema password o procedure di gestione delle chiavi. Non lo farai meglio, e molto probabilmente lo peggiorerai.

D'altra parte - usa ciò che è già ben controllato e considerato sicuro dal meglio di chi lo sa. Bcrypt (ed è un ilk) è dannatamente strong. Vuoi più strong? Utilizzare un fattore di lavoro più grande. Ecco a cosa serve.

hashing della password è un compromesso: tu rendere la funzione più lenta (usando molte iterazioni), il che rende più costosi sia gli attacchi che l'uso normale. Accetti di dedicare più CPU al compito di verificare una password perché sai che farà anche in modo che l'hacker spenda più CPU per il cracking di una password. Una decente funzione di hashing della password offre un parametro "costo" che consente di impostare la lentezza della funzione al livello migliore, ovvero la più costosa che è possibile tollerare, per le risorse disponibili e il carico medio.

Se esegui l'hashing X volte, rendi l'utilizzo X più lento, sia per te che per l'aggressore. In pratica, ciò significa che è necessario ridurre il conteggio delle iterazioni della funzione di un fattore di X , per mantenere il calcolo all'interno del proprio budget hardware e questo annulla esattamente qualsiasi guadagno di sicurezza. Quindi, da questo punto di vista, il tuo meccanismo proposto è semplicemente neutrale rispetto alla sicurezza (tranne che aumenta la complessità dell'implementazione, che è, a parità di condizioni, una cosa negativa).

C'è ancora un punto interessante da considerare, che è la casualità di X . Supponiamo di generare X a caso, tra 5 e 15. In media, X sarà uguale a 10; quando si convalida una password (corretta), è necessario calcolare la funzione di hashing circa 10 volte (in media). Tuttavia, per decidere che una password non è corretta, devi andare a 15.

Potremmo dire: hey, va bene! Il defender (il tuo server), in condizioni di utilizzo normale, convalida la maggior parte delle password corrette (gli utenti tendono a digitare correttamente le loro password (*)), mentre l'attacker, nel suo attacco di dizionario, tenterà la maggior parte delle volte di utilizzare password errate. Quindi l'attaccante spenderà 1,5 volte più CPU per ogni tentativo di password rispetto al difensore. Abbiamo appena guadagnato un fattore 1.5x rispetto all'attaccante! Non si gonfia?

Non così. L'attaccante è a conoscenza del tuo meccanismo "casuale X " e organizzerà il suo attacco di conseguenza. Cioè, egli cancellerà le parole nel suo dizionario con 5 invocazioni di hashing, registrando i valori hash (nella RAM - stiamo parlando solo di milioni di valori hash qui, o forse di un paio di miliardi, niente di estremo). Se uno dei valori hash si adatta, va bene, l'attaccante ha vinto. In caso contrario, calcolerà un'ulteriore invocazione hash su ciascun valore registrato e riproverà. E così via.

In questo modo, l'attaccante otterrà anche lo stesso tipo di efficienza del difensore: anche lui creerà una password con un costo (in media) 10 volte il costo di invocare la funzione hash. Quindi, ancora una volta, il vantaggio di sicurezza del X casuale è annullato.

^{(*) Questa è una nozione piuttosto ottimistica.}

Riepilogo: il fattore X , casuale o meno, non aumenta la sicurezza. Implementato correttamente, non dovrebbe ridurlo molto, ma poiché rende il codice più complesso e rende anche il carico meno prevedibile, posso solo sconsigliare quel meccanismo extra.