Come stimare il tempo necessario a un hacker per decifrare una password complessa

Non è possibile rispondere al tempo necessario per craccare una password senza sapere come viene creata la password. Se crei una password in base al tuo compleanno (o parente), indirizzo, secondo nome, ecc., Si presume che sia una password settimanale a causa di Principio di Kerckhoffs . Dato che non sai se un utente malintenzionato conoscerà queste informazioni, è meglio presumere che lo faranno e che conoscono il formato che hai deciso di utilizzare.

Per motivi di dimostrazione, supponiamo che non sappiano nulla della tua famiglia, ma sanno che hai formattato la tua password come My[B0y or G1rl][day of month with suffix][abbreviated month][symbols on keyboard corresponding to year] . Ci sono 2 possibilità per ragazzo o ragazza, 365,25 per mese e giorno, e siamo generosi e diciamo 50 per anno. 2 * 365,25 * 50 = 36,525. Non è niente. Un utente malintenzionato potrebbe provare centinaia di metodi simili senza dover eseguire un numero significativo di hash.

L'unico modo per stimare in modo affidabile la forza della password è basare la stima sul metodo di generazione della password . Se il metodo di generazione della password consiste nel generare 10 caratteri alfanumerici casuali, selezionerai casualmente 1 password da un set di 62 ¹⁰ password. In media, un utente malintenzionato indovina la tua password dopo aver provato metà delle possibili password, quindi a meno che non diventino estremamente fortunati dovranno indovinare circa 62 ¹⁰ / 2 = 419649682934170112 volte prima di indovinare il tuo (di Naturalmente questo potrebbe essere più alto o più basso se sono fortunati).

Questo benchmark 8x GTX 1080 è in circolazione da un po 'di tempo, se assumiamo che ciò che viene usato da un utente malintenzionato, può fare 200 miliardi di hash md5 o 826 bcrypt * hash al secondo. Se sei preoccupato di avere una stanza piena di ASIC, prendi quei tempi un miliardo (anche se bcrypt è piuttosto resistente agli ASIC). Il peggiore dei casi con bcrypt è 62 ¹⁰ / 2/826000000000 = 508050 secondi, che è solo pochi giorni, ma per quanto ne so, gli ASIC di bcrypt sono ancora improbabili che esistano (o siano così veloci se esistono). Certo, potresti facilmente migliorare molto usando 12 o 15 caratteri casuali invece di 10.

_{* Supponendo un costo di 12; il benchmark fornisce 105,7 kH / s con costo 5, quindi 105700/2 ^ (12-5) ≈ 826 H / s.}

La risposta breve è che non c'è risposta e il tempo necessario per craccare una password è direttamente proporzionale alla 1) lunghezza e 2) complessità. Questo è direttamente dalla SANS org:

Strong passwords are long, the more characters you have the stronger the password. We recommend a minimum of 14 characters in your password. In addition, we highly encourage the use of passphrases, passwords made up of multiple words. Examples include “It’s time for vacation” or “block-curious-sunny-leaves”. Passphrases are both easy to remember and type, yet meet the strength requirements.

Se hai una password complessa e lunga (ad esempio 16+ caratteri, potrebbero essere necessari anni per crack.Tuttavia, anche una lunga password è suscettibile di cracking SE si utilizzano parole del dizionario, o utilizzare una parola e ri-organizzare le lettere con numeri o simboli (ad es. P @ $$ w0rd non è una buona password, anche se include numeri, lettere maiuscole e simboli).

Ti incoraggio a utilizzare un generatore di password casuale come questo .

Infine, le password stesse non sono sufficienti per proteggere il proprio sito o la propria infrastruttura. Prendi in considerazione l'esecuzione di test di penna, scansioni, valutazioni delle vulnerabilità e strumenti come fail2ban . Le iniezioni SQL sono relativamente facili da proteggere sanitizzando l'input ma richiedono tempo per comprendere prima le vulnerabilità. Se si protegge semplicemente la password, qualcuno può ancora usare il pass-the-hash o qualche altro exploit per hackerare il tuo sito. La sicurezza è un approccio a più livelli, quindi concentrarsi su un errore di sicurezza specifico non è un approccio saggio.

Mentre altre risposte qui trattano la domanda posta, ho l'impressione che l'OP non stia davvero affrontando il problema. Quindi questo è davvero un commento piuttosto che una risposta.

getting the hash of admin password...without knowing the SALT

Ciò implica piuttosto che il sale sia tenuto indipendentemente dall'hash, il che suggerisce che il sale non sia generato casualmente e sia univoco per ogni account. Non va bene.

just sql-injected our website

Anche se presumo che si stia già cercando di prevenire le vulnerabilità di SQL injection, ciò implica anche che l'applicazione abbia accesso diretto alle tabelle contenenti informazioni di autenticazione. Erk! Anche se si correggono le vulnerabilità SQLI note, l'accesso dell'applicazione a questi dati dovrebbe essere mediato tramite procedure SQL con separazione dei privilegi.

Obviously we will have to change the algorithm to something unpredictable

No.

In primo luogo, sha256 è solo una parte dell'algoritmo che usi per convalidare le password. Ci sono molte altre cose da considerare qui. La semplice sostituzione di sha256 con qualcosa che è computazionalmente più costoso non risolverà un problema altrove nella convalida della password.

Ti incoraggio a considerare l'immagine più grande.

Nella sua risposta, SomeGuy suggerisce di usare una password grande e casuale. Anche se questo risolverà la forzatura bruta dell'hash, non aiuta ancora se hai fatto un errore altrove. Significa anche che è più probabile che le persone registrino la password da qualche parte. Spero che lo facciano in un gestore di password appropriato piuttosto che in una nota post-it, ma anche i primi non sono necessariamente affidabili al 100%. Hai aumentato la superficie di attacco.

we would change password every month.

Sia il NIST che il GCHQ hanno contestato questa saggezza ricevuta relativamente di recente. Certamente non avrebbe fornito alcuna protezione contro l'attacco che descrivi. Come nella discussione sulla complessità della password, più frequentemente cambi una password, più è probabile che venga comunicata e scritta.

Dato che puoi cambiare il codice dell'applicazione e il suo open source, ti consiglio:

• dai una occhiata lunga al codice intorno alla chiamata a sha256 () - assicurati di utilizzare una funzione di estensione della password

• usi sali unici generati casualmente per ogni account

• implementa l'autenticazione a due fattori (con una funzionalità che consente l'attivazione in base al privilegio o alla preferenza dell'utente)

• consideri l'isolamento dei privilegi dei dati hash della password