Un protocollo per autenticare gli utenti senza login / password

3

Un scambio di messaggi casuali su reddit ieri mi ha fatto pensare se potrebbe essere possibile progettare un protocollo che rimuova la necessità per gli utenti di ricordare una password unica per ogni servizio a cui si connette.

L'idea è che essenzialmente ogni utente fornisce credenziali identificative (nome, data di nascita, città di nascita) e una frase segreta segreta. In base a queste informazioni e al servizio a cui si accede (facoltativo, nel caso in cui l'utente non desideri essere tracciato tra i servizi), il software client può generare in modo deterministico una coppia di chiavi RSA (utilizzando uno schema di hashing sicuro, forse SHA-512). / p>

Il componente pubblico di questa coppia di chiavi viene passato al servizio e funge sia da token di autenticazione che da chiave di crittografia. L'utente deve solo ricordare una pass-frase e le credenziali per accedere a qualsiasi servizio da qualsiasi client, con la chiave pubblica come identificazione sicura. È possibile utilizzare le chiavi effimere specifiche della sessione per la segretezza in avanti.

Mi chiedo quali sono gli svantaggi di questo schema? Non è suscettibile di spoofing a meno che l'impostore non imponga la chiave privata, la mancanza di password multiple lo rende più sicuro e affidabile per gli utenti. È suscettibile di MITM e di un client compromesso (perché vede la passphrase), ma oggi è lo stesso di SSL e la minaccia dei key-logger.

Quindi, mi stavo chiedendo se ci sono dei seri inconvenienti che mi sono sfuggiti, e anche se qualcuno volesse sperimentare con questo, avrebbe senso crearlo sopra TLS (un'estensione a http, forse), o per sostituirlo?

Grazie!

Modifica :
Grazie Thomas Pornin per la risposta ben ragionata. Mi chiedo se le seguenti sono valide confutazioni alle obiezioni sollevate:

1. Poiché in questo schema esiste una sola password, non è irragionevole che vi siano requisiti di complessità stringenti (ad esempio almeno 128 byte, ecc.), quindi non è suscettibile agli attacchi di dizionario. Gli attacchi ai dizionari sono in realtà gli stessi che dire se l'attaccante ha a disposizione infinite risorse, può forzare la forza con qualsiasi schema. Finché lo schema è tale che nessuna informazione può essere ottenuta indovinando porzioni di password, allora è sicuramente possibile rendere gli attacchi di dizionario poco pratici?

  1. Per quanto riguarda la necessità di cambiare la password: questo non sarebbe possibile all'interno del protocollo limitato descritto nella domanda. Forse quando si registra l'identità pubblica degli utenti, il server può inviare un segreto codificato con la chiave degli utenti che dovrebbe essere usato solo per invalidare l'identità quando richiesto? Finché esiste una chiave pubblica per servizio (cioè generata deterministicamente in base a una combinazione non modificabile di password utente e identità del servizio, un utente malintenzionato può solo compromettere l'accesso a un particolare servizio).

Btw, conosci qualche algoritmo noto per generare la coppia di chiavi basata solo su un numero (per esempio) di 512 bit? Suppongo che questo sia lo stesso che chiedere se esiste un modo per trovare l'innesco sicuro più vicino dato un numero. Grazie!

    
posta Amit 27.07.2013 - 17:19
fonte

2 risposte

5

La tua idea è duplice:

  1. Utilizza una coppia di chiavi asimmetriche lato client per l'autenticazione.
  2. Genera la chiave privata deterministicamente da una password.

La prima parte è un problema standard in SSL; vedi lo standard . I browser Web lo supportano (ma la loro interfaccia grafica è stata a lungo brutta, confusa o entrambe).

