Domanda:
Si può dire se un'ipotesi di password era vicina al risultato hash?
elmer007
2016-09-16 01:50:17 UTC
view on stackexchange narkive permalink

Ho letto di recente sulla gestione delle password (roba molto interessante!) e mi chiedevo quanto sarebbero diversi gli hash per stringhe simili.

È possibile sapere se un'ipotesi di password era vicina confrontando l'hash risultante all'hash reale?

Ad esempio, se la vera password è "password123" e un hacker prova "Password123", "password1234", "password124", ecc., gli hash generati sarebbero abbastanza simile al vero hash che l'hacker o il suo computer potrebbero dire che erano sulla strada giusta?

Supponiamo che l'hacker conosca sale, pepe, polvere di cayenna, adobo, qualunque cosa ... Se provano la password giusta genereranno un hash corrispondente.

(Penso che questo potrebbe variare a seconda della funzione hash utilizzata, ma non lo so per certo.)

risposta breve: no - altrimenti le tabelle arcobaleno finirebbero per essere * molto * più piccole
L'obiettivo dell'hash è essere il più casuale possibile.Quindi spero di no.
Davvero questa domanda non è mai stata posta prima ???Basta provare e l'hash MD5 di una breve stringa, cambiare una lettera e scoprirlo da soli!http://www.miraclesalad.com/webtools/md5.php
@schroder stai confondendo "non dovrebbe essere" con "no"?
@emory stai confondendo le funzioni hash con le funzioni hash * quote unquote *?
@DmitryGrigoryev Non la penso così.La definizione che uso "Una funzione hash è qualsiasi funzione che può essere utilizzata per mappare dati di dimensioni arbitrarie a dati di dimensioni fisse" Alcune funzioni hash hanno proprietà che le rendono migliori per l'applicazione della password rispetto ad altre, ma il modulo è una funzione hash.Hai una definizione diversa e migliore?
@emory È ovvio dal contesto della domanda che si stanno discutendo le funzioni di hash crittografico.
Nove risposte:
#1
+159
ThoriumBR
2016-09-16 02:12:15 UTC
view on stackexchange narkive permalink

No, non puoi determinare quanto vicino hai indovinato guardando l'hash. Una funzione hash è progettata tenendo presente questo: un singolo bit modificato sull'ingresso deve cambiare molti bit sull'uscita. . La sua chiamata Avalanche Effetto

Bellow sono hash SHA1 per alcune delle vostre password di esempio:

  cbfdac6008f9cab4083784cbd1874f76618d2a97 - password123b2e98ad6f6eb8508dd6a14cfa704bad7f05f6fb1 - Password1232b4bfcc447c3c8726d26c22927a68f511d5e01cc - password124115b55dcc1cd9a0dfdd60c120e83eaf658c45fc6 - cavallo giusto battery stapleabf7aad6438836dbe526aa231abde2d0eef74d42 - corretta graffetta della batteria del cavallo  

Un singolo cambio di bit cambierà completamente il risultato dell'hashing. In effetti, in un caso ideale per ogni bit di cambio di input, ogni bit di output verrà modificato con una probabilità del 50%.

