Ho visto domande simili sul sito ma non esattamente.
Il più vicino era Modifica delle password prima di memorizzare dove la risposta accettata è riassunta da affermando che la trasformazione della password è spreco di cicli della CPU che potrebbero altrimenti andare in conteggio delle iterazioni più alte sul tuo hashing effettivo.
Anche se molto è corretto, considera il seguente scenario:
Supponiamo che l'applicazione utilizzi un host per il codice dell'applicazione e un altro host per il database / l'archivio. È possibile che in futuro il database venga compromesso, ma il codice dell'applicazione rimarrà segreto.
Se ciò accade, l'attaccante può tentare di rivelare le password degli utenti con una combinazione di forza bruta o elenchi di parole con espressioni regolari, qualcosa che è probabile che porti alla luce almeno alcune password e altro ancora con il passare del tempo.
Ovviamente, se hai scoperto che il tuo database è stato compromesso, avresti ripristinato tutte le password utente. Ma nel delta tempo tra il fatto che è stato effettivamente compromesso e tu lo scopri, l'attaccante ha un potenziale vettore di attacco per accedere agli account vulnerabili di alcuni utenti.
Quindi ho pensato, in particolare per questo scenario, non semplicemente aggiungendo alcuni dati spazzatura alle password degli utenti prima che l'hashing rendesse questo vettore di attacco molto più debole? (per esempio, rendi più difficile per un utente malintenzionato rivelare le password in tempo utile prima di scoprire cosa è successo e ripristinarle)
Non sto parlando di trasformazioni generali, ma piuttosto di appendere perché: 1. assicura che tutte le password rimangano uniche dopo la modifica, quindi non perdono entropia. 2. È un compito di calcolo relativamente a basso costo nel processo di un server che accetta i moduli di registrazione e le risposte di formattazione. 3. è semplice e non aggiunge complessità del codice che renderebbe l'applicazione più difficile da mantenere in futuro.
La stringa da aggiungere sarebbe una stringa costante, memorizzata in un posto nel codice dell'applicazione. Ovviamente, se il codice dell'applicazione viene compromesso, l'intera faccenda è inutile. Ma se solo gli hash delle password degli utenti sono stati compromessi:
- sarebbe davvero efficace nel rallentare un aggressore? (per esempio, impiega più tempo a rivelare le password degli utenti usando metodi moderni)
E, in generale:
- introdurrebbe qualche nuova vulnerabilità nel sistema?
Esempio:
Il server delle applicazioni ha una stringa costante: "! @ # $% ^ & () ,;"
User A registra con la password "secretpassword"
Il server concatena i due, creando: "! @ # $% ^ & () ,; secretpassword"
Quindi bripta la nuova stringa e memorizza l'hash risultante nel database.
Per ogni tentativo di accesso futuro, la stringa costante verrà aggiunta all'inizio della password dell'utente (sul server) prima di ricalcolare l'hash.
Ora diciamo che ho un milione di utenti e un utente malintenzionato ha ottenuto un milione di hash di password che la mia applicazione utilizza per autenticare gli utenti. L'hacker sa anche che sto aggiungendo una stringa costante all'inizio delle password degli utenti sul server, infatti lo sto affermando pubblicamente sulla mia GUI del registro. Tuttavia, l'autore dell'attacco non conosce la stringa effettiva che sto aggiungendo.
l'account di User A è più sicuro (ad esempio, richiederebbe più tempo all'attaccante di rivelare la sua password originale "secretpassword" o trovare un modo per accedere al proprio account e acquisire i propri dati) o sarebbe lo stesso?
qualche altro User X diventerebbe meno sicuro ora a causa di questo cambiamento, o nessun altro utente ne risentirebbe in peggio?