È ansible invertire uno sha1?

È ansible invertire uno sha1?

Sto pensando di usare uno sha1 per creare un semplice sistema leggero per autenticare un piccolo sistema embedded che comunica tramite una connessione non criptata.

Diciamo che creo uno sha1 come questo con l’input da una “chiave segreta” e lo rendo con un timestamp in modo che lo sha cambierà tutto il tempo.

sha1("My Secret Key"+"a timestamp") 

Quindi includo questo sha1 nella comunicazione e nel server, che può fare lo stesso calcolo. E si spera che nessuno sarebbe in grado di capire la “chiave segreta”.

Ma è davvero così?

Se sai che è così che l’ho fatto, sapresti che ho inserito un timestamp e avresti visto lo sha1. Puoi quindi usare quei due e capire la “chiave segreta”?

 secret_key = bruteforce_sha1(sha1, timestamp) 

Grazie Johan


Nota 1 : Immagino che potresti in qualche modo potenziare la forza, ma quanto sarebbe effettivamente il lavoro?

Nota 2 : Non ho intenzione di crittografare alcun dato, vorrei solo sapere chi lo ha inviato.

No, non è ansible invertire SHA-1, questo è esattamente il motivo per cui è chiamato Secure Hash Algorithm.

Ciò che dovreste assolutamente fare, però, è includere il messaggio che viene trasmesso nel calcolo dell’hash. Altrimenti un man-in-the-middle potrebbe intercettare il messaggio e usare la firma (che contiene solo la chiave del mittente e il timestamp) per collegarlo a un messaggio falso (dove sarebbe comunque valido).

E probabilmente dovresti usare SHA-256 per i nuovi sistemi ora.

 sha("My Secret Key"+"a timestamp" + the whole message to be signed) 

Devi anche trasmettere il timestamp in chiaro, altrimenti non hai modo di verificarlo (oltre a provare un sacco di timestamp plausibili).

Se un attacco di forza bruta è fattibile dipende dalla lunghezza della tua chiave segreta.

La sicurezza dell’intero sistema si baserebbe su questo segreto condiviso (perché sia ​​il mittente che il destinatario devono sapere, ma nessun altro). Un utente malintenzionato proverà a seguire la chiave (o indovinando la forza bruta o cercando di ottenerla dal dispositivo) anziché tentare di interrompere SHA-1.

SHA-1 è una funzione di hash che è stata progettata per rendere difficile l’inversione dell’operazione. Tali funzioni di hash sono spesso chiamate funzioni unidirezionali o funzioni hash crittografiche per questo motivo.

Tuttavia, SHA-1 ha alcune debolezze scoperte di recente che consentono di trovare un input più veloce rispetto a una ricerca di forza bruta di tutti gli input. Dovresti considerare di usare qualcosa di più forte come SHA-256 per nuove applicazioni.

Jon Callas su SHA-1:

È tempo di camminare, ma di non correre, verso le uscite del fuoco. Non vedi il fumo, ma gli allarmi antincendio si sono spenti.

La domanda è in realtà come autenticarsi su una sessione non sicura.

Lo standard per farlo è utilizzare un digest di messaggi, ad es. HMAC .

Inviate il messaggio in chiaro e un hash di quel messaggio in cui è stato inserito il vostro segreto.

Quindi, invece del tuo:

 sha1("My Secret Key"+"a timestamp") 

Hai:

 msg,hmac("My Secret Key",sha(msg+msg_sequence_id)) 

L’id della sequenza di messaggi è un semplice contatore per tenere traccia di entrambe le parti sul numero di messaggi scambiati in questa “sessione”: ciò impedisce a un utente malintenzionato di riprodurre semplicemente i messaggi visti in precedenza.

Questo è il modo standard e sicuro per l’autenticazione dei messaggi, indipendentemente dal fatto che siano crittografati o meno.


