Conteggio iterazione specificato dall'utente

2

Sto lavorando su un sistema di autenticazione e registrazione PHP seguendo lo standard salt + password = 'auth hash' e utilizzando il nome utente in chiaro / non crittografato come campo di ricerca nella query iniziale. Per l'intento di questa domanda, supponiamo che sto usando un peperone globale (probabilmente ne aggiungerò uno prima della fine, quindi facciamo finta di averlo già fatto).

Qualcosa mi ha colpito come un concetto forse interessante. Mi rendo conto che dicono " non reinventare la ruota quando si tratta di sicurezza ", ma stavo considerando di consentire un numero di iterazioni 'specificato dall'utente' per PBKDF2.

Ora, non intendo che l'utente abbia il controllo sul numero di iterazioni, ma piuttosto un numero casuale tra X e Y viene generato in fase di esecuzione e quindi quel valore è memorizzato, in chiaro, come un campo separato in il database nello stesso modo in cui si memorizza il sale. Capisco che l'algoritmo sia già visto come estremamente sicuro pur essendo semplice da implementare, ma immagino che un ulteriore 'livello' renderebbe ancora più difficile l'attacco di un utente malintenzionato.

Per ragioni di semplicità (e continuità nell'uso dei prodotti alimentari), chiamiamo "salsa" il conteggio iterativo casuale. Ad esempio;

  • Pepper è già presente nel DB e viene recuperato in una variabile
  • L'utente si registra con nome utente e password
  • Salt è generato
  • Sauce è generato e deve essere compreso tra 16000 e 32000 iterazioni ( numeri teorici )
  • Hash viene generato da sale + password + pepe + salsa
  • Nome utente, hash, sale e salsa sono memorizzati nel DB

Poiché "salsa" è memorizzato come testo normale, lo stesso algoritmo sarebbe adattivo basato su ciò che è memorizzato nel database (proprio come con sale), e ancor più al punto, scegliere un numero tra X e Y è generalmente abbastanza veloce.

Ancora una volta, non sono preoccupato che un utente malintenzionato possa rompere una chiave di output hash a 512 bit SHA512 passata attraverso 32000 (esempio numero) di iterazioni e sale e pepe in un ragionevole lasso di tempo, e sicuramente non potevano generare un tavolo arcobaleno contro di essa. Sono più interessato alla prospettiva di poter espandere ulteriormente il progetto, relativamente facilmente, avendo pochissime spese generali aggiuntive sul lato 'difensori', ma aggiungendo ulteriori costi generali al lato degli attaccanti, potenzialmente scoraggiandoli completamente, e senza bisogno di adattarsi l'algoritmo di hash stesso.

Puoi impostare i tuoi minimi e massimi conteggi di iterazione entro il raggio di ciò che il tuo ambiente può gestire e quindi continui a mantenere un controllo significativo sulla sicurezza relativa del sistema e non permetti mai ai tuoi utenti finali di specificare il proprio valore (per le prestazioni ragioni, e per la ragione che probabilmente sceglieranno qualcosa di memorabile annullando completamente il tuo passo in più, e per creare una bella UX). In ambienti in cui la sicurezza è di fondamentale importanza, sicuramente avere questi piccoli passi in più potrebbe funzionare a vantaggio dei difensori.

Avrebbe questo livello extra non fornire ancora un altro cerchio per un attaccante di saltare attraverso? Pensieri?

    
posta Scott Pritchard 07.06.2013 - 21:47
fonte

3 risposte

3

La salsa non è un cerchio in più. L'attaccante non trae alcun beneficio dal conoscere la salsa in anticipo. Il sale gli impedisce di fare comunque utili precomputazioni.

Il numero ottimale di iterazioni è determinato da un compromesso tra la potenza di calcolo disponibile e la potenza di calcolo disponibile per un tipico aggressore. Certo, è difficile quantificarlo con precisione, ma ciò nonostante la randomizzazione può solo rendere il valore risultante meno ottimale.

Se l'attaccante vuole entrare nell'organizzazione e non gli importa molto quale account ha violato, è probabile che i conti con la salsa più bassa cadano per primi (anche se la complessità della password avrà maggiore influenza). La randomizzazione fa più male che aiuta in questo scenario, poiché rende più debole il collegamento più debole senza una compensazione adeguata dal tempo di elaborazione ottenuto.

La tua salsa casuale è una complessità extra, anche se sono solo un po '. La complessità è il nemico della sicurezza, è un'altra cosa che potresti sbagliare per sbaglio (ad esempio, una salsa minima troppo bassa).

In conclusione, raccomando un conteggio di iterazioni fisso, che cambia di volta in volta man mano che i processori diventano più potenti.

    
risposta data 07.06.2013 - 22:06
fonte
2

Nello scenario:

  • Ho le tue password, hash
  • Si utilizza salt, nel modo corretto, quindi non è utile per le mie tabelle arcobaleno precalcolate
  • Dovrò usare la forza bruta usando il sale che ho già, e pepe e salsa ...

Bene, prima di tutto, devo solo portare la mia insalata, perché i condimenti sono dati da te:)

In secondo luogo, avrò il numero di iterazioni, dal momento che è come il sale, che non è tale segreto.

Ma anche se non ce l'ho, dovrò calcolare tutte quelle iterazioni. Se so che saranno da 16.000 a 32.000, metterò semplicemente alla prova il mio risultato dopo il 16.000esimo. Secondo il tuo schema, invece di dover iterare fino a 32.000, forse sono fortunato e ottengo il risultato prima. Non so se testarlo richiederà più potenza di calcolo rispetto al calcolo di ogni nuova iterazione, quindi forse vale la pena provare ...

E, infine, le tavole arcobaleno sono un modo per ottimizzare i valori pre-calcolati, non è una semplice tabella di ricerca .

    
risposta data 07.06.2013 - 22:05
fonte
2

Vuoi che il tuo numero di iterazioni sia tanto alto da poterlo tollerare in base alle prestazioni del tuo sistema e al sovraccarico di calcolo atteso che questo aggiunge al tuo processo di autorizzazione, e sicuramente non è regolabile in modo per utente . Inoltre, dovrai mantenere questo valore da qualche parte, il che significa che non può essere considerato un segreto, quindi non stai davvero rallentando o fermando l'aspirante attaccante, stai semplicemente fornendo una possibilità che potrebbe finisci il suo compito di forzare i singoli hash più velocemente, rispetto al massimo numero di iterazioni con cui puoi convivere.

Oh, e perché il tuo numero di iterazioni non può essere tenuto segreto? Bene, semplice. Anche se hai usato uno schema davvero geniale per proteggere quel valore, lo userai in seguito, e diversi valori di iterazione si tradurranno in un diverso overhead di elaborazione - qualcosa che un utente malintenzionato può controllare con ciò che viene chiamato timativi attacchi . Un utente malintenzionato potrebbe utilizzare anche il tuo sistema live per determinare con una precisione relativamente buona il conteggio delle iterazioni utilizzato per ciascun account.

    
risposta data 07.06.2013 - 22:12
fonte

Leggi altre domande sui tag