Utilizzo di una tabula nel browser per generare password

2

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 .

    
posta pst0102 25.01.2018 - 02:42
fonte

2 risposte

3

Il tuo sistema probabilmente funzionerebbe in teoria, ma sembra in pratica molto difettoso. Ci sono diversi punti deboli pratici nel modo in cui sarà usato:

  1. Non descrivi come convertirai la password principale nel seme per l'RNG. Questo è potenzialmente un punto debole.
  2. Non hai specificato in che modo gli utenti assoceranno un punto di partenza a un determinato sito. Senza un modo per salvare questo, sarà impossibile da usare. A seconda della memoria dell'utente, il riutilizzo della password sarà
  3. Gli utenti tenderanno a scegliere lo stesso numero o un numero limitato di punti di partenza nella tabella in base alla tendenza umana, riducendo significativamente l'entropia.
  4. Una tabula recta richiede più lavoro manuale di quello che gli utenti vorranno effettivamente utilizzare nella pratica.
  5. RC4 ha pregiudizi nel keytream iniziale. Se questo non è corretto nel tuo RNG, questo inserirà pregiudizi nel tuo tabula recta.
  6. Non è un buon modo per gli utenti di ruotare le password se non selezionando un nuovo punto di partenza per quel sito. Combinato con il n. 2, questo renderà ancora più difficile per gli utenti ricordare il punto di partenza per un determinato sito.
risposta data 25.01.2018 - 03:21
fonte
0

a 26x26 grid of characters that won't ever pass over a network

Questo non è completamente vero. Ogni password espone un po 'di questa griglia. Se l'utente malintenzionato ottiene una password, ha una parte della griglia e può utilizzarla per provare a forzare la password principale.

Per rendere più difficile la brute-forzatura della password principale, è possibile utilizzare una funzione di derivazione della chiave come PBKDF2, in modo che la griglia sia basata su seedrandom(pbkdf2(master_password)) . Ciò rallenta gli attacchi di forza bruta e rende irrilevanti tutte le insicurezze in RC4.

    
risposta data 25.01.2018 - 08:51
fonte