La seconda parte non è supportata dal software ampiamente distribuito, ma non è nuova, e funziona, con il seguente avvertimento: consente attacchi dizionario offline . Infatti, la chiave pubblica del client è pubblica e viene inviata "così com'è" (all'interno del certificato client) a qualsiasi server SSL che la richiede. Inoltre, per natura, il server deve vederlo a un certo punto. Poiché la chiave privata viene generata deterministicamente dalla password, un utente malintenzionato può quindi "provare" le password sulla propria macchina, cercando una corrispondenza con la chiave pubblica osservata.

In realtà molto generico . Considera un sistema e un protocollo, in cui client e server sono "aperti": nessuno di essi memorizza alcun valore segreto, agli occhi dell'aggressore - se il server può memorizzare i segreti, quindi l'elenco proverbiale delle password (hash) nel il database del server è sufficiente. L'unico segreto dell'intero sistema è la password dell'utente, che è memorizzata nella testa dell'utente, ed è sconosciuta all'attaccante. L'utente malintenzionato desidera recuperare la password.

In queste condizioni, per qualsiasi protocollo che potresti trovare , sono possibili attacchi di dizionario offline. Ciò è consustanziale all'apertura dei sistemi: poiché si presume che l'autore dell'attacco sappia tutto sull'intero setup tranne la password dell'utente, allora può emulare l'intera cosa sulle proprie macchine, per ogni potenziale password : l'utente malintenzionato esegue sia client che server in un ambiente virtuale sul proprio cluster.

Lanciare in RSA e hashing e tutto ciò non cambierà nulla in questo. Una volta che gli attacchi del dizionario offline sono possibili, si torna alla robustezza della password stessa. Esistono modi per tentare di far fronte agli attacchi del dizionario offline, ma la situazione è ancora, nel complesso, scomoda.

Per resistere agli attacchi del dizionario offline, devi avere un segreto sul client o sul server . Sul server, questo è il solito modello di password hash in un database che il server tenta di proteggere (con maggiore o minore successo); le password non vengono memorizzate "così come sono" ma come hash, come seconda linea di difesa. Sul client, è sufficiente memorizzare una chiave privata asimmetrica; possibilmente, crittografarlo localmente con una password, come seconda linea di difesa. Questo è supportato immediatamente dai browser esistenti (beh, almeno Firefox e la sua "password principale").

Oltre ai problemi di sicurezza relativi agli attacchi di dizionario, ci sono problemi pratici con la generazione di chiavi private deterministiche dalla password dell'utente. In particolare, cosa succede quando l'utente cambia la sua password? La sua coppia di chiavi cambia. Pertanto, tutti i server con cui viene utilizzata la chiave privata devono essere contattati per riconoscere la nuova chiave pubblica da accettare. Questo porta al ballo il solito problema della distribuzione della chiave pubblica , poi PKI, i certificati e il loro tipo. Questo ha ramificazioni a lungo raggio.

    
risposta data 29.07.2013 - 15:06
fonte
2

Si chiama autenticazione di certificato a due vie o autenticazione del certificato client ed è già stato supportato da SSL per un bel po 'di tempo. Semplicemente non viene utilizzato così tanto in the wild perché causa problemi con la gestione dei certificati quando si ha a che fare con più computer, il che rende più difficile agli utenti che un semplice nome utente e password.

Se si desidera vedere come funziona, è possibile verificare StartSSL.com, che è un'autorità di certificazione che utilizza un'autenticazione del certificato bidirezionale o al di fuori di un contesto Web, TeamSpeak 3 utilizza anche certificati client per l'autenticazione. È così che tiene traccia del tuo utente, ma non chiede mai un nome utente e una password. Lo chiamano un'identità e forniscono mezzi per spostarlo, ma è semplicemente un certificato client.

Poiché hai chiesto specificamente degli svantaggi, quello principale sta utilizzando più dispositivi e i problemi di gestione delle chiavi che ciò comporta. Un modo per aggirare è quello di fornire password monouso che consentono di collegare un altro computer e tenere traccia di più chiavi client che corrispondono all'utente. Senza associare una descrizione utente a ciascuna, è anche difficile rimuovere l'accesso da un dispositivo perso.

Un'implementazione ideale potrebbe memorizzare un certificato pubblico insieme a una descrizione del computer utilizzato per ciascun accesso e quindi consentire la generazione di una chiave una tantum da utilizzare su un altro computer per collegarlo al proprio account generale. Ciò consentirebbe di rimuovere un dispositivo perso accedendo su un altro dispositivo per rimuovere l'account. Una password (o altri mezzi di autenticazione) potrebbe anche essere utilizzata per eseguire la rimozione per impedire che il dispositivo perso rimuova i dispositivi legittimi.

Questo è anche spesso usato in combinazione con password in ambienti di sicurezza più elevati poiché richiede qualcosa che conosci (password) e qualcosa che hai (cliente cert). Si parla di autenticazione a due fattori in quanto richiede due dei tre fattori di base, chi sei (dati biometrici), cosa sai (password) e cosa hai (token, certificati, schede, ecc.).

    
risposta data 27.07.2013 - 18:48
fonte

Leggi altre domande sui tag