Alfonso Maruccia

Crackare password? Una passeggiata di salute

Ars Technica organizza un singolare esperimento con tre specialisti nel crackare password. Il risultato? Basta un'ora per ottenere decine di migliaia di codici con hardware non particolarmente spinto

Roma - Una peculiare competizione tra hacker e smanettoni del codice organizzata da Ars Technica evidenzia la facilità con cui è possibile crackare le password usate dagli utenti - anche quelle apparentemente dotate di una certa complessità e composte da almeno 16 caratteri.

Il contest ha visto la partecipazione di tre diversi cracker, a cui il reporter di ha fornito più di 16mila password in forma di hash crittografico calcolato - a partire dalle password di cui sopra - con algoritmo MD5.

Dopo un'ora dall'inizio del contest, Jens Steube - noto per essere lo sviluppatore di oclHashcat-plus - è riuscito a battere l'82 per cento delle password (13.486) usando un singolo computer e un paio di GPU. Il risultato peggiore è stato quelli di tale radix, che ha crackato "appena" il 62 per cento delle password di cui era stato fornito l'hash.
La conclusione dell'esperimento è chiara: l'utilizzo di password costituite da nomi o parole comuni nell'epoca delle multi-GPU e degli algoritmi super-ottimizzati è pura follia, e persino password come "qeadzcwrsfxv1331" (in teoria piuttosto sicura) hanno ben poca speranza contro hacker e personale specializzato. O contro qualcuno che è disposto a pagare per il crack.

