Ho lavorato a un'idea per un gestore di password senza stato, ispirato a questo post sul blog . Utilizzo un generatore di numeri pseudo-casuali nel browser ( seedrandom.js ) inizializzato con la password principale di un utente per creare un unico (?) 26x26 tabula recta di personaggi. L'utente sceglie quindi un punto di partenza per ciascun sito Web e segue uno schema scelto attraverso la griglia per creare / accedere alle proprie password.
Seedrandom.js utilizza RC4 (RC4-drop[256] ) codifica stream, che non ritengo più sicura per la crittografia delle informazioni. Q1 : questo importa se lo sto solo usando come fonte di casualità per una griglia di caratteri 26x26 che non passerà mai su una rete (tutto viene generato lato client nel browser)?
Q2 : inoltre, qual è la tua analisi della forza di questo sistema rispetto a un attacco, sia prima che dopo che la password principale per la griglia di un utente è stata esposta? Questa domanda precedente parla di possibili attacchi a un tabula recta, ma le risposte si concentrano principalmente sul mantenimento del token fisico sicuro, che non si applica qui.
Questi sono i miei calcoli sul retro della busta:
Prima che la password principale sia nota, indovina una password di 16 caratteri :
log_2(88^16) = ~103
bit di entropia, che impiegherà molto tempo a decifrare in qualsiasi contesto.
Dopo la password principale, bruta forzatura di una password dalla griglia :
(26*26 cells) * (20 common patterns) * (8 pattern directions, including diagonals) * (20 potential password lengths, 10-30chars) = ~2 million options
Quindi in media ciò richiederebbe circa 2 million/2 = 1 million
di tentativi di crack. A seconda del contesto, questo sarebbe craccato in qualsiasi luogo da ~ 400 giorni (modulo web a tariffa limitata, 100 tentativi / ora ) a < < 1 secondo (perdita di database, algoritmo di hashing veloce, 1e10 tentativi / secondo ).
Esiste una demo di base di questo progetto qui .