Singola passphrase generata casualmente per identità e autenticazione

Question

Singola passphrase generata casualmente per identità e autenticazione

#1 da (2 voti)

3

Ci sono domande sull'utilizzo di una password solo per identificare e autenticare un utente, piuttosto che un indirizzo email o nome utente più password:

Tutti, tuttavia, riguardavano nomi utente e / o password impostati dall'utente con la possibilità di reimpostarli. Che dire di password / passphrase casuali che non possono essere ripristinate? Il salvataggio del cloud di DuckDuckGo mi ha fatto riflettere su questo, poiché utilizza le stesse passphrase casuali per identità e autenticazione, senza indirizzo email o nome utente coinvolti.

Diciamo che stiamo costruendo un servizio che memorizza i dati sui suoi utenti.

Se il servizio genera in modo casuale una passphrase / password (ad es. cinque parole casuali da un dizionario di 2000 parole) per ogni nuovo utente,
e l'identità di ogni utente è privata,
e non dobbiamo supportare il ripristino delle password dimenticate (ad es., perché utilizziamo le passphrase dell'utente per crittografare tutti i dati memorizzati dell'utente con SHA-512 con PBKDF2 o qualsiasi altra cosa),
allora quali rischi ci sono dall'usare solo quella frase casuale, piuttosto che richiedere anche un indirizzo email o un nome utente per identificare l'utente?
(Se la nuova passphrase si scontra con un altro utente durante la creazione di un nuovo utente, il servizio genererebbe automaticamente un'altra passphrase casuale e la userà invece.)

C'è un chiaro vantaggio: l'utente dovrebbe solo digitare la passphrase al momento dell'accesso, piuttosto che un email / username e una passphrase.

Per quanto riguarda i rischi, se un utente malintenzionato sapeva che una persona specifica era un utente del nostro servizio, l'utente malintenzionato dovrebbe tentare di forzare la passphrase dell'utente ... che in teoria dovrebbe essere difficile da eseguire in ogni caso.

Tuttavia, posso vedere il rischio che l'autore dell'attacco possa accadere accidentalmente sulla passphrase di un altro utente mentre sta provando a forzare la prima passphrase dell'utente, ottenendo l'accesso all'altro utente. Ma non è comunque una possibilità altrettanto piccola? Posso vedere come dipenderebbe da quanti utenti ci sono registrati nel servizio-se ci sono un account utente di quintilioni, allora sarà più facile ottenere casualmente l'account di qualcuno da brute-forzante. Non so come calcolare questo, però.

Ma ciò non pregiudica ancora la difficoltà di rompere i dati utente crittografati se l'attaccante ottiene l'accesso ai dati; il suo punto di forza dipende dalla passphrase e dalla crittografia solo se viene utilizzata o meno una e-mail / nome utente per l'identità.

Esistono altri rischi nell'utilizzo di passphrase casuali per l'identità e l'autenticazione / crittografia dei dati, senza e-mail / nomi utente?
Come si può calcolare la probabilità che un utente malintenzionato trovi la passphrase di qualsiasi utente dopo T, date N passphrase utente esistenti e D passphrase teoriche possibili possibili?

authentication identity passwords password-management passphrase

posta user3842252 13.03.2016 - 19:44

fonte

1 risposta

Leggi altre domande sui tag authentication identity passwords password-management passphrase

Come impedire la memcpy, causare l'overflow dell'heap? Come faccio a capire la differenza tra una "pagina di caricamento dei problemi" falsa e una vera e propria?

score 2 · Accepted Answer

I rischi includeranno quello che hai citato:

the attacker might incidentally happen upon another user’s passphrase while they’re trying to brute-force the first user’s passphrase, gaining access to the other user

Per ogni utente che viene aggiunto al tuo servizio, l'attaccante ottiene un'ipotesi "libera" durante il suo attacco. Nel tuo scenario di un utente malintenzionato che si rivolge solo a un singolo utente, questo non ha importanza, ma nel caso in cui un utente malintenzionato abbia solo bisogno di accedere a un account, ogni password che provano viene automaticamente testata su ogni account utente. Questo funziona sia in uno scenario online che offline (quest'ultimo potrebbe essere possibile se un utente malintenzionato ottiene l'accesso a tutti gli hash delle password archiviati - non è chiaro se li stai utilizzando o meno).

Un altro inconveniente è che il blocco automatico o la limitazione richiesta di tentativi ripetuti contro un particolare utente non è possibile. Questa è la mitigazione primaria contro gli attacchi di indovinamento della password.

if there are a quintillion user accounts, then it’s going to be easier incidentally getting someone’s account by brute-forcing. I don’t know how to calculate this, though.

Quintillion = 1,000,000,000,000,000,000
(World population 7,400,000,000)

Number of permutations = 2000^5 = 32,000,000,000,000,000

Chances that a guessed password (if the wordlist and method is known) 
matches an existing one of the quintillion accounts = 3.2%

Chances if everyone in the world has one account = 
2000^5 / 7,400,000,000 = ~1 in 4.3 million

Per rendere questi calcoli significativi è necessario conoscere la dimensione approssimativa della base di utenti. Dubito che sarà all'altezza degli esempi precedenti, ma con un quintario un attaccante ha solo bisogno di 32 ipotesi in media.