(questo è il motivo per cui non puoi brutalizzare l’hash 🙂

Un hash è una funzione a senso unico, il che significa che molti input producono tutti lo stesso output.

Come sai il segreto, e puoi fare un’ipotesi ragionevole sull’intervallo del timestamp, allora potresti scorrere tutti quei timestamp, calcolare l’hash e confrontarlo.

Ovviamente due o più timestamp all’interno dell’intervallo esaminato potrebbero “scontrarsi”, anche se i timestamp sono diversi, generano lo stesso hash.

Quindi, fondamentalmente, non esiste un modo per invertire l’hash con certezza.

In termini matematici, solo le funzioni biiettive hanno una funzione inversa. Ma le funzioni hash non sono iniettive in quanto vi sono più valori di input che producono lo stesso valore di output (collisione).

Quindi, no, le funzioni di hash non possono essere invertite. Ma puoi cercare queste collisioni.


modificare

Come vuoi autenticare la comunicazione tra i tuoi sistemi, ti suggerirei di usare HMAC . Questo costrutto per calcolare i codici di autenticazione dei messaggi può utilizzare diverse funzioni di hash. Puoi usare SHA-1, SHA-256 o qualsiasi altra funzione di hash che desideri.

E per autenticare la risposta a una richiesta specifica, invierei un nonce insieme alla richiesta che deve essere usata come sale per autenticare la risposta.

Non è del tutto vero che non è ansible invertire la stringa crittografata SHA-1.

Non è ansible invertire direttamente uno, ma può essere fatto con le tabelle arcobaleno.

Wikipedia: una tabella arcobaleno è una tabella precalcata per l’inversione delle funzioni hash crittografiche, in genere per il cracking degli hash delle password. Le tabelle vengono solitamente utilizzate per recuperare una password in testo semplice fino a una determinata lunghezza costituita da un insieme limitato di caratteri.

Essenzialmente, SHA-1 è sicuro solo quanto la forza della password utilizzata. Se gli utenti hanno password lunghe con combinazioni di caratteri oscure, è molto improbabile che le tabelle arcobaleno esistenti abbiano una chiave per la stringa crittografata.

È ansible testare le stringhe SHA-1 crittografate qui: http://sha1.gromweb.com/

Ci sono altre tabelle arcobaleno su Internet che puoi utilizzare per invertire Google SHA1.

Si noti che i migliori attacchi contro MD5 e SHA-1 riguardano la ricerca di due messaggi arbitrari m1 e m2 dove h (m1) = h (m2) o la ricerca di m2 tale che h (m1) = h (m2) e m1! = m2. Trovare m1, dato h (m1) è ancora computazionalmente imansible.

Inoltre, stai usando un MAC (codice di autenticazione dei messaggi), quindi un utente malintenzionato non può dimenticare un messaggio senza conoscere il segreto con un avvertimento: la struttura MAC generale che hai usato è suscettibile di un attacco di estensione della lunghezza – un attaccante in alcune circostanze può fustigare un messaggio m2 | m3, h (segreto, m2 | m3) dato m2, h (segreto, m2). Questo non è un problema con timestamp ma è un problema quando si computa MAC su messaggi di lunghezza arbitraria. È ansible aggiungere il segreto al timestamp invece che in attesa, ma in generale è preferibile utilizzare HMAC con SHA1 digest (HMAC è solo di costruzione e può utilizzare MD5 o SHA come algoritmi di digest).

Infine, stai firmando solo il timestamp e non la richiesta completa. Un attaccante attivo può facilmente attaccare il sistema, specialmente se non si ha la protezione di riproduzione (anche se con la protezione di riproduzione, questo difetto esiste). Ad esempio, posso acquisire timestamp, HMAC (timestamp con segreto) da un messaggio e quindi usarlo nel mio messaggio e il server lo accetterà.

Meglio inviare un messaggio, HMAC (messaggio) con un segreto sufficientemente lungo. Il server può essere certo dell’integrità del messaggio e dell’autenticità del client.

È ansible, a seconda del proprio scenario di minacce, aggiungere protezione di riproduzione o notare che non è necessario poiché un messaggio quando viene riprodotto interamente non causa problemi.

Gli hash dipendono dall’input e per lo stesso input restituiscono lo stesso output.

Quindi, oltre alle altre risposte, tieni presente quanto segue:

Se si avvia l’hash con la password, è ansible calcolare preventivamente le tabelle arcobaleno e aggiungere rapidamente valori di timestamp plausibili, il che è molto più difficile se si inizia con il timestamp.

Quindi, piuttosto che usare sha1 (“My Secret Key” + “a timestamp”)

go for sha1 (“a timestamp” + “My Secret Key”)

Credo che la risposta accettata sia tecnicamente corretta ma sbagliata in quanto si applica al caso d’uso: creare e trasmettere dati di manomissione su mezzi pubblici / non affidabili.

Perché anche se è tecnicamente molto difficile eseguire la forza bruta o invertire un hash SHA, quando si inviano “dati e hash dei dati + segreti” in chiaro su Internet, come indicato sopra, è ansible ottenere in modo intelligente segreto dopo aver catturato un numero sufficiente di campioni dei tuoi dati. Pensaci: i tuoi dati potrebbero cambiare, ma la chiave segreta rimane la stessa. Quindi ogni volta che invii un nuovo blob di dati, è un nuovo esempio su cui eseguire algoritmi di cracking di base. Con 2 o più campioni che contengono dati diversi e un hash dei dati + segreti, è ansible verificare che il segreto che si determina sia corretto e non un falso positivo.

Questo scenario è simile a come i cracker di Wifi possono violare le password wifi dopo aver acquisito un numero sufficiente di pacchetti di dati. Dopo aver raccolto abbastanza dati è banale generare la chiave segreta, anche se non stai tecnicamente invertendo SHA1 o persino SHA256. L’UNICO modo per garantire che i tuoi dati non siano stati manomessi o per verificare con chi stai parlando dall’altra parte, è crittografare l’intero blob di dati utilizzando GPG o simili (chiavi pubbliche e private). L’hashing è, per sua natura, SEMPRE insicuro quando i dati che stai tranciando sono visibili.

In pratica, dipende in primo luogo dall’applicazione e dallo scopo del motivo per cui si sta facendo l’hashing. Se il livello di sicurezza richiesto è banale o si dice che si è all’interno di una rete completamente affidabile al 100%, forse l’hashing sarebbe un’opzione praticabile. Spero che nessuno sulla rete o qualsiasi intruso sia interessato ai tuoi dati. Altrimenti, per quanto posso determinare in questo momento, l’unica altra opzione affidabile è la crittografia basata su chiave. È ansible crittografare l’intero blob di dati o semplicemente firmarlo.

Nota: questo è stato uno dei modi in cui gli inglesi sono riusciti a decifrare il codice Enigma durante la seconda guerra mondiale, portando a favorire gli alleati.

Qualche idea su questo?

SHA1 è stato progettato per impedire il recupero del testo originale dall’hash. Tuttavia, esistono database SHA1 che consentono di cercare le password comuni tramite il loro hash SHA.