È _ [graffa batteria cavallo corretta] (https://xkcd.com/936/) _ :) (SHA1 `abf7aad6438836dbe526aa231abde2d0eef74d42`)
I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/45501/discussion-on-answer-by-thoriumbr-can-one-tell-if-a-password-guess-was-vicino a).
downvoted per aver cercato di essere intelligente con XKCD ma poi citato erroneamente.
Bene, giusto è abbastanza * vicino * da correggere, il risultato non può essere così diverso
Dovresti notare che questo è vero per gli hash * crittografici *.Questo non è vero se utilizzi, ad esempio, il metodo String.hashCode () di Java o altre funzioni di hashing generiche
@theonlygusti: In realtà, cambiare una parola in un sinonimo _ è_ abbastanza intelligente;sicuramente più intelligente che usare una password di cui tutti ora conoscono l'hash SHA1.
@theonlygusti chi stai votando?Reeno?Come si downvote un commento?Solo curioso
@Mawg Il collegamento pubblicato da Reeno mostra il popolare esempio di "corretta battey a cavallo".ThoriumBR ha fatto un riferimento ad esso nella sua risposta, ma lo ha citato erroneamente come "la graffetta giusta della batteria del cavallo".Quindi theonlygusti sta votando, presumibilmente scherzando, ThoriumBR per aver citato erroneamente un XKCD così popolare.
OIC.Scusa per essere così stupido.Grazie per aver spiegato (+1)
Gli hash SHA1 forniti in questa risposta sono quelli delle password più un cambio di riga (LF) alla fine.Quindi sono completamente diversi dagli hash delle stringhe della password senza il cambio di riga aggiuntivo.
@JiK Non ha molta importanza.Il punto è mostrare che un singolo bit dell'input cambia completamente l'output.
Inoltre, i buoni hash delle password sono salati.
#2
+15
Surendra Patil
2016-09-16 03:31:56 UTC
view on stackexchange narkive permalink

No, grazie all'effetto valanga, anche un singolo cambio di bit nell'input dovrebbe creare una grande differenza significativa nell'output.

Parliamo anche di funzioni di hashing come md5 o altre ... Dato qualsiasi input dimensione la dimensione dell'output non cambierà. In md5 se la dimensione dell'input è di 2 bit o 2000 bit, l'output sarà sempre di 32 cifre in alfanumerico (formato esadecimale). Quindi è quasi impossibile per l'utente normale indovinare la dimensione dell'input anche se ha hashing l'output md5, indovinare la password va ben oltre l'ambito per l'utente normale, tuttavia ci sono modi con il calcolo parallelo di fascia alta applicando algoritmi e molte permutazioni e combinazioni per capire uno dei possibili input se hai il codice hash ...!

 md5 Output: password123 = 482c811da5d5b4bc6d497ffa98491e38Password123 = 42f749ade7f9e195bf475f37abo44cafcbpassword1234c894bc6d497ffa98491e38Password123 = 42f749ade7f9e195bf475f37abo44cafcbpassword1234c894bc6d497ffa98491e38Password123 = 42f749ade7f9e195bf475f37abo44cafcbpassword1234 = bdc879p> 
Si prega di non utilizzare MD5 per eseguire l'hashing delle password (e se è per l'unico motivo che è "troppo efficiente") ..
Ho appena preso un md5 per esempio ... sono consapevole di funzioni hash migliori ...
#3
+13
Jason
2016-09-16 22:06:56 UTC
view on stackexchange narkive permalink

Per aggiungere un ulteriore elemento alle risposte sopra - il punto di una funzione hash è di non perdere il tipo di informazioni nella domanda - se potessi determinare qualcosa sulla somiglianza degli input dal confronto degli output, che rappresenta un fallimento della funzione hash.

Non è solo che le funzioni hash eseguono un certo lavoro e, per inciso, non puoi capire nulla sulla input, il compito della funzione hash è quello di darti zero informazioni sugli input e se potessi scoprire qualcosa sugli input confrontando due output, ciò violerebbe quel principio.

Il punto centrale di una funzione hash ** crittografica **, intendi.
@XiongChiamiov hai ragione - con l'addendum che se hai hash delle tue password con una funzione hash non crittografica, hai incasinato.
#4
+7
TTT
2016-09-16 20:18:06 UTC
view on stackexchange narkive permalink

Dipende dalla funzione hash che usi. Poiché hai specificato un hash della password , quindi inequivocabilmente no , non vorrai mai utilizzare una funzione hash per le password che trapelano qualsiasi tipo di informazione. L'hash dovrebbe semplicemente corrispondere o non corrispondere e il gioco è fatto.

Detto questo, esistono funzioni hash che forniscono informazioni sulla somiglianza; ulteriori informazioni sono fornite in questa risposta.

