Autenticazione su SSL usando hash e salt

Question

Autenticazione su SSL usando hash e salt

#1 da (1 voti)
#2 da (1 voti)

1

Ho svolto ricerche approfondite su questo argomento e sono bloccato - speravo di ottenere alcuni chiarimenti da parte di persone utili.

Sfondo: ho dei transponder Bluetooth collegati ai lucchetti che sono stati aperti tramite pagamento nella mia app. Un utente paga una quota fissa, la serratura si apre, afferrano il loro oggetto e la porta si chiude e si blocca. Sto cercando di impedire attacchi di spoofing in cui gli utenti non paganti sono in grado di aprire questi blocchi.

La mia attuale soluzione teoricamente è la seguente: A ogni transponder viene assegnato un sale casuale a 32 bit. Una volta che l'app si connette, una richiesta di autenticazione viene inviata al transponder. Il transponder crea quindi una stringa di sfida casuale + il suo sale unico. Il transponder quindi hash itera la stringa 10.000 volte (per proteggersi dalla forza bruta) usando SHA256.

Mentre ciò accade, anche la stringa di prova originale + sale viene trasmessa all'app che poi la invia a un server sicuro via SSL dove si trovano anche la chiave hash segreta condivisa e il sale transponder. La stringa è hash iterata 10.000 volte usando Sha256, rinviata all'app e torna al transponder che convalida l'hash del server con il proprio hash calcolato. Se uguale, il blocco si apre.

Le mie domande sono: è sicuro? Sto trascurando qualche vistoso difetto di sicurezza, che si tratti di forza bruta o altro? Mi sto sbagliando completamente? Qualsiasi aiuto o raccomandazione sarebbe molto apprezzato

bluetooth hash salt tls

posta user3682157 03.08.2016 - 04:53

fonte

2 risposte

Leggi altre domande sui tag bluetooth hash salt tls

Dove posso ottenere maggiori informazioni su questi virus? Identificazione della vulnerabilità di SQL injection utilizzando il parametro GET dell'URL

score 1 · Answer 1

Quello che vuoi è un codice di autenticazione dei messaggi . Ci sono diversi modi per crearne uno. Quello che descrivi è un modo banale per creare un Hash-MAC, ma ha alcuni falle di sicurezza . Potresti essere a posto con esso, se la tua stringa di sfida è di lunghezza fissa e aggiungi il "sale", che in realtà è la chiave, alla fine. Ma esiste un modo ben definito per generare un HMAC e suggerirei di usarlo, perché la sua sicurezza è stata studiata. Per la maggior parte dei linguaggi di programmazione ci sono anche buone librerie per creare un HMAC che riduce il tuo lavoro (e le cose che potresti fare male).

score 1 · Answer 2

L'iterazione di un hash è una forma di allungamento della chiave . Questo è solitamente ottenuto tramite un algoritmo comprovato come PBKDF2 piuttosto che semplicemente iterando una funzione di hashing crittografica a modo tuo.

L'allungamento delle chiavi in questo modo è davvero necessario solo se stai tentando di prendere una password fornita dall'utente con una possibile bassa entropia di cui è necessario aumentare artificialmente. Se puoi controllare tu stesso i tasti e generarne uno con un'entropia sufficientemente alta, non è necessario un allungamento delle chiavi.

Per chiarire che hai:

App --authentication request--> Transponder

Transponder Authentication Key = 10,000 x sha-256(Challenge String + Transponder 32-bit salt)

Transponder --Challenge String + Transponder 32-bit salt--> App
App --Challenge string + Transponder 32-bit salt--> Server (via SSL)

Server Authentication Key = 10,000 x sha-256(Challenge String + Transponder 32-bit salt)

Server --Server Authentication Key--> App --Server Authentication Key--> Transponder

Transponder: Unlock if Server Authentication Key == Transponder Authentication Key

Spero di averlo corretto.

L'unica cosa su cui non sono chiaro è shared secret hash key - è questa la stringa di sfida o qualcos'altro, dato che non hai menzionato questo termine in precedenza?

I am trying to prevent spoofing attacks where non paying users are able to open these locks.

Che cosa impedisce a qualcuno di generare il proprio calcolo di 10,000 x sha-256(Challenge String + Transponder 32-bit salt) e quindi di inviarlo di nuovo al transponder per farlo aprire?

Immagino che shared secret hash key sia coinvolto da qualche parte e ciò che stai facendo sul transponder è

Transponder Authentication Key = 10,000 x sha-256(Challenge String + Transponder 32-bit salt + shared secret hash key)

Se questa ipotesi è corretta, sembra che tu abbia bisogno di un codice di autenticazione dei messaggi piuttosto che un semplice hash con più turni. Ad esempio, un HMAC .

Se la stringa di challenge è 128 bit e sale è a 128 bit, questo darebbe a ogni chiave di autenticazione 256 bit di entropia, e dovresti assicurarti che shared secret hash key sia almeno di 128 bit. Vedi questa risposta .

Dal transponder all'app calcoleresti

HMAC_SHA256("<shared secret hash key>", "Challenge String + Transponder 32-bit salt")

e Challenge String + Transponder 32-bit salt viene quindi trasmesso all'app e quindi al server, il server esegue quindi lo stesso calcolo di HMAC e lo restituisce all'app che lo inoltra al transponder per il confronto.