Verifica PIN sicura se HTTPS è decifrabile da terze parti

-1

Sto sviluppando un sistema in cui le applicazioni mobili comunicano con il server tramite HTTPS. La comunicazione consiste di due fasi: in un primo momento, l'app "registra" sul server: tra le altre cose, l'utente sceglie il suo PIN e viene inviato al server e archiviato lì. Supponiamo per ora che questa fase sia sicura e che tutte le informazioni siano state scambiate in modo sicuro e che nessuna informazione sia trapelata.

La seconda fase della comunicazione inizia dopo la registrazione. L'app invia richieste al server e, con ogni richiesta, all'utente viene richiesto di inserire il PIN che viene aggiunto alla richiesta per autenticare l'utente (in realtà è solo uno dei passaggi di autenticazione, poiché utilizziamo anche l'autenticazione del cert client). La mia domanda è la seguente: è possibile impedire che questo PIN venga esposto nel caso in cui un utente malintenzionato sia in grado di decodificare la nostra comunicazione HTTPS? La maggior parte delle soluzioni sembra fallire perché l'utente malintenzionato è in grado di enumerare i PIN poiché di solito sono lunghi circa 4-6 caratteri (ad esempio, il passaggio di un hash di PIN non riesce a causa di ciò).

Possiamo scambiare alcuni dati aggiuntivi nella fase di registrazione, se necessario.

    
posta poe123 30.06.2016 - 13:38
fonte

1 risposta

1

È possibile implementare il proprio livello di crittografia oltre a quello fornito da TLS. Poiché tu dici che "possiamo scambiare alcuni dati aggiuntivi nella fase di registrazione", ritengo che la soluzione più semplice sarebbe quella di condividere una chiave di crittografia simmetrica (ad esempio AES) durante la registrazione e quindi criptare tutte le ulteriori comunicazioni con quella. (L'IV eviterà la forza bruta anche se ci sono solo un numero limitato di possibili testi in chiaro.)

Si prega di notare che questo si basa interamente sulla sicurezza della connessione originale quando vengono scambiati PIN e chiave. Se fallisce, questo schema fallisce. Un'altra opzione sarebbe quella di spedire l'applicazione con la chiave pubblica codificata in esso. Chiedi all'app di generare una chiave simmetrica casuale, crittografarla in modo asimmetrico con la tua chiave pubblica e inviarla al server. Questo può essere fatto solo una volta o una volta per sessione. Ma ora stiamo iniziando a costruire un protocollo crittografico completo ...

Questo sarebbe un lavoro, e forse non ne vale la pena. La minaccia principale probabilmente non è la rottura di TLS, ma il telefono degli utenti viene infettato da malware o il server viene violato.

Invece, ti consiglierei di ottenere il TLS corretto in modo che un utente malintenzionato non sia mai in grado di decrittografarlo in primo luogo. Nel caso di un'app mobile, in cui si ha il controllo sia del client che del server, è più facile da fare rispetto a un'app Web. Raccomando questi passaggi:

  • Scegli un seme cifrato adatto a un set ridotto e consenti solo al client e al server di accettare quelli
  • Consenti solo TLS 1.2 (o versioni successive)
  • Implementa il blocco della chiave pubblica
risposta data 30.06.2016 - 13:57
fonte

Leggi altre domande sui tag