Lavoro con un sistema hardware che autentica tradizionalmente gli utenti inserendo una breve password numerica su una tastiera fisica. Nonostante la piccola entropia della password, questo sistema ha dimostrato di essere abbastanza robusto perché sono in atto meccanismi per rilevare la forza bruta (ripetuta immissione errata della password). Ogni utente ha una stringa di nome associata e una password numerica. La stringa del nome viene utilizzata solo per scopi amministrativi e non per il processo di autenticazione. Quindi, per essere chiari: l'unico modo per un utente di interagire con il sistema è di essere sul posto e salire su una tastiera fisica, a quel punto hanno solo X tenta di inserire la password numerica corretta.
Ora desideriamo introdurre l'accesso al dispositivo mobile remoto al sistema tramite un server HTTPS integrato e l'API REST. Poiché il sistema è una piattaforma embedded con vincoli molto limitati, l'implementazione di un server HTTPS è stata possibile (e ora è stata raggiunta), ma credo che ospitare uno schema basato su token come OAuth sia troppo difficile in questo momento, e pertanto desidero affidarmi all'autenticazione di base crittografata con TLS.
Per soddisfare gli standard, gli utenti remoti devono fornire una password ogni volta che usano l'app del telefono. La gestione del prodotto stabilirà inevitabilmente che le stringhe e le password del nome utente legacy esistenti vengano utilizzate per autenticare un utente in remoto tramite HTTPS REST (in altre parole, quando usano l'app del telefono), ma chiaramente le password numeriche corte esistenti potrebbero essere forzate brute facilmente, e sospetto che il tentativo di implementare un meccanismo di blocco su HTTPS potrebbe essere difficile e problematico. Cambiare il sistema esistente per usare password più lunghe e complesse non è un'opzione perché il sistema legacy esistente non le supporta. Pertanto, concludo che ogni utente avrà bisogno di una password di entropia secondaria e più elevata ai fini dell'accesso remoto, insieme alla propria password numerica legacy. Sospetto che la gestione del prodotto non gradisca il fatto che ora l'utente debba memorizzare e utilizzare una password di accesso remoto separata.
Lo schema su cui ho pensato è il seguente:
-
L'utente inizialmente imposta la propria app per funzionare con il dispositivo hardware. Il dispositivo hardware fornisce all'utente (tramite il suo LCD) una chiave lunga ad alta entropia. L'utente inserisce quella chiave lunga nella sua app mobile.
-
L'app memorizza internamente quella chiave in modo permanente, associata alla breve password numerica dell'utente.
-
Ogni volta che l'utente vuole utilizzare l'app, inserisce la sua password numerica. Se l'app ha una chiave memorizzata internamente per tale password, viene utilizzata all'interno dell'intestazione Autorizzazione di base (eventualmente aggiunta alla password legacy) per effettuare chiamate dell'API HTTPS all'hardware.
In questo modo, esiste una password ad alta entropia ai fini dell'accesso remoto, riducendo il rischio di brute-force di base Auth. La breve password legacy è ora utilizzata solo per l'applicazione per recuperare la password HTTPS dalla memoria locale. In un certo senso, suppongo che sia come pre-condividere un 'sale' tramite un canale di comunicazione separato (che in questo caso sarebbe l'utente che legge la chiave dal display LCD dell'hardware). Raggiunge l'obiettivo finale di dare all'utente l'impressione di accedere al sistema (tramite l'app) tramite la sua normale password numerica.
L'unica pecca che vedo è che si basa sul dispositivo mobile che memorizza la chiave di accesso remoto. Quanto di una vulnerabilità che presenta è a me sconosciuta in questo momento. Quello che sto pensando è che, se il processo di autenticazione di base richiede una concatenazione sia della chiave remota (archiviata in modo permanente) che della password numerica breve (inserita dall'utente ogni volta, mai memorizzata), significa che qualsiasi cosa è memorizzata in modo permanente sul dispositivo non è sufficiente per un utente malintenzionato per ottenere l'accesso senza ulteriore lavoro.
Considerati i miei limiti, ci sono difetti o opportunità di miglioramento con ciò che ho proposto?