Questo processo è un modo sicuro per gli utenti di accedere? Se è così, c'è già un nome?

-1

Ho pensato a questo processo specificamente per fermare attacchi "man in the middle" e replay:

  1. L'utente digita il proprio nome utente nell'applicazione client.
  2. L'applicazione client invia il nome utente al server.
  3. Il server risponde con una stringa di testo (chiamiamola SecretA ) che è la crittografia di una stringa casuale RandomString utilizzando la password per il nome utente recuperato come chiave di crittografia !! vale a dire SecretA = encrypt( message: RandomString, key: Password)
  4. L'utente digita la sua password e preme "accedi".
  5. L'applicazione client accetta la password immessa dall'utente e SecretA . Decrittografa SecretA utilizzando la password inserita dall'utente per scoprire RandomString (solo se l'utente ha inserito la password corretta). Crittografa RandomString utilizzando la password utente concatenata con un timestamp (che scende ai microsecondi) come chiave, producendo SecretB . vale a dire SecretB = encrypt(message: RandomString, key: concat(Password, TimestampInMicroseconds))
  6. Il client invia SecretB al server insieme al timestamp utilizzato nella crittografia nel passaggio.
  7. Il server decrittografa SecretB concatenando la password dell'utente con il timestamp ricevuto anche dal client. Se la decrittografia è RandomString , l'utente si connetterà.
  8. Il server nega l'accesso se il client del timestamp invia ha una differenza troppo grande con il tempo in cui il server riceve il messaggio.
posta Adé 18.06.2015 - 17:50
fonte

1 risposta

1

Se il tuo obiettivo è quello di fermare gli attacchi degli uomini nel mezzo, in teoria funziona in teoria, ma in pratica cade a pezzi abbastanza facilmente. Questo è solo ciò che vedo come ovvio. Sono sicuro che ci sono più cose che mi sono perse.

Stai facendo affidamento sulla segretezza della password per proteggere l'intera conversazione, il che significa che è effettivamente una chiave simmetrica. Le password definite dall'utente non sono fondamentalmente casuali, quindi la possibilità di indovinare la chiave è un vero problema. Potresti usare una chiave derivata basata sulla password e questo renderebbe la chiave un po 'più strong.

Devi memorizzare la password non protetta (non con hash), che di solito è una cosa brutta da fare, perché qualsiasi violazione di tale elenco significa che ogni utente è fregato. È possibile memorizzare la chiave derivata equivalente, ma se l'utente malintenzionato ottiene quel valore, può semplicemente ignorare la derivazione sul lato client.

Qui ci sono anche una serie di requisiti crittografici indefiniti, come accordo sugli algoritmi, utilizzo IV, ecc. Come si protegge il canale da un MITM che specifica un algoritmo debole, o usa un IV di { 0, 0, 0, 0, 0, 0, 0, 0 } , o ecc.

I passaggi 5-6 possono essere riprodotti da un utente malintenzionato un numero infinito di volte entro il periodo di validità del timestamp. Sia il client che il server devono essere sincronizzati in termini di tempo, altrimenti è molto facile per loro divergere e avrai bisogno di una finestra più ampia, altrimenti otterrai una serie infinita di richieste non valide. Questo è un problema abbastanza serio con i sistemi distribuiti. Hai bisogno di un modo per sapere da entrambe le parti che non hai mai visto quel particolare messaggio prima.

Cosa succede quando hai autenticato entrambe le parti? È così? Una cosa sola? E il resto delle comunicazioni tra i due? Le probabilità sono piuttosto buone, non stai solo autenticando. Un utente malintenzionato può semplicemente attendere il completamento dell'autenticazione prima di iniziare a trafficare con i dati per fare ciò che vuole fare.

Quello che stai cercando di fare è dimostrare l'autenticità di entrambe le parti e quindi creare un canale sicuro tra loro sulla base di tale autenticità. In quanto tale è necessario concordare una chiave per il canale. Questa è una scambio di chiavi di qualche tipo. Questa potrebbe essere una domanda utile da cercare anche a.

    
risposta data 18.06.2015 - 18:54
fonte

Leggi altre domande sui tag