Quanta entropia è richiesta per una Grid Card?

0

Stiamo implementando l'autenticazione multifactor. Un buon candidato per questo era la "Grid Card" - un piccolo tavolo con lettere e cifre casuali. Al momento dell'accesso, l'utente verrebbe interrogato per il contenuto di una cella nella griglia.

Esempio

Per un utente tipico, la griglia potrebbe essere simile a questa:

┌──┬──┬──┬──┐
│A9│64│UT│U4│
├──┼──┼──┼──┤
│K7│2C│4F│JK│
├──┼──┼──┼──┤
│3W│V9│V7│HH│
├──┼──┼──┼──┤
│TA│PN│KU│A7│
└──┴──┴──┴──┘

Il problema

Al fine di evitare simboli ambigui , il set di caratteri totale è stato ridotto a 23 caratteri in totale. Con una griglia 4x4 con due lettere ciascuno, ho ipotizzato che l'entropia totale di una query fosse circa 23 2 , che è solo 529. È sufficiente per un fattore secondario? In caso contrario, come può essere migliorata la sua sicurezza?

    
posta David Stockinger 24.05.2018 - 11:13
fonte

1 risposta

2

I assumed the total entropy of one query to be about 232, which is only 529

Il calcolo è corretto ma quello che mostri è il numero di varianti che non è uguale all'entropia o alla forza della password. Questo sarebbe invece di circa 9 dal 2 9 = 512.

Is this enough for a secondary factor?

Probabilmente no, ma dipende molto da come viene utilizzato questo secondo fattore. Se l'attaccante può fare supposizioni illimitate in breve tempo senza effetti collaterali, questo non è sicuramente sufficiente. Se invece il primo tentativo sbagliato provocherà la morte immediata dell'aggressore, anche questo semplice schema di forza bruta potrebbe essere troppo rischioso per iniziare anche con la forza bruta.

If not, how can its security be improved?

I modi ovvi sono di aumentare il numero di varianti, cioè inserire più lettere in ogni griglia, scegliere tra più simboli (ad esempio usare anche lettere minuscole), chiedere più di una sola cella della griglia ...

Oltre a tale limite, il numero di possibili tentativi di rallentare la forzatura bruta. Questo potrebbe essere un tempo di attesa crescente dopo ogni ipotesi errata o persino un blocco permanente dopo un numero specifico di tentativi errati. O aumentare i costi di ogni ipotesi sbagliata, in realtà richiede sempre più soldi per avere un'altra ipotesi :)

Quale di queste e simili proposte è effettivamente fattibile dipende molto dell'ambiente in cui viene utilizzato questo schema. Dipende anche dal valore delle attività che dovrebbero essere protette da questo schema, cioè i costi per rompere questo schema dovrebbero essere superiori a quelli che si possono ottenere come risultato in modo che la rottura del programma non sia attraente. Ciò significa che un altro modo di affrontare il problema è limitare ciò che l'attaccante può ottenere con una singola ipotesi corretta.

    
risposta data 24.05.2018 - 11:34
fonte

Leggi altre domande sui tag