La lunghezza tonda sconosciuta rende l'hash non incrinato?

1

Quindi sono impegnato in un aggancio e ho afferrato alcuni hash ma farli scoppiare non è servito a nulla. Credo di conoscere il tipo di hash (PBKDF2-HMAC-SHA256) ma non sono sicuro di quale dimensione arrotondata hanno usato. Questo mi ha fatto pensare che questo non lo rende impossibile da decifrare o mi manca qualcosa. Perché anche se dici che conoscevi la password in testo semplice e salt (ovviamente uno scenario molto elaborato) avresti ancora bisogno di provare ogni dimensione rotonda finché non hai trovato quello che hanno usato.

Questo pensiero è corretto o mi manca qualcosa?

EDIT: Questa è una informazione importante che guarda indietro e mi scuso per le confusioni riguardo ai round mancanti. L'applicazione restituisce gli hash in due parti diverse di un oggetto JSON. {..., "Password": "(Base64encoded (27 caratteri))", "PasswordSalt": "(Base64encoded (24 caratteri))" , ...}. Ecco perché gli hash non includono un identificatore di round.

Quindi PBKDF2-HMAC-SHA256 proveniva da come memorizzavano le password in una parte diversa dell'applicazione ed era tutto ciò che riuscivo a trovare tramite OSINT. Guardando le lunghezze delle password e giocando con Python passlib sembra che le password siano memorizzate come pbkdf2_sha1. Posso assicurarmi di aver ragione, ma fare il giro di tutti i round e vedere se ne viene fuori la password che ho. Ci vorrà ancora un po 'da quando, come ha detto la community, 100.000 round non sono inauditi e purtroppo non usano il valore predefinito di 29.000.

MODIFICA MODIFICA: Ho appena eseguito la mia password conosciuta contro il suo hash attraverso tutti i round 1-100.000 e non ho avuto successo. Sembra che la mia intuizione sul fatto che Sha1 fosse sbagliata. Cercando SHA-256 ora con lo stesso approccio.

MODIFICA MODIFICA: beh, la mia speranza si sta esaurendo rapidamente. Ho provato SHA_1,256 e 512 tutti da 1 a 100.000 round e nessuno di essi corrisponde al mio hash. Le lunghezze e i valori di hash sembrano corrispondere perfettamente alla descrizione, ma gli esperimenti sembrano essere diversi.

So che questo non è davvero un forum di programmazione, ma per completezza ecco il codice che stavo usando per controllare il mio hash rispetto a tutti quelli generati.

import concurrent.futures
global quit
from passlib.hash import pbkdf2_sha512
quit = False

def hasher(round, quit):
    if(not quit):
        hash = pbkdf2_sha512.using(salt=(passlib.utils.binary.ab64_decode('xpN14Zl95QQNOKffgsERSw==')), rounds=round).hash('Password').split('$')[-1]
    if(hash[0:5] == '278Vu'):
        print(round) #found it
        quit = True
    if(round % 5000 == 0):
        print(round) #status update


exec = concurrent.futures.ThreadPoolExecutor(max_workers=4)
print("Execing")
for i in range(1,100001):
    exec.submit(hasher,i, quit)

MODIFICA MODIFICA MODIFICA: Sembra che lo strumento di identificazione dell'hash qui link li abbia etichettati come password di Peoplesoft. Non sono sicuro se questo è un falso positivo perché l'applicazione non sembra utilizzare peoplesoft ovunque. Inoltre sembra che gli hash di Peoplesoft non siano salati e la mia restituisca un sale. C'è un post sull'argomento qui, link ma è vago. Qualsiasi aiuto in questo senso?

    
posta staticFlow 09.06.2018 - 09:05
fonte

1 risposta

1

Questo di solito sarebbe solo una barriera lieve e temporanea al cracking.

Lasciare fuori il numero di round sarebbe un sottile strato di oscurità. L'unico modo in cui un tale hash potrebbe anche lavorare sarebbe se il software avesse un metodo hard-coded o algoritmico per determinare il numero di round. In modo che il software potrebbe semplicemente essere decodificato per scoprire il numero di round.

Sarebbe anche piuttosto insolito. La maggior parte dei formati hash che utilizzano rounds include il numero di round come parte dell'hash stesso (il "1000" in questo esempio, preso da la lista degli hash di hashcat di esempio ):

sha256:1000:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

Ciò significa che la soluzione più semplice è semplicemente generare una versione dell'hash con molti numeri di round:

sha256:1:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:2:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:3:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:4:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:5:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

... e poi feed tutti di loro al tuo software di cracking. (Poiché il numero di round in questo formato hash è progettato per essere variabile, il software di cracking dovrebbe essere in grado di gestirlo correttamente.)

Detto questo, di solito c'è un limite superiore pratico al numero di round - oltre il quale sarebbe necessario troppo tempo perché gli utenti interattivi tollerino l'attesa per la verifica della password. 100.000 round sarebbero piuttosto insoliti, ma non impossibile . Ma se si tratta di un'applicazione personalizzata e su misura, un numero insolitamente elevato di round potrebbe essere tollerabile. Quindi, se si tratta di un'applicazione su misura, provare a "nascondere" il numero di round potrebbe renderlo un piccolo più difficile per l'attaccante. E poiché PBKDF2 è un hash piuttosto lento, se supponiamo che il difensore abbia selezionato un numero piuttosto elevato di round, questo approccio potrebbe effettivamente rendere le cose più difficili.

Quindi, se un attacco a turni da 1 a 50.000, usando comuni elenchi di parole e attacchi, non ha prodotto alcun risultato in un giorno o due ... Sarei propenso a pensare che potrebbe essere un tipo di hash diverso - e probabilmente proverebbe anche ad afferrare il software / firmware che genera / verifica gli hash e lo decodifica. In realtà, probabilmente lo farei comunque perché stavo aspettando che finisse il crack. :)

    
risposta data 09.06.2018 - 16:31
fonte

Leggi altre domande sui tag