Sfida, autenticazione e chiave di sessione

1

Ho programmato un'applicazione su Linux usando C, ho aggiunto un livello di autenticazione e crittografia simile a questo:

1-client invia la richiesta di connessione. -server invia una sfida casuale al client. -Il client aggiunge un sale alla sfida e lo ha cancellato usando SHA1 quindi lo invia. -il server aggiunge lo stesso salt e hash la sfida con SHA1 e confronta il risultato ricevuto.

2 -In caso positivo, il server chiede al client login e password. -il client invia il login e la password (salted e hash con sha1). -il server cerca la password di accesso e hash in un file.

3 -Se il client ha inviato un login e una password validi, è autenticato. -Una sessione chiave viene generata concatenando La sfida con hash ricevuta E la password con hash ..

4 -la sessione chiave viene utilizzata per crittografare i dati con AES256

Voglio che tu mi dica cosa ne pensi, è sicuro? C'è qualche attacco che può spezzare quelle sequenze in qualsiasi passaggio ...? Grazie mille.

    
posta badr assa 21.09.2013 - 18:08
fonte

1 risposta

6

Il tuo protocollo è abbastanza sottodescritto, ma alcune osservazioni possono ancora essere fatte:

  • Nel primo passaggio, il "salt" viene scelto casualmente dal client e inviato insieme al valore hash, nel qual caso questo passaggio appare completamente inutile; o il sale è non inviato dal client, ma è un valore segreto precondiviso tra client e server, nel qual caso non è un salt ma un tasto e il resto del protocollo è completamente inutile.

  • Nella seconda fase, il client invia il suo login e la "password hash" in cui l'hash utilizza un po 'di sale. Se il client invia sempre lo stesso valore di hash, la presentazione del valore hash garantisce l'accesso: è equivalente alla password . Qualsiasi attaccante che osserva una connessione (puramente passiva) impara quindi a simulare l'autenticazione, quindi il protocollo sarebbe estremamente debole.

Se il tuo protocollo deve avere alcun valore, allora dobbiamo presumere che le cose vadano in questo modo:

  • Il client si connette; server invia un valore casuale N (il termine tecnico è un nonce ).
  • Il client invia un altro valore casuale N ' al server (e invia anche un valore hash calcolato sui valori pubblici N e N' ; tale valore di hash non ha alcun scopo utile).
  • Il client invia il nome utente L e il valore h (N + N ', P) dove N e N' sono scambiati nonces, P è la password dell'utente, e h è una "funzione di hash" che in qualche modo combina N e P (ci sono molti metodi per fare questa combinazione, molti dei quali sono deboli in modi più o meno sottili).
  • Il server ha una copia di P e quindi può ricalcolare il valore h (N + N ', P) e vedere se corrisponde a ciò che il client ha inviato.
  • Il client e il server usano un'altra funzione h ' per calcolare h' (N, P) e usare quel valore come chiave condivisa per fare qualche crittografia simmetrica per il resto dei dati.

Supponendo che tu abbia fatto tutto correttamente e usato le funzioni di hash in modo corretto e non abbia dimenticato di aggiungere controlli di integrità e si siano presi cura dei gazillions dei dettagli di implementazione che possono affliggere i protocolli meglio progettati, allora avrai ottenuto, nel migliore dei casi , TLS-PSK . Ci sono due debolezze intrinseche e inevitabili in quel protocollo:

  • Il server deve memorizzare un segreto equivalente alla password. Se un utente malintenzionato ottiene una visualizzazione di sola lettura dei dati del server (una consueta conseguenza di attacchi di SQL injection o di backup rubati), apprende abbastanza da autenticarsi come qualsiasi utente registrato. Questo è considerato negativo. Vedi questo post del blog per una discussione su questo argomento.

  • Un attaccante passivo impara abbastanza per eseguire un attacco del dizionario offline : l'attaccante deve solo osservare un'autenticazione e quindi può "provare le password" sulle proprie macchine; elenca semplicemente le password possibili finché non ne trova una che corrisponda ai valori hash che ha osservato. Questo, ancora, è negativo, perché le password tendono ad essere vulnerabili a una ricerca così esauriente. Gli attacchi del dizionario online , in cui l'utente malintenzionato deve parlare con il server originale o il client originale per ogni tentativo di password, sono molto meno preoccupanti, perché il server può applicare rigorose limitazioni al numero di tentativi al secondo; mentre un attacco offline è limitato solo dal potere di calcolo che l'attaccante può radunare.

Il modo corretto di eseguire un'autenticazione reciproca basata su password client-server consiste nell'utilizzare un accordo chiave autenticato da password , che risulta in un segreto condiviso adatto per la crittografia simmetrica con controlli di integrità. Ciò significa fondamentalmente TLS-SRP . 15 anni di implementazioni e attacchi e correzioni hanno dimostrato che progettare e implementare un protocollo sicuro di questo tipo non è affatto facile.

    
risposta data 21.09.2013 - 21:17
fonte

Leggi altre domande sui tag