Migliorare la sicurezza aggiungendo tutte le password con una stringa lunga fissa?

No, non è una buona idea. Poiché la stringa aggiunta è pubblica, l'utente malintenzionato lo aggiungerebbe anche a tutte le parole del dizionario quando esegue un attacco di forza bruta.

Sostieni che l'aumento del tempo dall'annullamento di una lunga stringa invece di un corto rallenterebbe l'attacco, ma l'effetto sarebbe probabilmente piccolo. Ancora più importante, le funzioni di hash moderne come PBKDF2 e bcrypt sono già progettate per essere lente e avere una build in grado di renderle più lente, consentendo di impostare un parametro del fattore di costo. Se vuoi rallentare un attaccante, aumentalo. Non c'è bisogno di inventare la tua soluzione per la preparazione della tua casa.

Se non si utilizza un algoritmo di hashing della password moderna, questo è il momento di correggi anziché considerare gli hack come questo.

Se dovessi mantenere segreta la stringa (aggiungendola al server invece che al client), allora sarebbe pepe . Questa è una tecnica comunemente usata per aumentare la sicurezza degli hash delle password, ma si potrebbe sostenere che solo la crittografia degli hash è una soluzione migliore.

Sì e no. Se modifichi la tua soluzione un po ', aggiungi un sacco di byte casuali sul lato server e diversi byte casuali per ogni utente, avrai un' sale ', è un buon approccio e rende le tue password resistenti alle tabelle arcobaleno.

Ma nel tuo caso, no, farai solo un casino. Pensa alla migrazione di questo sistema, alcuni codici javascript sul lato client, saranno difficili da trovare e portati. Come hashing / salting delle password è qualcosa che è quasi un modello universale da implementare sul lato server.

Riguardo alla complessità del cracking, parliamo del tuo scenario. Immaginiamo che un utente malintenzionato ottenga l'intero database, 10k utenti e che conosca il prefisso casuale di 102400 byte e che tutti gli utenti utilizzino lo stesso prefisso. Se si usa md5 per esempio (cosa che non raccomando), si hanno i cicli di elaborazione, in cui una certa quantità di dati viene letta ed elaborata nell'algoritmo, cambiando il suo stato interno, che cambierà il valore hash finale.

Se si dispone di una stringa grande iniziale, è sufficiente immetterla nell'algoritmo md5, quindi copiare lo stato della memoria (detto anche contesto) e aggiornarlo semplicemente con la password che si sta tentando. Dopodiché, se la password è sbagliata, ti basta rilasciare quello stato di memoria (o libero, come vuoi chiamare questa operazione), ripristinare lo stato calcolato precedente e aggiornarlo di nuovo con la prossima possibilità.

Tecnicamente parlando, non c'è molto miglioramento nella soluzione.

L'hashing con metodi moderni di solito non richiede molto tempo con qualsiasi oggetto di piccole dimensioni. Usare qualcosa di più lento, come SHA1, diventerebbe molto più lento in relazione alla dimensione della stringa, ma è esso stesso insicuro. Se il tuo 'sale' (la stringa da 1kb) è pubblico, allora non aiuta molto con l'attacco del dizionario. Tuttavia, interromperà un attacco da tavolo arcobaleno usando un algoritmo di hash standard a meno che l'attaccante non compili da solo.

Forse, se hai archiviato un elenco di hash salati casualmente insieme ai requisiti di gestione della password utente, sarebbe più sicuro.