[Questa è la mia opinione, non sto affermando che rappresenti la visione del settore]

Sono assolutamente d'accordo sul fatto che alcuni dei dati segreti memorizzati sul dispositivo principale sfocino tra "qualcosa che conosci" e "qualcosa che hai". A quale lato della linea cade, penso, dipende dalle specifiche di cosa sono questi dati e da come funziona il protocollo di autenticazione, e da quale prospettiva si sta guardando.

Tecnicamente yubikeys, smartcard e persino OTP fobs , sono anche un pezzo di dati segreti memorizzati in software, anche se in un modo che è difficile anche per un utente malintenzionato con accesso fisico da estrarre. Discuterò che la cosa di cui si sta dimostrando il possesso non è il dispositivo, ma i dati segreti. Con i token hardware questi sono gli stessi, ma le persone vanno e applicano lo stesso modo di pensare ai telefoni e ad altri tipi di segreti e non sono sicuro che sia il modo corretto di pensarci.

Definizioni di "Conosci" o "Abbi"

Che tipo di segreto è, e in che modo il tuo dispositivo memorizza e accede a una scala mobile di sicurezza ( plain text file --> yubikey ). Da qualche parte in là si trova il confine tra "sapere" e "avere". Dove si disegna quella linea, penso, dipende pesantemente dalla prospettiva che si prende. Alcuni esempi:

• Prospettiva dell'utente finale: probabilmente traccia la linea in "venuto dalla mia memoria" e "è memorizzato su un dispositivo".
• Prospettiva amministratore di sistema: probabilmente tracci la riga se puoi chiedere nuovamente il dispositivo e essere sicuro che l'utente non abbia più il segreto.
• Prospettiva del server di autenticazione: nella maggior parte dei casi, il server non ha modo di sapere se il segreto proviene da un dispositivo sicuro o è derivato da una password digitata dall'utente. Quindi la distinzione rilevante dalla sua prospettiva è se si tratta di un segreto condiviso che sia sia del client e del server, sia che si tratti di una sorta di chiave pubblica che è necessario per provare il possesso di senza rivelare il segreto reale. La pratica cartina di tornasole è che "sa" tendere ad essere vulnerabile a registrare e ripetere attacchi, mentre "haves" tende a non esserlo.

Ci sono alcuni casi in cui tutti sono d'accordo: una password che l'utente digita in una casella di testo è chiaramente un "sapere" e una smartcard con una coppia di chiavi RSA è chiaramente un "avere". Ma non importa come tu definisca "sapere" o "avere", penso che ci saranno sempre dei casi limite che una delle prospettive di cui sopra considera un "sapere" mentre un altro considera un "avere".

Esperimento di pensiero

Diciamo che il sysadmin ti genera una nuova password casuale, la memorizza su un yubikey in modo tale che la chiave rilascerà la password crittografata su richiesta, e solo il tuo client VPN ha la chiave per decifrare e in realtà usa la password in chiaro (nessuna idea se questo è realistico, ma hey, è un esperimento mentale). È un sapere o un avere? Dal punto di vista dell'utente finale è certamente un ... non possono entrare nel loro account senza il fob. Dal punto di vista dell'amministratore è (per lo più) un avere perché a meno che l'utente non abbia fatto di hackerare il fob e il client VPN, l'utente non può imparare la password, quindi puoi chiedere il fob indietro e darlo ad un altro dipendente. Ma dal punto di vista del server è certamente un sapere perché tutto ciò che vede è una password in chiaro, non ha modo di dire se è venuto fuori da un dispositivo sicuro, o è stato digitato.

Prospettiva server

Come sviluppatore di applicazioni, la distinzione teorica che mi interessa è:

With "something you know" (ie passwords) you are sending the secret itself over the network to the server. With "something you have" (usually cryptographic keys or seeds) you never send the secret itself, but a one-time value or challenge response that proves you have possession of the secret.

Considera un man-in-the-middle che annusa il tuo traffico web. Possono rubare il tuo nome utente / password. Con OTP / yubikey / etc, i dati segreti sono una chiave crittografica o un seme RNG. Possono annusare tutti i messaggi che vogliono, non recupereranno mai il "qualcosa che hai" segreto.

Sto sostenendo che se il recupero del secondo fattore richiede che l'utente malintenzionato abbia accesso al tuo dispositivo (accesso fisico o rootkit) oa un altro tuo account, allora soddisfa la mia definizione di "qualcosa che hai".

