Utilizzo della password, tra gli altri valori, come dati chiave nell'autenticazione a due fattori

3

Sto scrivendo un'implementazione e una tesi sull'autenticazione a due fattori, e sto attualmente facendo qualche ricerca. Attualmente sto esaminando un'implementazione per generare deterministicamente una chiave condivisa composita basata su determinati dati, che userò per TOTP. M'Raihi, et al specificano in RFC 4226 (capitolo 8, Composite Shared Secrets, pagina 14) che un composito chiave condivisa:

"[...] can consist of any data known at the token but not easily obtained by others."

Specificano i seguenti esempi:

  • PIN or Password obtained as user input at the token
  • Phone number
  • Any unique identifier programmatically available at the token

Per me è sembrato un modo abbastanza ragionevole per generare una chiave composita condivisa (con alcuni svantaggi che sono fuori dalla portata della mia domanda). RFC 4226 si presenta come un solido documento di alta qualità da una fonte attendibile con scrittori che hanno articoli su argomenti avanzati multipli. Per me sembra che gli autori e il documento possano essere considerati affidabili per l'implementazione sicura.

Ho quindi eseguito l'accesso a " Case for Mobile Two-Factor Authentication "(purtroppo richiede login / paga, ma posso accedervi gratuitamente usando il mio account universitario) di Dimitri DeFigueiredo, che è un ricercatore di crittografia e sicurezza in Adobe.

Il documento è più a, come nel caso del titolo, caso per l'autenticazione mobile a due fattori. Tuttavia, fa un paio di affermazioni che mi hanno interessato. Vale a dire il seguente, che a mio parere sembra contraddire RFC 4226 (enfasi mia):

"By itself, a stolen in-phone token shouldn't provide a way to authenticate an attacker and can't leak the corresponding PIN."

Questo mi ha fatto chiedere se usare una password in una chiave sia davvero una buona idea. La mia domanda principale è se l'uso della password nella chiave condivisa composita possa perdere informazioni su come viene generata la chiave condivisa. O peggio, compromettere completamente la sicurezza della chiave? Conosco questo tipo di conteggi come una seconda domanda intera, ma: i dati utilizzati per la chiave devono essere salati / pepati / hash o ciò compromette anche la sicurezza?

Come piccola nota: non penso che userò il documento di DeFigueiredo. Sembra che stia mescolando i PIN per sbloccare i telefoni con l'autenticazione a due fattori e alcune altre affermazioni vaghe che mi fanno dubitare della qualità del documento. D'altra parte ha un lavoro in Adobe come ricerca di crittografia, quindi potrebbe essere che non sto ottenendo quello che dice. Qualsiasi feedback sulla qualità di quel documento sarebbe molto apprezzato, se qualcuno avesse la possibilità di leggerlo.

    
posta Bono 05.11.2015 - 17:15
fonte

1 risposta

2

La parte importante di questa sembra essere la riga successiva nella RFC:

In this scenario, the composite shared secret K is constructed during the provisioning process from a random seed value combined with one or more additional authentication factors.

I dati chiave non dovrebbero mai essere solo i dati conosciuti a quel punto, ma dovrebbero essere derivati da esso utilizzando un processo strong, che dovrebbe assicurare che i singoli componenti di una chiave composta siano sufficientemente miscelati rendere impossibile la ricostruzione.

Ciò non contraddice necessariamente l'affermazione di DeFigueiredo: se hai utilizzato un PIN di 1234 e i tuoi token erano 1234-token1 e 1234-token2, chiaramente i token perdono il PIN. Se erano MTIzNC10b2tlbjE= e MTIzNC10b2tlbjI= , continuano a trapelare, solo leggermente meno ovviamente - queste sono solo le rappresentazioni di base 64 dei token di cui sopra. Se erano 32e38e71a26e560092e395a02fb85132 e bd7c0c61696eb5716fc866c21246e846 , ci vuole molto più sforzo per capire cosa sta succedendo - in questo caso, la rappresentazione esadecimale dell'hash MD2 delle stringhe sopra. Questo non è un processo di generazione strong, ma mostra il principio di base.

Pertanto, se hai un processo di generazione strong, puoi inserire quasi tutto ciò che vuoi e non perdere ciò che è successo.

    
risposta data 05.11.2015 - 17:40
fonte