Esiste solo una funzione hash che non "perde alcun tipo di informazione" e mappa tutti gli input sullo stesso output.
@NajibIdrissi Che trapela le informazioni che c'era un input.
@MichaelKjörling Lo fa?Questa non è in realtà una nuova informazione.Il mio commento non era inteso come uno scherzo, FYI ...
@NajibIdrissi - Sono d'accordo con te.Pedanticamente potrebbe non essere possibile per una funzione hash non far trapelare * alcuna * informazione E anche essere utile per controllare le password.Anche se possiamo avvicinarci abbastanza da renderlo praticamente equivalente.
@NajibIdrissi quella particolare funzione si comporta male quando si tratta di collisioni però ... (j / k)
@TTT "Pedanticamente"?La crittografia è una scienza esatta."Abbastanza vicino" non è "uguale".
@NajibIdrissi - Non sono sicuro di quello che stai chiedendo?Per quanto riguarda abbastanza vicino, non ho detto che era uguale, solo * praticamente * uguale.Come in esso * praticamente * non fa trapelare alcuna informazione, anche se * any * è un'esagerazione (come hai sottolineato.) Se ciò non fosse vero non saremmo in grado di utilizzare in sicurezza alcuna funzione hash per le password.
#5
+4
Joshua Hunter
2016-09-16 02:08:05 UTC
view on stackexchange narkive permalink

No. Non dovrebbe esserci alcuna relazione con i dati che sono entrati nella funzione hash e ciò che viene fuori.

Ad esempio, ecco "ciao" in MD5:

  5d41402abc4b2a76b9719d911017c592 

Ed ecco "Hello":

  8b1a9953c4611296a827abf8c47804d7  
Ebbene, esiste necessariamente una relazione;il punto è che non è trasparente in entrambi i modi.
@AntonSherwood, ovviamente hai ragione.C'è una relazione tra ciò che entra e ciò che esce.Deve esserci se metti la stessa cosa e ti aspetti che la stessa cosa esca di nuovo ogni volta. Ma fintanto che la funzione hash non è stata compromessa, non dovrebbe essere possibile prendere ciò che è uscito e determinare cosa è entrato. Quindi non c'è nessuna relazione ** apparente ** tra dentro e fuori.
#6
+1
Flutter
2016-09-20 15:11:30 UTC
view on stackexchange narkive permalink

Questo è un po 'inverosimile, ma generalmente no - non c'è modo di determinare "quanto sia corretta" un'ipotesi di password da un valore hash. Lo scenario più vicino a cui riesco a pensare sarebbe quando i segmenti della passphrase vengono suddivisi e sottoposti a hashing separatamente, come con LMhash. Questa situazione consentirebbe all'autore dell'attacco di raccogliere informazioni dalle sezioni corrette della password, ma non consentirebbe all'autore dell'attacco di dedurre "quanto vicino" ogni segmento doveva essere corretto.

Altri utenti hanno fornito un'ottima panoramica dell'hashing e dell'effetto valanga, quindi non ne parlerò!

#7
  0
Lucas
2016-09-19 01:56:12 UTC
view on stackexchange narkive permalink

A seconda degli algoritmi utilizzati, potrebbe essere possibile calcolare quanto è vicina la password e questo porta ad attacchi di collisione che consentono di violare la password molto più velocemente della forza bruta.

Come ho capito è il caso di MD4 che può essere rotto in millisecondi a causa di difetti del genere. Non ho analizzato l'exploit MD4, ma scommetto che in esso è incorporata un'equazione di prossimità.

Facciamo un esempio idiota: una funzione hash che è la somma dei codici ASCII della password. Le password AB e BA avranno lo stesso hash 131. Se la password reale è AB, il sistema accetterà anche BA come password reale. Un po 'di reverse engineering mostrerà una relazione: a) cambiare qualsiasi lettera alla successiva ne aggiungerà una nell'hash; b) l'aggiunta di una nuova A alla password aggiunge 65 all'hash. E poi il crack è pronto. La password restituita dalla crack potrebbe non essere la stessa utilizzata dall'utente, ma il sistema non conoscerà la differenza.