Alfonso Maruccia
47 Commenti alla Notizia Crackare password? Una passeggiata di salute
Ordina
  • Non dico che ho trovato proprio tutte le password che cercavo, ma buona parte sì, grazie a http://www.md5decrypter.co.uk/
    non+autenticato
  • - Scritto da: Mino
    > Non dico che ho trovato proprio tutte le password
    > che cercavo, ma buona parte sì, grazie a
    > http://www.md5decrypter.co.uk/

    Evidentemente usi delle password ridicole perché ho fatto varie prove con due parole italiane concatenate e non ne ha trovata manco una!
    non+autenticato
  • - Scritto da: emmerdal
    > - Scritto da: Mino
    > > Non dico che ho trovato proprio tutte le
    > password
    > > che cercavo, ma buona parte sì, grazie a
    > > http://www.md5decrypter.co.uk/
    >
    > Evidentemente usi delle password ridicole perché
    > ho fatto varie prove con due parole italiane
    > concatenate e non ne ha trovata manco
    > una!

    Ho provato con ciao e l'ha trovata, poi sono passato a ciaociao e ok, poi con ciaociaociao e le ha trovate e quindi ho pensato di farla più difficile con ciaociaocia e ha fallitoTriste
  • Uno (Uno!) (Uno!)
    Due! (Due!) (Due!)
    Tre! (Tre!) (Tre!)
    Quattro! (Quattro!) (Quattro!)
    Cinque! (Cinque!) (Cinque!)
    [...]
    Curioso, è la stessa combinazione della mia valigia!


    -----------------------------------------------------------
    Modificato dall' autore il 03 giugno 2013 09.55
    -----------------------------------------------------------
    Funz
    12944
  • ...ma sempre di attacco brute force si tratta, quindi più è lunga e complessa la password, più sarà difficile arrivare al giusto hash.
    Chiaro che se le password sono comuni (o basate sulla geometria della tastiera), con un attacco a dizionario le si trova facilmente.
  • Ho scritto un testo su come dovrebbe essere una password sicura ispirato da questo articolo e dalla discussione su questo spazio commenti, per chi abbia voglia di approfondire e soprattutto di dirmi che scrivo caxxate mi farebbe piacere avere il vostro commento:

    http://www.kensan.it/articoli/Password_sicurezza.p...
  • Ottimo articolo. Sorride
    non+autenticato
  • - Scritto da: seti
    > Ottimo articolo. Sorride

    mi aspetto critiche o suggerimenti di miglioramento: niente da osservare?
  • Ottimo articolo (e ottima discussione, in generale).

    Mi permetto di fare un’unica aggiunta/appunto, premesso che sono _un assoluto profano_, e che quindi potrei dire delle bestialità.

    I ragionamenti che vengono proposti in tutti i commenti, infatti, mi PARE che non stiano tenendo conto di una cosa, ovvero della probabilità statistica.

    Si presuppone infatti che una password composta da 12 lettere/cifre valga 20 milioni di euro di elettricità (e che ci voglia di conseguenza anche un tempo piuttosto lungo per trovarla). Questo però mi pare presupponga anche che il computer preposto al crack trovi la password solo all’ultimo tentativo fatto.
    E se magari invece, per suprema botta di fortuna, il computer azzeccasse la password al primissimo tentativo? La probabilità è infima, ma non è zero. Non solo: se immaginiamo tutte le possibili pwd di 12 cifre stampate, che so, su dei bastoncini da ghiacciolo, e che tutte siano contenute in uno scatolone; non è che il pc, una volta appurato che la pwd che ha “estratto” è sbagliata, la rimetta nello scatolone: la mette da parte! Ergo, la probabilità che la prossima pwd sia quella giusta è aumentata di un tot… e così via man mano che si va avanti (è la classica estrazione senza reimmissione).

    Quindi, secondo me non è detto che una pwd da 12 cifre valga davvero 20 milioni di euro e che ci voglia necessariamente X per crackarla: potrebbe volerci molto meno e, per avvicinarci a capire “quanto” meno ci debba volere, dovrebbero probabilmente essere introdotti nell’equazione anche dei calcoli di media statistica. E probabilmente questi calcoli fornirebbero come risultato che una pwd, per valere 20 milioni di euro, magari dovrebbe essere composta, che so, da 30 cifre e non da 12 (sto sparando numeri a caso), perché dovrebbero essere fatte le medie dei tempi _effettivi_ di crackaggio della pwd in questione.

    Ripeto: sono un profano e non so se in realtà sto parlando del nulla; questo però è l’unico appunto che mi sento di fare all’articolo (che comunque ribadisco essere interessantissimo).
    non+autenticato
  • > E se magari invece, per suprema botta di fortuna,
    > il computer azzeccasse la password al primissimo
    > tentativo? La probabilità è infima, ma non è
    > zero.

    Si applica il teorema della media semplice.

    Se una chiave ha 256 bit (il sistema binario è in base 2) quindi significa che ci sono 2^256 combinazioni diverse.
    Per crackare una password devi quindi testare 2^256 combinazioni diverse... eppure potrebbe capitare che la prima combinazione sia proprio quella giusta.... oppure potrebbe capitare l'opposto: che l'ultima combinazione possibile sia quella giusta. (dal punto di vista "binario" si può dire che il caso migliore equivale a tutti i bit messi a 0, e il peggiore con i bit tutti a 1)
    Si applica quindi il teorema della media, perché non sai in anticipo in quale dei due casi la chiave ricadrà.
    Quindi, in media, ci saranno: 2^(256-1) oppure (2^256)/2 combinazioni da testare.
    Questo include tutti i casi possibili: che la chiave giusta sia nella prima combinazione o nell'ultima, che la chiave giusta sia nella prima-1 combinazione o nell'ultima-1, che la chiave giusta sia nella prima combinazione-2 o nell'ultima-2 ecc... Ogni metà bilancia il suo speculare, per questo si divide per due.

    Non so' quali siano i calcoli che portano a "20 milioni di euro di elettricità", ma assumendo questo, un attacco reale costerà: 10 milioni di euro di elettricità in media, e 20 milioni di euro nel caso peggiore (e 0 euro nel caso migliore -- possibile, ma di fatto sarà improbabile proprio come il caso peggiore)
    non+autenticato
  • Esatto, hai centrato il punto! E' proprio questo l'appunto che mi sentivo di fare all'articolo di Kensan -linkato poco più sopra (e dove trovi anche i calcoli che portano a "20 milioni di euro di elettricità")-, e a tutta la discussione in generale. Ovvero, non capisco se in tutti i calcoli di durata per il break della password che appaiono nei vari post sia già ricompreso questo calcolo di media statistica oppure no.
    non+autenticato
  • - Scritto da: Megadubbio
    > Esatto, hai centrato il punto! E' proprio questo
    > l'appunto che mi sentivo di fare all'articolo di
    > Kensan -linkato poco più sopra (e dove trovi
    > anche i calcoli che portano a "20 milioni di euro
    > di elettricità")-, e a tutta la discussione in
    > generale. Ovvero, non capisco se in tutti i
    > calcoli di durata per il break della password che
    > appaiono nei vari post sia già ricompreso questo
    > calcolo di media statistica oppure
    > no.

    No non è compreso questo calcolo. Però non è importante. Se una password vale 20 milioni secondo il mio testo non bisogna solo considerare che in realtà ci vorranno metà tentativi in media di tutti quelli disponibili ma cnhe il fatto che l'ASIC che ho considerato consuma 6 w*s (j) per Ghash (mi pare di ricordare) ma quento non include il costo (anche energetico) per fabbricare l'ASIC che durerà un certo numero di hash (qualche sestilione di hash?). Poi per avere tempi ragionevoli bisogna avere batterie di ASIC con un certo costo infrastrutturale (UPS, Condizionatori, stabile, sicurezza, ecc).

    Poi gli asic diminuiranno di costo col tempo e aumenteranno di velocità. Insomma il fattore 1/2 è il minimo dei problemi se si vuole calcolare un costo esatto.
  • Si, ma solo i polli usano gli hash così come lo descrivi te (ciò nonostante il 99.998% dei "webmaster" sono proprio esempi di pollastro).
    Ti suggerisco di dare un'occhiata a questi articoli introduttivi per un uso più sicuro delle funzioni di hashing crittografico:
    http://en.wikipedia.org/wiki/Key_stretching
    http://en.wikipedia.org/wiki/PBKDF2
    http://en.wikipedia.org/wiki/Scrypt
    non+autenticato
  • - Scritto da: FreeBSD
    > Si, ma solo i polli usano gli hash così come lo
    > descrivi te (ciò nonostante il 99.998% dei
    > "webmaster" sono proprio esempi di
    > pollastro).
    > Ti suggerisco di dare un'occhiata a questi
    > articoli introduttivi per un uso più sicuro delle
    > funzioni di hashing
    > crittografico:
    > http://en.wikipedia.org/wiki/Key_stretching
    > http://en.wikipedia.org/wiki/PBKDF2
    > http://en.wikipedia.org/wiki/Scrypt

    Il salt lo conoscevo come tecnica, l'atra tecnica, quella di un algoritmo di hash che impieghi molto tempo ad essere eseguito lo immaginavo ma non ne avevo mai letto nulla. Interessante anche il metodo che allarga le risorse di memoria richieste dall'algoritmo.

    Ho letto qualche critica sul salt. Il salt deve essere conservato da qualche parte e non è detto che si riesca a non rivelarlo al cracker.
  • Il salt è la cosa più banale che c'è, ma è utile, e anche se viene rivelato non è un problema. Il suo unico scopo è quello di evitare tabelle pre-compilate.
    Se hai un sito con la password degli utenti: H(password) e qualcuno ha una lista di Hash, può semplicemente vedere se qualche hash corrisponde nella lista. Se nella lista c'è un hash di una password di 20, 25 caratteri e l'hash corrispone a uno del tuo sito, allora trova la password subito nonostante la sua lunghezza. Se invece tu hai le password degli utenti: H(salt || password) dove i due || corrispondono al concatenamento, allora la tabella diventa già inutile. Se ci sono tanti utenti, si può generare una tabella con quel salt e quindi vedere quali hash corrispondono. Quindi è meglio avere un salt diverso per utente. Ad ogni modo, anche con un attacco brute force, il salt significa solo concatenare (o alternativamente in certi casi di XORare) ad un certo punto all'input una costante (l'XOR con una costante non altera mai l'entropia di un input, ma viene solitamente usato solo se si sà che il salt ha la stessa lunghezza di una chiave -- o di un blocco nei cifrari). Si tratta di una costante proprio perchè chi cerca di crakare l'hash, se ti ha fatto un dump del database, il salt lo può leggere da li per ogni utente (perché come hai detto il salt deve essere conservato da qualche parte, quindi solotiamente si conserva insieme/vicino all'hash in cui è stato usato). Quindi si suppone sempre che sia a conoscenza del salt. Il salt dovrebbe essere infatti un nonce. http://en.wikipedia.org/wiki/Cryptographic_nonce Un array/vettore di byte casuali usa-e-getta (relativamente a ogni hash in cui viene usato) che quindi anche se viene reso pubblico non può compromettere niente.
    Anche in crittografia il nonce che viene per esempio usato nel concatenamento dei blocchi solitamente come vettore di inizializzazione lo si dà per "pubblico". Perché la sicurezza di un hash o di un cipher è basata solo sulla chiave e sull'algoritmo utilizzato. Il resto si da per scontato che sia pubblico. Con "algoritmo utilizzato", relativamente agli hash, si intende anche l'utilizzo di pbkdf2 ecc. non solo la funzione Hash in sé.
    non+autenticato
  • - Scritto da: FreeBSD
    > Il salt è la cosa più banale che c'è, ma è utile,
    > e anche se viene rivelato non è un problema. Il
    > suo unico scopo è quello di evitare tabelle
    > pre-compilate.

    Esatto, pure questo l'ho letto. Io non sono un sysadmin ma ho una infarinatura perché ho letto diversi commenti qua e la a livello basilare.

    > Se hai un sito con la password degli utenti:
    > H(password) e qualcuno ha una lista di Hash, può
    > semplicemente vedere se qualche hash corrisponde
    > nella lista. Se nella lista c'è un hash di una
    > password di 20, 25 caratteri e l'hash corrispone
    > a uno del tuo sito, allora trova la password
    > subito nonostante la sua lunghezza.

    Infatti, basta usare un grande data base con gli hash già fatti e una ricerca ad albero su una tabella ordinata scopre la password in pochi passaggi nel DB.

    > Se invece tu
    > hai le password degli utenti: H(salt || password)
    > dove i due || corrispondono al concatenamento,
    > allora la tabella diventa già inutile. Se ci sono
    > tanti utenti, si può generare una tabella con
    > quel salt e quindi vedere quali hash
    > corrispondono. Quindi è meglio avere un salt
    > diverso per utente.

    Certamente. Tra il generare una tabella con un unico salt che vale per tutte le password di un server e il generare una tabella che vale solo per una unica password da scovare c'è molta differenza soprattutto se il server ha un grande numero di hash che si intende invertire.

    > Ad ogni modo, anche con un
    > attacco brute force, il salt significa solo
    > concatenare (o alternativamente in certi casi di
    > XORare) ad un certo punto all'input una costante
    > (l'XOR con una costante non altera mai l'entropia
    > di un input, ma viene solitamente usato solo se
    > si sà che il salt ha la stessa lunghezza di una
    > chiave -- o di un blocco nei cifrari).

    Infatti. L'entropia non varia se si somma una costante e credo anche se si fa un OR esclusivo e pure un sacco di altre operazioni con una costante.

    > Si tratta
    > di una costante proprio perchè chi cerca di
    > crakare l'hash, se ti ha fatto un dump del
    > database, il salt lo può leggere da li per ogni
    > utente (perché come hai detto il salt deve essere
    > conservato da qualche parte, quindi solotiamente
    > si conserva insieme/vicino all'hash in cui è
    > stato usato). Quindi si suppone sempre che sia a
    > conoscenza del salt. Il salt dovrebbe essere
    > infatti un nonce.
    > http://en.wikipedia.org/wiki/Cryptographic_nonce
    > Un array/vettore di byte casuali usa-e-getta
    > (relativamente a ogni hash in cui viene usato)
    > che quindi anche se viene reso pubblico non può
    > compromettere
    > niente.
    > Anche in crittografia il nonce che viene per
    > esempio usato nel concatenamento dei blocchi
    > solitamente come vettore di inizializzazione lo
    > si dà per "pubblico". Perché la sicurezza di un
    > hash o di un cipher è basata solo sulla chiave e
    > sull'algoritmo utilizzato. Il resto si da per
    > scontato che sia pubblico. Con "algoritmo
    > utilizzato", relativamente agli hash, si intende
    > anche l'utilizzo di pbkdf2 ecc. non solo la
    > funzione Hash in
    > sé.

    Nel caso del salt si ritorna al problema di fare un attacco dizionario senza uso delle tabelle oppure quello di fare un attacco brute force. Diciamo che è un sistema di sicurezza per evitare al cracker delle scorciatoie.

    In più mi pare una buona idea quella di usare un algoritmo "lungo" da eseguire. Non ne ho mai sentito parlare e non so la sicurezza di questa soluzione. Questo algoritmo può pure essere invertibile ma deve costare molti cicli di CPU e deve essere sicuro che non ci siano scorciatoie e i cicli non possano essere ridotti ad una manciata.

    Certo che una soluzione facile a questo problema è quello di eseguire un certo numero di volte l'algoritmo di hash:

    for (i=0;i<10000;i++){
    hash=sha256(hash);
    }

    Certo che se l'hash ha dei punti fissi allora si trovano delle collisioni. Forse lo sha256 non ha di questi problemi?

    Comunque ci saranno sicuramente degli algoritmi appositi.
  • Sto guardando gli ASIC che mi pare siano utili per lo sha256 usato per minare i bitcoin.

    https://forums.butterflylabs.com/bfl-forum-miscell...

    questi consumano 6 watt per gigahash al secondo, cioè ogni miliardo di hash questi consumano 6 w*s ovvero circa 0.0003 euro in Italia (la corrente costa circa 20 centesimi al chilowattora).

    In poche parole un terahash costa 0.3 euro.

    la password casuale di 12 lettere maiuscole, minuscole e numeri ha un numero di combinazioni pari a un sestilione ovvero un miliardo di terahash ovvero costa in energia elettrica 300 milioni di euro.

    Anche una password di sole lettere minuscole da 12 caratteri ha 100 quadrilioni di combinazioni ovvero 30 mila euro in corrente.

    Ovviamente questo vale solo per le password casuali e non per qwaszxerdfcv.
  • Per chi vuole crakkare una password il consumo di corrente elettrica è, secondo me, il problema minore. Comunque discorso interessante. Occhiolino
    non+autenticato
  • - Scritto da: dell
    > Per chi vuole crakkare una password il consumo di
    > corrente elettrica è, secondo me, il problema
    > minore. Comunque discorso interessante.
    >Occhiolino

    Certamente il consumo di corrente è il problema minore ma anche il più concreto e il più difficile da sconfiggere. Uno oppure una organizzazione può risolvere tutti i problemi ma non quello del costo economico per crakkare una password.

    Per esempio le organizzazioni statali americane oppure la mafia può sicuramente risolvere il problema "tempo" comprando quanti ASIC desidera e lavorando parallelamente. Può pure ammortizzare facilmente il costo degli ASIC lavorando su un cracking a livello industriale. Ma non può risolvere il problema del costo energetico.

    Il costo energetico è basilare e non è risolvibile, si deve pagare l'energia elettrica e quindi è il vero fattore limitante il cracking indipendentemente da chi lo effettua.

    Per esempio se ho una password casuale che protegge 1 miliardo di euro in bitcoin allora questa deve costare almeno un miliardo di euro in energia elettrica per essere crakkata.
  • - Scritto da: Sandro kensan
    > - Scritto da: dell
    > > Per chi vuole crakkare una password il
    > consumo
    > di
    > > corrente elettrica è, secondo me, il problema
    > > minore. Comunque discorso interessante.
    > >Occhiolino
    >
    > Certamente il consumo di corrente è il problema
    > minore ma anche il più concreto e il più
    > difficile da sconfiggere. Uno oppure una
    > organizzazione può risolvere tutti i problemi ma
    > non quello del costo economico per crakkare una
    > password.
    Posso sempre sfruttare una botnet di pc, a "loro insaputa"Occhiolino
    non+autenticato
  • Fanno sempre tenerezza queste dissertazioni....che danno per scontato che il sistema ti dica se la psw e' ok o no in tempo 0. A bocca aperta
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
1 | 2 | 3 | Successiva
(pagina 1/3 - 14 discussioni)