Autenticazione utente protetta da tutti i vettori di attacco

0

Avendo investito molto tempo nella ricerca, non sono in grado di confermare se il mio sistema è abbastanza sicuro.

  • Gli utenti hanno un telefono cellulare e si collegano a un server di autorizzazione centrale passando il loro nome utente, password e un nonce. La password verrà sottoposta a hash
  • Nome utente, la password sarà pre-generata e fornita all'utente tramite metodi fuori banda. Non c'è una pagina di registrazione, e il nome utente, la password che viene assegnata a un utente non sarà mai compromessa
  • L'utente riceverà un jwt con un tempo di scadenza di circa 12 ore
  • Per qualsiasi post o get richiesta, l'utente deve aggiungere il jwt nel header come da standard comuni
  • Il server può essere considerato affidabile

Ora i miei dubbi sono,

  • Se qualcuno intercetta i pacchetti inviati dal cellulare, può ottenere il token jwt , che può essere utilizzato per inviare richieste da un hacker. Cosa impedisce all'hacker di inviare richieste aggiungendo jwt alle sue richieste?
  • Se i pacchetti in entrata e in uscita dal cellulare vengono violati durante la fase di accesso, l'hacker otterrà l'accesso all'hash della password (e sale) e al nome utente leggendo i pacchetti. Cosa gli impedisce di inviare gli stessi dati in un secondo momento al server e di ottenere un jwt del proprio

Suppongo che l'hacker sia estremamente sofisticato.

Una cosa che ho pensato, è che ogni volta che l'utente tenta di accedere, uno scambio di chiavi viene avviato con il server e viene quindi utilizzato per scambiare la password. Quindi, se queste informazioni vengono ottenute, l'hacker non può utilizzarle per l'autenticazione in quanto le chiavi di crittografia sono di natura effimera.

Un'altra opzione più semplice è che il server invii semplicemente un nonce, che il client userà per firmare la password. Questo è unico per una singola sessione, quindi una volta che l'utente effettua l'accesso, se un hacker invia la stessa password firmata verrà rifiutata poiché il nonce sul lato server sarebbe scaduto.

Tuttavia, non sono in grado di proteggermi nell'eventualità che l'hacker acceda al token jwt .

    
posta Varun Agarwal 24.11.2016 - 12:03
fonte

1 risposta

2

Presumo che tu stia utilizzando https con una lunghezza ragionevole della chiave, per accedere all'API di accesso e ricevere il JWT e l'invio di JWT è sessioni SSL. Se questo è il caso, l'accesso a JWT da un'acquisizione pacchetto della sessione SSL (crittografata) non sarà veloce. Quindi il tuo JWT dovrebbe avere un ragionevole termine di scadenza e essere riemesso alla scadenza.

Se ritieni che il tuo carico utile sia troppo sensibile per https , ti suggerisco di utilizzare una connessione privata (ad esempio tunnel su VPN) prima della connessione dell'app. Per le app pubbliche non è pratico.

    
risposta data 24.11.2016 - 12:08
fonte