È stupido non salvare gli ultimi due caratteri dell'hash della password

Regola numero uno della crittografia: non eseguire il crypto . Stai prendendo un algoritmo di crittografia standard e stai scherzando. Se l'algoritmo o la combinazione di algoritmi che stai utilizzando non è stato valutato dai ricercatori di sicurezza negli ultimi anni, hai un'idea no se hai creato una vulnerabilità o meno. Interrompi subito . L'utilizzo di algoritmi standard e ampiamente testati è la cosa più sicura da fare.

Inoltre, la tua domanda commette due pessimi errori in termini di sicurezza di hashing della password:

1. Stai utilizzando un singolo hash SHA-1. SHA-1 è troppo veloce; è rotto per l'hashing della password. Vedi qui o qui . (Nota che il mio uso della parola "singolo" non implica che dovresti semplicemente applicare SHA-1 in modo iterativo. C'è dell'altro.)

2. Hai fondamentalmente frainteso ciò che un tavolo arcobaleno è per. Una tabella arcobaleno è un insieme di dati precompilati che possono essere utilizzati per cercare in modo più efficiente gli input corrispondenti per gli hash. Il problema è questa affermazione:

   If someone were to get my database they could theoretically create a rainbow table for every user and have at it until they crack it.

   Se un utente malintenzionato deve generare una tabella arcobaleno per utente , la tabella arcobaleno non è migliore della sola forzatura brutale di ciascun utente. Hai già reso inutilizzabile la tabella arcobaleno utilizzando un sale unico per utente.

Mostra che non hai una buona conoscenza della sicurezza delle password o della crittografia. I due errori in cui ti sei imbattuto hanno solo bisogno di passare la conoscenza dei soggetti da evitare. Quindi sicuramente non dovresti cercare di sviluppare i tuoi schemi di sicurezza finché non avrai acquisito molta più conoscenza. (So che è dura, ma ci hai chiesto di fermarti.)

Possiamo anche invocare principio di Kerckhoffs . Il principio di Kerchoff afferma che il sistema dovrebbe rimanere sicuro anche se l'hacker conosce tutti i dettagli dell'implementazione. Il motivo per cui è così importante è che gli aggressori sono in realtà molto, molto intelligenti nel capire i dettagli del tuo sistema, anche con dettagli sorprendentemente pochi. Quindi valutiamo il tuo cambiamento in questa luce. Questa modifica offre un vantaggio qualsiasi se l'attaccante lo sa? No, non è così. Un utente malintenzionato può facilmente modificare il proprio modello di attacco per risolvere il problema una volta scoperto.

In effetti, c'è qualche possibilità che potrebbe essere un danno. Usando un hash più breve, garantisci che ci saranno più collisioni con altre password, il che potrebbe rendere più facile per un utente malintenzionato ottenere un accesso non autorizzato al tuo sistema trovando una password con lo stesso hash. Da quanto? Non lo so. Forse non molto; Non impiegherò molto tempo a risolverlo perché ci sono molti altri argomenti a sfavore di questo aiuto.

In conclusione: non tirare la tua cripta. Gli attuali algoritmi standard probabilmente non sono perfetti, ma sono molto più duraturi di qualsiasi altra cosa io o te riusciremo a trovare.

Come hai sottolineato nella domanda, tutto ciò che stai facendo facendo cadere l'ultima parte dell'hash sta creando più stringhe di password considerate password valide per quell'utente.

In effetti ciò significa che in quanto vi sono più password valide, è più facile trovare solo una password che funzioni.

L'utente malintenzionato non ha bisogno di trovare la stessa password utilizzata dall'utente.

In breve, è una cattiva idea.

Sì, è stupido.

Stai contando su un po 'di oscurità (due caratteri abbandonati) per un hash leggermente più debole. Dato che le dimensioni degli hash tendono ad essere ben note, non mi aspetto che questa sia una barriera significativa.

C'è un caso in cui la tua idea potrebbe aiutare: se alcune organizzazioni di hacker hanno creato enormi tabelle arcobaleno e fornisce un'interfaccia web in cui inserisci un hash a 128 bit e ti dicono la password (se disponibile). Dal momento che un utente malintenzionato avrebbe solo 112 bit, avrebbe dovuto consultare quell'interfaccia web fino a 65.536 volte, 32.768 volte in media, per ottenere la password.

Ma non è realistico. Se l'hacker può solo modificare leggermente il codice che cerca un hash in queste tabelle arcobaleno, cercare un codice con gli ultimi 16 bit mancanti è altrettanto facile che cercare il codice completo.

Ma l'hacker non dovrebbe essere in grado di usare le tabelle arcobaleno, e in effetti non lo sono. Questo perché stai usando un sale diverso per ogni password, più un altro sale per la tua applicazione. Quindi ogni singolo hash deve essere rotto individualmente.

E spezzare un hash per le password significa che l'hacker deve provare ogni singola password finché non trova quella giusta. Dal momento che si memorizzano solo 112 bit, provando sistematicamente 4 milioni di miliardi di miliardi di password troveranno una password che può essere utilizzata per accedere a un account. Molto probabilmente non è la password effettiva dell'utente, quindi non può essere utilizzata per accedere ad altri siti in cui è stata utilizzata la stessa password. Tuttavia, non è possibile creare un hash della password in questo modo. Invece, per esempio, trovi le 10 miliardi di password più probabili e provale. Ora, se l'hacker trova una password che blocca i 112 bit corretti, la probabilità è una su 250.000 miliardi di miliardi che non sia effettivamente la password giusta, è trascurabile.

Quindi il tuo schema non fa nulla per migliorare la tua sicurezza e la sicurezza dell'utente. A meno che tu non abbia usato uno schema che è totalmente insicuro in primo luogo, cosa che non stai facendo.

Devo ammettere che all'inizio questa idea sembrava interessante ..

Tuttavia, il costo reale del recupero di una password salata è che l'utente malintenzionato non può utilizzare una tabella arcobaleno tradizionale (già con hash) e deve utilizzare il sale per generare l'hash per un elenco di password comuni.

L'utente malintenzionato potrebbe notare che mancavano 2 caratteri e bastava rilasciare 2 caratteri dal loro hash generato .. il loro processo non cambierebbe diversamente da quel dettaglio.