token di accesso contro UserID + token di accesso

1

Il mio obiettivo è quello di associare (autenticare) dispositivi hardware agli utenti nel database. Il token di accesso viene generato tramite interfaccia web. Viene quindi inserito nel dispositivo hardware dall'utente e il dispositivo lo utilizza per l'autenticazione sul server web. Il token è composto da 20 caratteri esadecimali casuali e può essere revocato. Il numero massimo di dispositivi è stimato in 1 milione.

C'è qualche ragione, perché l'utente dovrebbe inserire anche un ID utente sul dispositivo? O il token di accesso è sufficiente?

Grazie

    
posta user2291758 23.11.2014 - 10:54
fonte

3 risposte

2

Senza un ID utente che attacca il tuo sistema può essere eseguito un milione di volte più velocemente che con ID utente. Mi sembra abbastanza ragionevole.

Con un userID un utente malintenzionato può attaccare un solo token alla volta. Senza userID, con un solo tentativo, può attaccare tutti e 1 milione contemporaneamente.

    
risposta data 23.11.2014 - 12:32
fonte
1

Il "userID" che intendi introdurre suona come un'autenticazione di secondo fattore.

Quindi per accedere al tuo sistema, un avversario deve possedere il dispositivo e deve anche conoscere l'ID utente associato al dispositivo.

Aggiunge un secondo livello di sicurezza, a condizione che l'ID utente non sia stampato sul dispositivo stesso. Se è sufficiente dipende dal valore del target che si sta proteggendo e dagli agenti della minaccia associati. L'aumento della sicurezza comporta un inconveniente maggiore poiché tutti gli utenti devono eseguire un ulteriore passaggio per ottenere l'accesso.

In definitiva, devi trovare un equilibrio tra comodità e sicurezza con cui ti trovi a tuo agio.

    
risposta data 23.11.2014 - 16:37
fonte
1

Ho pensato di liberare l'aria per chiunque lo legga in futuro. Il problema con il token di accesso è non l'entropia. È che rende molto più facile sfruttare una vulnerabilità utilizzando un timing attack .

Un esempio potrebbe essere se l'applicazione cerca il token di accesso direttamente da una chiamata al database where access_token = '' . Questo non viene confrontato in modo sicuro, ma verrà restituito il più rapidamente possibile. Pertanto, consentirà a un utente malintenzionato di creare le proprie stringhe in base ai tempi dei confronti che stanno inviando. Esistono modi per mitigare questa vulnerabilità, ad esempio aspettando sempre lo stesso periodo di tempo prima di restituire il risultato.

Riassunto, la parte buona dell'invio di un user_id è che puoi eseguire il loop su tutti i token di quell'utente e controllare se uno di essi corrisponde utilizzando un confronto sicuro. Che, a sua volta, non fornisce a un utente malintenzionato alcuna informazione utile per le sonde future.

    
risposta data 28.01.2018 - 07:52
fonte

Leggi altre domande sui tag