Prevenzione dei dispositivi che utilizzano lo stesso segreto OTP

Comprendo perfettamente la tua esigenza, dal momento che la scansione del codice QR con Google Authenticators KeyURI determinerà "copie" del possesso dell'autenticazione.

Interessante abbastanza c'è un RFC per questo: link Ma il mio sospetto è che questo potrebbe essere un bit overkill.

Sto lavorando al nostro server di autenticazione che oltre a molti altri dispositivi di autenticazione supporta anche app per smartphone come Google Authenticator che eseguono la scansione del segreto OTP in "testo normale". Come detto, non mi piace molto, quindi abbiamo anche iniziato a pensare a migliorare il processo di implementazione. Questi sono i nostri temi finora: link

In sostanza, vogliamo essere in grado di registrare uno smartphone senza connessione a Internet. A volte lo smartphone non ha una connessione o, a volte, il server di autenticazione, dove viene registrato il token, non è accessibile dallo smartphone, ma solo dal client desktop. Quindi abbiamo pensato di affidarci ancora al QR Code.

Ma invece di trasportare solo la chiave segreta all'interno del QR Code e rendere così il token copiabili su molti smartphone, abbiamo bisogno di un secondo componente generato dallo smartphone. Il modo più semplice è questo:

1. Il server di autenticazione fornisce il primo compoment della chiave segreta in un codice QR
2. L'utente esegue la scansione di questo codice QR con la sua nuova app lucida
3. L'app genera il secondo componente e semplicemente visualizza questo all'utente.
4. L'utente digita questo secondo componente nella pagina di registrazione del server di autenticazione.
5. Entrambi, il server e l'app per smartphone calcolano l'ultima chiave segreta in base al componente generato dal server e al componente generato dall'app dello smartphone.

Inoltre : il flusso di lavoro è piuttosto semplice e non soggetto a errori

Meno : un utente malvagio potrebbe ancora annotare il primo componente del server e il secondo componente generato dallo smartphone e "manualmente" calcolare la chiave segreta e utilizzare questa chiave segreta su diverse app per smartphone . Ma questo è ancora un processo brutto. L'obiettivo principale era proteggere gli utenti pigri e malvagi, che potevano semplicemente chiedere al loro collega: "Ehi, scannerizza anche il mio token".

Sono curioso, cosa ne pensi di questo. Se ti piace, seguici su github o contribuisci, forse questa potrebbe essere una soluzione anche per te.

Se stai progettando la tua app di autenticazione; invece di eseguire la scansione del token OTP, eseguire la scansione di un token di autorizzazione che verrà quindi utilizzato per recuperare l'OTP da un server. Il server può quindi essere configurato per rilasciare il token una sola volta. Certificato di bundle che si inserisce nella tua applicazione e anche tu sei bravo.

Il flusso sarebbe simile a questo.

• L'utente richiede il token OTP dal sito web
• L'utente apre l'app e scansiona il codice QR, che contiene un codice API utilizzabile una sola volta
• L'app contatta quindi il server, verifica il certificato con cert spillato
• L'app invia una chiave API utilizzabile una sola volta, il server restituisce il token OTP e contrassegna la chiave API come defunta.

Potresti voler utilizzare l'ID del dispositivo per implementare un segreto deterministico unico per dispositivo come descritto nella RFC 4226 , nulla impone il segreto da trasmettere (ma si consiglia di utilizzare la generazione casuale).

 We distinguish two different cases:

      - A single master key MK is used to derive the shared secrets;
        each HOTP device has a different secret, K_i = SHA-1 (MK,i)
        where i stands for a public piece of information that identifies
        uniquely the HOTP device such as a serial number, a token ID,
        etc.  Obviously, this is in the context of an application or
        service -- different application or service providers will have
        different secrets and settings.

In alternativa allo scenario della chiave casuale generata alla prima esecuzione, l'app può utilizzare il dispositivo uuid come chiave di crittografia nei tuoi 1 e 2, il che rende più difficile la riproduzione su un altro dispositivo.