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?