Sì, l'obiettivo di un algoritmo di hash crittografico è impedirlo. Dovrebbe essere imprevedibile e quindi richiedere forza bruta. Ma non sempre funziona come previsto. La matematica è imperdonabile.

EDIT: MD4, MD5 e SHA1 sono ormai obsoleti a causa di questo tipo di attacchi. Sono nati nuovi algoritmi per evitare quelle vulnerabilità. E il controllo della password fa qualcosa di più del semplice hashing. L'adozione di nuovi algoritmi non è veloce come vogliamo. Per Linux costantemente aggiornato, le password di base dovrebbero utilizzare algoritmi moderni. Ma scommetto che ci sono molti sistemi al mondo che eseguono software più vecchi di 10 anni perché la nuova versione del sistema operativo potrebbe non essere compatibile con le applicazioni più vecchie o semplice per i costi di licenza se viene utilizzato software a pagamento. Scommetto che molti software che hanno il proprio database di password separato dal sistema hanno una sicurezza debole.

Ma nessuno sta usando MD4, MD5 o anche SHA1 salato in questi giorni, giusto?Usiamo tutti pbkdf2, bcrypt o script?Come hanno spiegato altri poster, anche l'antico MD5 non consigliato produce output molto diversi per input che differiscono solo di 1 carattere, il che significa che no, tentativi di password simili non danno luogo a hash simili.
Aggiunto un commento a riguardo
MD4 è molto più vecchio di 10 anni, così come MD5.MD5 era obsoleto a partire dal 1993, quando SHA0 è stato pubblicato, e un componente di MD5 è stato compromesso nel 1995. SHA1 è stato pubblicato nel 1995, ma una debolezza teorica è stata trovata in SHA1 nel 2005 e da 11 anni fa SHA1 non è più consideratosicuro contro avversari ben finanziati, quindi vuoi usare SHA256 o SHA512, ma non da solo.Così le funzioni HMAC, Pbkdf2, bcrypt, scrypt, re all, che utilizzano funzioni hash, con entropia, come parte dei loro algoritmi, ma non sono SOLO algoritmi hash.
Craig, la domanda di Elmer riguardava gli hash "supponendo che qualcuno conosca tutti i sali, [...]" e altre tecniche usate.
La domanda di Elmer riguardava la gestione delle password
#8
  0
mckenzm
2016-09-19 11:46:00 UTC
view on stackexchange narkive permalink

Sì, puoi, ma devi memorizzare gli hash per i near miss e associarli, quindi lavoro e risorse e possibili problemi di sicurezza qua e là. È possibile, ad esempio, anche ora vedere i "tentativi" di password in chiaro su un sito Wordpress, se qualcuno di questi trova una corrispondenza con una password nota ad alta entropia da qualche altra parte, possiamo dire da dove potrebbe essere trapelata. Esistono ovviamente algoritmi per la generazione di dati con chiavi errate, e questo è ampiamente noto a causa dell'URL accovacciato su errori di ortografia simili, tuttavia dovresti assegnare punteggi per determinare quanto potrebbe essere vicina la corrispondenza e quanto vicino deve essere prima di te allertato. Essenzialmente, se queste fossero parole del dizionario, potresti classificarle in base a Soundex o simili.

Puoi spiegarlo un po 'di più?Non capisco come faresti per determinare che due hash hanno un input simile.
La somiglianza viene determinata prima dell'hashing.Dato che "disneyland" è una password a bassa entropia, potresti generare hash per "disnyland" e "Disneyland" (tra gli altri).Salvo collisioni, avrai un elenco di hash collegati alla password, se ne viene colpito uno, puoi rilevarlo.I criteri per la somiglianza dipendono da te, ma potresti memorizzare 100 quasi mancati, ripetendo o omettendo caratteri dall'originale.Non puoi farlo dall'hash, hai bisogno della password al momento dell'acquisizione.A livello aziendale questo può creare una lista nera per impedire valori seriali come "Summer01", "Summer02" ecc.
Credito per l'idea della lista nera, ma è meglio controllare "abbastanza diverso" quando si specifica una nuova password.Richiedere all'utente di (ri) inserire la vecchia password quindi fornisce il testo in chiaro di entrambi (inoltre, buona pratica da riconvalidare comunque durante la modifica).Vedi anche la risposta e i commenti di Harper.La risposta è ancora "no" per gli hash crittografici, la domanda originale, dal momento che stai effettivamente confrontando con l'hash _other_ (in più hai anche creato il collegamento tra gli hash in base ai valori unhashed / unencrypted).
#9
-1
Harper - Reinstate Monica
2016-09-19 06:34:15 UTC
view on stackexchange narkive permalink

