Che cosa è più sicuro per voce e SMS OTP: un numero casuale o generato simile a HOTP?

3

Molti provider stanno creando l'autenticazione OTP per l'accesso. Tuttavia ho notato che tutti gli OTP vocali e SMS che ho incontrato sono una serie di 6 cifre ... simile allo standard HOTP RFC emesso da Google Authenticator.

Vedo queste OTP a sei cifre quando:

  1. Autenticazione tramite una telefonata (Google e alcune banche ...)
  2. SMS al mio telefono (Facebook e Google ...)
  3. Verifica di un account tramite l'indirizzo email verificato
  4. Verifica del mio indirizzo di casa (Google Business, autenticazione strong IRS)

... Ovvero qualsiasi OTP che non utilizza un token o dispositivo OTP intelligente (YubiKey, Google Authenticator, Gemalto, ecc.)

Domanda

With regard to protecting the IdP that issues the OTP, what are the benefits and drawbacks of using a random number vs a seed like HOTP?

Ecco come potrebbero apparire alcuni scenari se la password one time è archiviata in un database. Uno scenario è basato sul seme in stile HOTP, l'altro scenario è basato sul numero casuale:

  1. Se il database delle password (salate) viene rubato / estratto, è probabile che il seme HOTP sia archiviato nella stessa posizione. La sicurezza del datacenter in questo scenario si basa esclusivamente sulla protezione del database e dell'amplificazione; Seme HOTP.

    L'autore dell'attacco ha il seme HOTP fino a quando non viene resettato quel seme, che probabilmente non è mai.

  2. Al contrario, se il numero viene generato da random () e scritto nel database, non vi è alcun seed da compromettere. L'unico modo in cui può essere sfruttato è se l'utente malintenzionato avesse accesso in lettura in tempo reale al database.

From that quick outline it appears that seeded OTP (like HOTP) should not be used in these scenarios (voice, and SMS).

Is this a correct conclusion?

    
posta random65537 22.02.2013 - 16:20
fonte

1 risposta

3

Il punto delicato è la sincronizzazione pre-utilizzo. Quando si desidera utilizzare una password monouso, il client deve "in qualche modo" imparare la password monouso da utilizzare. HOTP è per le situazioni in cui questa sincronizzazione out-of-band avviene attraverso un contatore che viene mantenuto sia lato client che lato server.

Se disponi di un altro meccanismo fuori banda che può essere invocato su base per connessione (ad esempio un SMS), non è necessaria la gestione del contatore fornita da HOTP. HOTP è anche un buon PRNG , ma è più semplice generare casuali password monouso dalle strutture del sistema operativo ( /dev/urandom e il suo ilk). Come fai notare, HOTP è simile a un PRNG con una chiave segreta e il furto di chiavi implica un compromesso. Con una nuova password casuale per ogni connessione, un utente malintenzionato che può dare un'occhiata al database del server potrebbe apprendere l'OTP corrente per un dato utente, ma non saprà nulla sul prossimo OTP, quindi il danno è contenuto nel tempo.

L'utilizzo di HOTP (o la sua variante basata sul tempo TOTP ) nello scenario basato su SMS non è terribilmente debole - questo è un buon modello che supporta i token dell'utente. HOTP è un uso sensato della crittografia. Ma se disponi di un canale out-of-band disponibile per la trasmissione quasi-immediata dell'OTP (come un SMS), puoi utilizzare la generazione casuale che sarà ancora migliore.

    
risposta data 22.02.2013 - 16:50
fonte