Resistenza alla clonazione

La resistenza alla clonazione una volta che l'attaccante ha già accesso al dispositivo è chiaramente un bonus, ma (per me) non è necessario per soddisfare la definizione. Dopotutto, per fare un clone, l'attaccante ha già bisogno di "avere" il dispositivo. La differenza a quel punto tra l'essere in grado di usare il dispositivo per impersonare te e la possibilità di clonare il dispositivo per impersonarti è teoricamente priva di significato perché, in entrambi i casi, hanno già la capacità di impersonarti.

Sono abbastanza sicuro che non ci sia una risposta corretta a questo e simile a Mikes post questo è solo il mio punto di vista ...

La principale debolezza con l'utilizzo dei telefoni è la propensione a fare affidamento sui messaggi SMS per dimostrare l'accesso al dispositivo.

Anche se non banale, è possibile clonare una SIM senza accesso fisico al dispositivo o alla SIM, e fa affidamento sulle procedure dal controllo dell'autenticazione del sistema e in particolare dal controllo dell'utente. Per me questo regola questa opzione come un sistema 2FA a causa della natura essenzialmente sconosciuta dell'affidabilità dei controlli procedurali su cui esiste una dipendenza.

C'è un motivo per sostenere che questo non sarà un problema in un ambiente a basso impatto o per uno scenario di minaccia in cui è improbabile che i potenziali aggressori tenteranno di clonare una SIM. Può essere del tutto giustificato accettare il rischio (affidarsi a una dipendenza esterna con un'affidabilità sconosciuta), ma senza alcun modo di essere in grado di affermare anche soggettivamente un livello di sicurezza che un utente è in possesso di un dispositivo in un determinato punto tempo penso che possa essere descritto come una soluzione 2FA.

Ci sarebbe anche una domanda sul perché preoccuparsi di cercare di implementare un fattore aggiuntivo se lo scenario di rischio non ha bisogno che sia affidabile, o in un altro modo se la valutazione del rischio suggerisce che è necessario un fattore aggiuntivo almeno avere qualcosa che non sta introducendo un certo grado di falso senso di travisamento di sicurezza / controllo. Ciò è particolarmente rilevante se esiste la possibilità che il sistema di controllo degli accessi venga esteso a dati più sensibili in futuro, mentre le buone pratiche impongono che i controlli vengano riesaminati, se qualcuno non si preoccupa e sottoscrive sulla base di che 2FA sia implementato potrebbe essere una brutta sorpresa in anticipo.

D'altra parte i sistemi che installano un'applicazione con un contatore ciclistico su uno smartphone sono molto più vicini ad essere un'indicazione affidabile dell'accesso al dispositivo. Anche se un exploit remoto per accedere al dispositivo non è impossibile, è più complesso e (affermazione infondata e selvaggia) meno probabile.

Per alcuni scenari, penso che la convenienza e la probabilità che un telefono sia "protetto" dal proprietario significa che il compromesso richiesto da una soluzione 2FA basata su app vale la pena, di solito mi riferisco formalmente come pseudo-2FA o parole a questo effetto.

La maggior parte degli smartphone oggi dispone di una "memoria sicura antimanomissione", che può essere utilizzata per memorizzare i segreti OTP. Questi sono costruiti in modo da poter estrarre o copiare il valore segreto, ma possono essere "utilizzati" solo per il calcolo degli OTP.

Questo può quindi essere visto come "qualcosa che hai" in quanto l'hardware non può essere copiato, nemmeno con la tua collaborazione o negligenza. Fondamentalmente, il token e i suoi dati segreti sono "saldati insieme", quindi è necessario utilizzare il token per poter utilizzare i dati segreti.

Tuttavia, i "token soft" che si basano solo su segreti memorizzati su supporti non protetti, considererei più di "qualcosa che conosci".

Lo stesso vorrei applicare ai token fisici. Se il token può mantenere un segreto, allora lo considererei "qualcosa che possiedi". Se il segreto può essere facilmente copiato in qualche modo, allora il suo "qualcosa che conosci".

Vorrei utilizzare questo "test" per decidere se un token / smartphone potrebbe essere considerato "qualcosa che hai" o "qualcosa che conosci".

1: Immagina il dispositivo token o l'oggetto in questione.

2: Immagina che questo sia collocato su una panchina pubblica, lì sdraiato, diciamo un giorno intero.