Non guardando l'hash, no.

Ma potrebbero forzare alcune migliaia di password vicine alla password inserita.

Presumendo, ovviamente, che possano aggirare qualsiasi difesa abbia un sito contro qualcuno che fa numerosi tentativi. Ovviamente, il sito stesso ha questa capacità, ad esempio, se vuole verificare se una password è stata semplicemente inserita e non contarla nel numero di tentativi consentito.

Quanti tentativi sarebbero necessari per una password di n caratteri?

  • n per verificare che l'utente stia digitando un carattere in più.

  • (n + 1) * 95 per verificare se manca personaggio in qualsiasi posizione.

  • n per verificare che l'utente inserisca 1 carattere minuscolo invece di maiuscolo o maiuscolo (#) invece di non spostato (3).

  • n (n-1) per verificare la presenza di 2 caratteri minuscoli / non spostati o viceversa.

  • < = 6n per verificare che l'utente digiti inavvertitamente un carattere adiacente invece di questo carattere. (Ad esempio, se si dice una F, sostituire D R T G V C).

  • 12 per verificare che una delle mani dell'utente sia spostata di un punto da dove dovrebbe essere, più qualche altra per i caratteri al centro della tastiera (YGHB) che potrebbe essere colpito da entrambe le mani.

Come puoi vedere, questi numeri non sono eccessivamente grandi e tale analisi è fattibile.

Mi manca il punto di questa risposta.Non stai confrontando un hash con l'hash reale per vedere quanto è vicino, stai costruendo un set di hash basato su input simili.Questo set potrebbe essere utile per convalidare un utente (la chiusura non conta per il numero massimo di tentativi prima del blocco) ma aiuterebbe anche un utente malintenzionato se il set fosse trapelato ("provato valore sbagliato ma la tua chiusura!" O "è necessario provare solo una forma dipassword ma non variante) Esempio: "password" verifica anche "Password", "password1", "password2", "password", "passwordz", ma non il classico blocco maiuscole "PASSWORD" e "PASSWORD".
Non vedo alcun motivo per cui l'host dica all'hacker / utente che è vicino, è solo un'intelligenza interna utile.Se l'hacker ha gli hash e il sale, questo gli consente anche di testare facilmente le password nelle vicinanze di password che potrebbe già avere, ad es.Dall'hacking di * altri * sistemi.Per l'utente questo significa che piccole alterazioni della password non costituiscono alcuna protezione.
Se il cracker ha il set di hash (effettivo + close), il test di 1 possibile password con hash elimina tutte le password che si trovano nel set (se 1000 close, calcola 1 hash e confrontalo con 1001 hash _without_ _recomputing_).Sto assumendo che il db pwd - con tutti gli hash "chiusi" extra - sia trapelato (ma vedi il prossimo commento).
Scenario alternativo di cracking: supponiamo che il cracker (me) tenti di accedere a un login di una pagina web che si blocca per 5 minuti dopo 3 tentativi sbagliati, per 1 giorno dopo 12 e richiede il ripristino dopo 24 ma non conta "abbastanza vicino".Se provo effettivamente una password di "chiusura", è quasi come provare 1000 se tengo traccia dei blocchi.Se "opensesame" è vicino, devo solo testare le password close-to-opensesame.Ancora peggio, ** questa è una manna dal cielo per chiunque cerchi di estendere la violazione di un sito ad altri tramite la procedura di accesso standard ** dato il riutilizzo dilagante della password (esatta o per lo più simile).** Posso provare per sempre! **


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...