Risposta alla sfida con un libro abbronzato?

Naviga le tue risposte
3

Sto cercando di proteggere una connessione tra un dispositivo mobile (client) utilizzando una web app e un dispositivo domestico (server) in una rete Wifi potenzialmente pericolosa.

La comunicazione è asincrona e sto cercando di impedire " attacchi di riproduzione ".

Stavo pensando a Challenge Response, ma il sovraccarico di " chiedi sfida, ricevi sfida, invia messaggio con sfida risolta " è un problema di prestazioni per noi.

Quindi stavo pensando di utilizzare una sorta di TAN approccio al libro come la cottura in linea lo fa:

Inizialmente il Cliente avrebbe chiesto un set di Sfide che memorizza. Il server memorizzerebbe quelle sfide e terrà traccia di quante sono già state utilizzate.

Se rimangono solo n Sfide, il Server crea nuove Sfide e le invia con la successiva risposta al Cliente. In questo modo, il Cliente dovrebbe quasi sempre avere abbastanza Sfide senza il sovraccarico di Chiedere per loro prima di ogni richiesta.

Esempio:

  • Il cliente desidera accedere e richiede prima le sfide, fornendo il suo nome utente / userid.
  • Il server crea n Sfide e le memorizza per l'ID utente specificato, quindi le invia all'utente.
  • Il client invia challenge-id e hash (challenge, shared-secret).
  • Il server confronta la sfida memorizzata (identificata da challenge-id) con hash con segreto condiviso e, se corretta, restituisce successo e delta sfida poiché era ora in uso.

quindi diventa più facile

  • Il cliente desidera chiamare l'endpoint X dell'API sul server, invia la richiesta con intestazioni aggiunte (ID sfida, hash (challenge, shared-secret))
  • Il server verifica la verifica e uppon successo lo elimina, esegue il metodo x e restituisce la risposta. In risposta aggiunge una nuova sfida nell'intestazione ( i.e. Challenge_id-xyz: 45egrgh3gw43gw43zrezh54egh44z54b54esb ... 54sreh5j )

se il cliente ha problemi con le sfide

  • Il cliente desidera chiamare l'API Point X, invia Request with Challenge in Header
  • Verifica server La sfida, una volta che il successo lo ha eliminato, si rende conto che il cliente è a corto di sfide (a causa della bassa quantità di sfide memorizzate) e ne crea di nuove. Invia Response for API Point X e aggiunge nuove sfide nelle intestazioni.

Esiste già un concetto come questo e in caso contrario, questo suona in modo molto simile a " cuocere il proprio criptaggio " o sembra legittimo? O c'è un modo migliore per farlo senza sovraccaricare l'http?

    
posta Andresch Serj 26.02.2015 - 10:54
fonte

1 risposta

2

Bene in risposta alla tua domanda se c'è un modo migliore per farlo, mi chiedo se una soluzione leggermente più semplice che ho usato in precedenza potrebbe essere all'altezza del compito.

Piuttosto che generare un elenco predefinito di sfide e trasmetterle, fare in modo che client e server aggiungano un valore incrementale prevedibile all'hash che si passa nell'intestazione. Sia il client che il server mantengono il conteggio delle chiamate / risposte numeriche per la sessione e possono rifiutare qualsiasi ricezione con hash duplicati (riutilizzati). Il valore incrementale può essere semplice come un conteggio o potrebbe essere una semplice funzione matematica eseguita sul conteggio se ti senti particolarmente paranoico.

Sembrerebbe qualcosa del genere:

  • Il cliente vuole accedere e invia una richiesta di accesso con userid & hash (una combinazione sensata di segreto condiviso con userid o alcuni ad esempio).
  • Server esamina l'hash e, se corretto, restituisce successo e a token di sessione.

Ora per ogni chiamata effettuata:

  • Il client chiama l'endpoint API X sul server, con hash di intestazione aggiunto (token di sessione, valore incrementale)
  • Il server verifica che l'hash corrisponda al token di sessione & il successivo valore incrementale previsto per questa sessione, se lo fa invia la risposta dall'endpoint anche firmata con hash (token di sessione, valore incrementale successivo).
  • Il client verifica che l'intestazione della risposta contenga un hash del token di sessione e il successivo valore incrementale che si aspettava.

e ripeti.

Se qualsiasi richiesta / risposta arriva con un hash riutilizzato nell'intestazione, il valore incrementale sarà fuori sequenza e il client / server può rifiutarlo. Inoltre, non è necessario preoccuparsi di generare, trasmettere e gestire un elenco di sfide per la sessione.

Gli svantaggi qui implicano problemi causati dall'effettuare chiamate multiple e uscire dalla sequenza a causa di problemi di rete o della progettazione / requisiti dell'applicazione. I modi in cui ciò avviene implicano l'aggiunta di un punto centrale al client per eseguire il marshalling / accodamento di tutte le richieste e le risposte per la sessione, o in alternativa creare una sessione separata per ogni thread o conversazione all'interno dell'applicazione client. Questa è una considerazione extra durante lo sviluppo, forse, ma se la tua esigenza di mantenere il traffico al minimo è abbastanza importante potrebbe valerne la pena.

Commenti e pensieri sono i benvenuti.

    
risposta data 20.03.2015 - 18:06
fonte

Leggi altre domande sui tag

Che cosa significa "PIN crittografato con LMK"? Che cosa costituisce un exploit? Sono stato in grado di compromettere il mio router domestico comune