3: Dopo 1 giorno, ritorni e trovi il tuo dispositivo.

4: Se il dispositivo può ancora essere considerato affidabile senza cambiare alcun segreto, allora il suo "qualcosa che possiedi", altrimenti è "qualcosa che conosci". Immaginiamo anche che, se è un telefono, viene riformattato e lo stesso segreto viene reinstallato nel telefono.

Un'altra considerazione facile è immaginare un dipendente canaglia. Riporti il token da lui (senza cambiare o sostituire alcun segreto). Può il dipendente canaglia accedere ancora al servizio in questione. Considera il fatto che il dipendente canaglia può manomettere il token per estrarne i segreti.

Normalmente un possession factor è rappresentato da una chiave crittografica.

Smartcard

La chiave privata, che è stata generata e non può (facilmente) essere estratta da una smartcard è probabilmente la chiave crittografica più sicura e quindi il miglior 2 ° fattore (possesso).

U2F

Un dispositivo U2F come yubikey ha anche una chiave privata, derivata da una chiave master. (La discussione sulla sicurezza di questa chiave master è fuori portata qui).

Yubikey

Un tokenkey utilizzato come token OTP utilizza una chiave segreta simmetrica per generare una password unica basata, ad es. su RFC 4226.

Keyfob

La maggior parte dei token keyfob hardware utilizza RFC 4226 o RFC6238 con una chiave segreta simmetrica. Bene: questa chiave è stata generata e scritta sull'hardware dal fornitore. Questo indebolisce pesantemente l'idea del fattore di possesso, dal momento che devi fidarti del venditore per distruggere qualsiasi copia di questa chiave segreta.

Smartphone

Ora veniamo allo smartphone. Google ha creato Google Authenticator. Lo definirei un secondo fattore, poiché funziona anche in base a una chiave crittografica (segreta) in base a RFC 4226 e RFC 6238. Ma il processo di implementazione dell'autenticatore di Google fa schifo . La chiave segreta all'interno dello smartphone risiede in un potente "computer" mal collegato online. Sì, lo smartphone, se utilizzato con un'app, è un secondo fattore, ma piuttosto debole.

Autenticazione a 2 vie

Se usi lo smartphone per ricevere messaggi push o SMS, non lo chiamerei un 2 ° fattore, piuttosto un'autenticazione a due vie. La differenza interessante è la seguente:

Puoi "proteggere" il tuo autenticatore google portando completamente il telefono offline. Un attaccante deve attaccare il telefono reale - il vero secondo fattore.

Se ricevi SMS, l'aggressore non ha assolutamente a cuore il tuo telefono. Il tuo telefono non è un secondo fattore. Potrebbe essere molto più facile per l'attaccante attaccare la rete (tecnicamente o socialmente) e reindirizzare l'SMS. Allora, dov'è il tuo secondo fattore / telefono? È totalmente fuori dall'equazione.

Ma dopo tutto quello che devi pensare, quanta sicurezza hai bisogno e quanti rimanenti rischi sei disposto a prendere.

A mio avviso, l'unica differenza tra "qualcosa che hai" e "qualcosa che conosci" è dove vengono archiviate le informazioni necessarie per l'autenticazione. Se è immagazzinato nella tua testa, è "qualcosa che conosci". Se è memorizzato su una smartcard o anche solo su un pezzo di carta, è "qualcosa che hai".

Ora ovviamente un pezzo di carta con un codice a barre su di esso sarebbe un'implementazione terribilmente insicura di "qualcosa che hai", così come chiedere ad un utente di dare il proprio nome e compleanno sarebbe un'implementazione terribile di "qualcosa che conosci", ma queste considerazioni sono completamente separate dalla definizione concettuale di ciascuno di questi fattori di autenticazione.

In pratica, anche se sei corretto, un fattore di autenticazione che intende implementare "qualcosa che hai" dovrebbe essere il più resistente possibile a un utente malintenzionato che cerca di clonare il token fisico utilizzato per l'autenticazione, proprio come un fattore di autenticazione che ha lo scopo di implementare "qualcosa che conosci" dovrebbe utilizzare informazioni che è difficile per l'hacker di indovinare o scoprire attraverso la sorveglianza o sotterfugi. Se un fattore di autenticazione è facilmente aggirato o compromesso, allora non è affatto un fattore di autenticazione.