it-swarm-eu.dev

Come funziona 2FA di Authy, se non si connette al server?

Pensavo di sapere come funziona l'autenticazione a due fattori:

  • Inserisco la password.
  • Il server genera un numero casuale (token) e me lo invia via SMS.
  • Entro in questo token.
  • Il server verifica che il token immesso corrisponda a quello generato per la mia precedente richiesta 2FA.

Ma oggi ho scoperto Authy e sembra che non sappia come funzioni l'autenticazione a due fattori (2FA) di questo programma.

Authy mi mostra numeri segreti (token 2FA) senza alcuna connessione con il server. Come può essere?

Suppongo che questi token non siano casuali? Forse è una specie di sequenza numerica, dove conoscere i parametri di seeding iniziale rende questo un processo deterministico? Forse questa sequenza è una funzione del tempo? Funziona così?

È sicuro? Posso, ad esempio, determinare i token 2FA successivi, se conosco un numero [~ # ~] n [~ # ~] dei token precedenti?

24
demas

Mostra automaticamente numeri segreti senza alcuna connessione con il server. Come può farlo?

Authy sta usando un algoritmo OTP (one-time passcode) disponibile in vari modi, i due più popolari sono OTP (HOTP) basato su HMAC e OTP (TOTP) basato sul tempo. Authy sta usando TOTP.

Entrambi gli algoritmi sono essenzialmente gli stessi; richiedono alcuni dati seed e un contatore per generare il passcode successivo nella serie. Le implementazioni HOTP incrementano il contatore ogni volta che l'utente richiede/utilizza un passcode, TOTP incrementa il contatore dopo un determinato intervallo di tempo.

Nel caso di Authy, quando l'utente invia un passcode al server, il server cerca i dati seed dell'utente, calcola il valore del contatore in base al timestamp della richiesta e quindi genera il passcode corretto. Il server verifica quindi che il passcode generato corrisponda al passcode inviato dall'utente.

È sicuro? Posso sapere il prossimo numero se conosco N numeri precedenti?

Sì e no, dipende dall'affidabilità o meno della sicurezza del server.

Dato N token precedenti, un utente malintenzionato non dovrebbe essere ancora in grado di recuperare i dati di seed. Tuttavia, questi algoritmi richiedono che il server memorizzi i dati seed per tutti gli utenti. Se un utente malintenzionato è in grado di compromettere il database (tramite SQL injection, ecc.), Sarà in grado di generare passcode validi. Questo è quello che è successo a RSA e ai loro token SecurID ( http://arstechnica.com/security/2011/06/rsa-finally-comes-clean-securid-is-compromised/ )

Alcune aziende come Duo Security ( https://www.duosecurity.com/ ) e Twitter ( https://blog.Twitter.com/2013/login-verification-on-Twitter -per-iphone-and-Android ) stanno affrontando questo problema implementando l'autenticazione a due fattori challenge-response con crittografia a chiave asimmetrica. In questo caso devono solo archiviare le chiavi pubbliche, il che significa che se il loro database è trapelato, un utente malintenzionato non dispone delle chiavi private necessarie per generare risposte valide.

Disclaimer, ho lavorato in Duo.


Aggiornato in base alle domande nei commenti

Gli algoritmi (HOTP o TOTP) devono essere gli stessi sul server e sull'applicazione client?

L'algoritmo è identico, il modo in cui viene generato il valore del contatore è diverso. Se Google fosse HOTP e Authy volesse supportare gli account Google, la loro app dovrebbe generare e archiviare il valore del contatore in modo diverso dagli account TOTP.

Il client HOTP richiede una connessione con il server per ottenere il prossimo passcode (perché non sa quante richieste sono state fatte dall'ultima volta), mentre TOTP non lo richiede?

No, HOTP non richiede una connessione per funzionare, ma HOTP non viene generalmente utilizzato perché è facile che il telefono e il server non siano sincronizzati.

Supponiamo che sia il server che l'app inizino con un valore contatore pari a 0. Il server di solito ha una finestra, forse i successivi 10 passcode, che considererà validi. Quando l'utente invia un passcode, il server confronta il passcode inviato con i successivi 10 passcode generati. Se uno qualsiasi dei 10 corrisponde, il server può aggiornare il valore del contatore memorizzato e rimanere sincronizzato.

Il problema però è che l'utente potrebbe essere in grado di generare troppi passcode nell'applicazione senza usarli. Se l'utente è in grado di incrementare il contatore oltre la dimensione della finestra del passcode, il server non può più verificare che i passcode siano validi.


Per vedere in dettaglio come vengono generati i token OTP, vedere questo post sul blog informativo .

30
JackWink

Sembra che comunichi usando una semplice REST. In termini di sicurezza dei token -

Il token viene generato utilizzando una funzione a 1 via (SHA-2) e un tasto a 256 bit. Anche se l'attaccante avesse accesso a centinaia di token, sarebbe comunque matematicamente impossibile generare un nuovo token valido. Se sei propenso a saperne di più, Authy si basa su RFC4426 ( http://www.ietf.org/rfc/rfc4226.txt ).

In breve: Sì, utilizza un metodo sicuro per generare un token.

0
Ashley B