Autenticazione a due vie sicura con chiave già condivisa

Naviga le tue risposte
2

Ho la seguente configurazione:
Un server e un client saranno connessi tramite tcp. Sia il server che il client hanno accesso alla chiave segreta già condivisa. Quando il client si connette al server, sia il client che il server devono conoscere la chiave, quindi devono utilizzare la stessa chiave per autenticarsi o fallire.

Mi è venuto in mente il seguente processo e vorrei sapere se c'è qualcosa di evidentemente sbagliato in esso che non ho visto. La vera crittografia non lo è rilevante in questo caso. Quindi questo è ciò che accade quando il client si connette:

  1. Il server genera un sale di 16 byte (salt1).
  2. Il server calcola hashServer1 = HASH (tasto + HASH (tasto + sale1)).
  3. Il server invia salt1 al client.
  4. I client calcolano usando il sale1 ricevuto hashClient1 = HASH (chiave + HASH (chiave + sale1)).
  5. Il client genera 16 byte salt (salt2).
  6. Il client calcola hashClient2 = HASH (tasto + HASH (tasto + sale2)).
  7. Il client invia (hashClient1 + salt2) al server.
  8. Il server controlla se ha ricevuto hashClient1 == hashServer1 e se non si rompe.
  9. Il server calcola usando salt2 hashServer2 = HASH (chiave + HASH (chiave + sale2)).
  10. Il server invia hashServer2 al client.
  11. Il client controlla se ha ricevuto hashServer2 == hashClient2 e se non si rompe.

Se non mi sbaglio, questo dovrebbe essere abbastanza sicuro quando si utilizza un algoritmo di hash strong. La chiave non viene mai inviata come testo in chiaro e, a causa del sale, i dati sono diversi ogni volta.

EDIT: modificato il sale utilizzato per l'hashing da saltX a HASH (chiave + saltX).

    
posta darkfire000 08.06.2017 - 10:06
fonte

3 risposte

0

L'unico problema lampante che vedo qui è che il sale è effettivamente inutile. Il punto di un sale è rendere più difficile il cracking aggiungendo un ulteriore fattore sconosciuto per supportare l'entropia del processo di hashing. I sali non devono necessariamente essere segreti, ma vogliamo che abbiano alcune proprietà quando si tratta di proteggere gli hash:

  • non riutilizzare mai i sali
  • non dare i sali gratis
  • non usare i sali corti

dare il sale ogni transazione mi permetterà di guardare per i modelli nella loro creazione. naturalmente, questo dipende da quanto è casuale la generazione.

In questo caso se sono un utente malintenzionato che annusa questo traffico, ho il sale ogni volta. nel senso che ho effettivamente ridotto il problema a rompere il PSK in ogni singolo caso, e mi fornisci due hash e sali per ogni connessione, aumentando ulteriormente il mio pool.

Questo è ancora un grosso problema, devo ancora vedere se riesco a trovare il valore che porta all'hash che tu dai, ma in questo caso, una volta che ho un hash + una coppia salina, sto solo crackando la PSK a quel punto.

Penso che le cose più importanti qui sono che i sali vengono solitamente usati per proteggere grandi database di informazioni da ricerche inverse o tabelle arcobaleno. Ma nel tuo caso, l'intero server è soggetto a una password. Conoscere il sale è un affare più grande qui, e scommetterei che rende il sale un segreto anche. Qualcosa che valga la pena di custodire. Dal momento che se volevo davvero entrare, avrei preso una coppia salata / hash e generato gli hash fino a quando ho trovato il PSK.

    
risposta data 08.06.2017 - 10:20
fonte
0

Questo protocollo è chiamato Autenticazione della risposta alla sfida e potresti semplificare il tuo processo:

  1. Il server invia la stringa timestampFromServer:HASH(PSK + timestampFromServer) .

  2. Il client convalida l'hash, si fida del server e invia la stringa timestampFromClient:HASH(PSK + timestampFromClient)

  3. Il server convalida l'hash e si fida del client.

On 2 , il client procede solo se l'hash è valido e ciò dimostra che il server conosce la chiave. Su 3 viene testato il contrario e il server sa che il client conosce anche la chiave.

On 1 , il server può anche inviare timestampFromServer:HASH(PSK + timestampFromServer):TransientSessionKey . Ora il client può utilizzare TransientSessionKey e PSK per ricavare una chiave simmetrica e utilizzarla su ogni comunicazione con il server.

In questo modo non hai bisogno di un accumulatore di sale, non devi preoccuparti di riutilizzare i sali (a seconda della precisione del timestamp) e usare meno sali. Puoi autenticare sia il client che il server con meno round trip, riducendo la latenza e se usi TransientSessionKey riduci la probabilità di perdere il PSK.

    
risposta data 03.07.2018 - 23:28
fonte
0

Non tirare la tua crittografia. Utilizza TLS-PSK.

link

    
risposta data 01.11.2018 - 06:42
fonte

Leggi altre domande sui tag

Implementazione dei metodi di blocco intelligente esistenti Perché preoccuparsi delle misure di sicurezza quando IBAN è tutto ciò che serve per trasferire denaro dal mio account?