Utilizzo di Cryptovariable con un'API progettata per le password generate dagli utenti

2

Sto lavorando con un fornitore che fornisce un'API con un metodo di registrazione utente chiaramente progettato per le password generate dagli utenti. Stiamo chiamando l'API in modalità offline da server a server, tuttavia, e registrando con l'API per conto del nostro utente.

Sono relativamente tranquillo con l'idea di generare il nostro cryptovariable, invece di riutilizzare la password dell'utente o costringere l'utente a generare la propria seconda password per l'API. In entrambi i casi, a causa della progettazione dell'API, saremo costretti a memorizzare la password / cryptovariable, che sarà inoltre crittografata sia a riposo che sul filo.

L'unico problema che ho è che l'API (di nuovo, apparentemente progettata per le password generate dall'uomo), ha alcune restrizioni sul formato della password che diminuiscono l'entropia quando si utilizza un generatore di numeri casuali crittografico per generare la "password" (più accuratamente un criptovariabile). Posso fare la matematica su tutti, tranne uno (e anche ottenere il codice corretto è abbastanza ragionevole).

Il più criptovariabile-ostile delle regole della "password" è che non ci possono essere sequenze ripetute di caratteri nella password. In altre parole (e non tenendo conto delle altre regole della password che l'API impone), "ab" e "ba" sono OK, ma "aa" e "bb" non lo sono. Per quel caso specifico, assumendo la lunghezza fissa di due e solo i due simboli 'a' e 'b', posso vedere che la restrizione dimezza esattamente l'entropia, e posso anche vedere che è meglio quando la lunghezza aumenta. Nel mio caso avrei solo raddoppiato la lunghezza e lo chiamerei un giorno, tranne che c'è anche una limitazione della lunghezza massima della password (doh!).

Quindi abbastanza sfondo - la mia domanda concisa è:

Qual è l'entropia di una cryptovariable lunga di 48 simboli a lunghezza fissa generata in modo casuale composta da 64 simboli (AZ, az, 0-9, + e /), dove qualsiasi combinazione con qualsiasi sequenza ripetitiva di simboli sono esclusi?

Per quanto riguarda l'edificazione personale, vorrei anche sapere non solo quale sia la risposta in questo specifico caso, ma vorrei anche capire come determinare l'entropia per le condizioni "non ripetitive" per varie lunghezze e set di simboli. Sembra che questo potrebbe anche essere un esercizio in un libro di testo di crittografia e piacerebbe un riferimento.

E, ora che sono pronto ad ammettere che ho passato più tempo su questo già di quanto avessi mai sperato, mi sto anche chiedendo:

Sto solo diventando paranoico?

Specificamente, poiché le password che seguono queste regole sono teoricamente "sufficientemente sicure" dagli attacchi di forza bruta che l'entropia rimanente è "sufficiente", posso, in coscienza, fidarmi solo che l'API sia abbastanza "abbastanza buono", chiamalo un giorno, e vai a bere una birra?

- Tim

P.S. Dovrei anche notare che sono aperto ad altre soluzioni out-of-the-box per il problema, ma ho già escluso di archiviare localmente la password generata dall'uomo dell'utente e chiedere all'utente in modo interattivo quando è necessario passarlo attraverso l'API.

Riutilizzare la password dell'utente ci obbligherebbe a memorizzare localmente la password personale dell'utente, piuttosto che usare la pratica più appropriata del settore di memorizzare un hash unidirezionale della password - quindi non vogliamo assolutamente fallo.

Forzare l'interazione dell'utente per generare una seconda password è sia una cattiva esperienza utente in generale, e praticamente garantisce un alto grado di riutilizzo della password da parte di molti utenti, quindi non vogliamo farlo neanche. Inoltre, e in modo più critico, stiamo accedendo all'API per lo più offline. Nonostante il bruciore di stomaco questo problema particolare mi sta dando, l'uso offline è pienamente supportato dall'API per la documentazione. In ogni caso, dal momento che stiamo accedendo all'API offline, in realtà non abbiamo l'opportunità di chiedere all'utente di inserire la password, quindi non possiamo farlo neanche.

    
posta Timothy Johns 27.02.2015 - 21:16
fonte

1 risposta

3

L'entropia del calcolo per una password scelta casualmente può essere suddivisa in una semplice regola che può essere utilizzata praticamente in tutti i casi, con alcuni avvertimenti. È il log2 () dello spazio del set di caratteri della password elevato alla lunghezza della password. Quindi, con una password completamente casuale in cui tutti i caratteri sono indipendenti, questo è un calcolo facile. E.G., Per una password lunga 8 caratteri e composta solo di lettere inglesi maiuscole, è: log2(26^8) o ~ 37,6 bit di entropia. Un altro modo leggermente più verboso per esprimere questo è: log2(26*26*26*26*26*26*26*26) . Se dovessimo aggiungere un vincolo alla nostra password, forse dovevano essere quattro caratteri maiuscoli e quindi due cifre, una password generata casualmente avrà log2(26*26*26*26*10*10) bit di entropia. (~ 25,4 bit)

Quindi, in un caso più complesso come il tuo, devi determinare quanti caratteri sono disponibili per ogni posizione successiva al fine di determinare lo spazio della password e quindi l'entropia. La condizione che vieta la ripetizione significa che non è possibile conoscere in anticipo l'entropia di una password specifica, poiché il set di caratteri da cui scegliere sarà limitato da caratteri già scelti ... Quindi è possibile calcolare solo l'entropia minima se i caratteri vengono scelti casualmente al massimo vincolare lo spazio dei caratteri per i personaggi successivi. In realtà non voglio calcolare questo calcolo specifico, ma in generale, per evitare sequenze ripetitive, è necessario limitare lo spazio dei caratteri solo all'ultimo carattere scelto (in modo da non ottenere bb) e se ci sono precedenti episodi di il personaggio precedente, i personaggi che seguono quegli incidenti. (Quindi se a questo punto la password è abcdbeb, dovresti escludere b, c ed e dallo spazio dei caratteri per il prossimo carattere.) Come puoi vedere, questo significa che man mano che la password aumenta di lunghezza, il carattere disponibile lo spazio non si restringerà solo, ma le sue dimensioni saranno conosciute solo dopo aver esaminato i personaggi scelti in precedenza.

Quindi, il metodo super semplice per determinare l'entropia minima con un margine di errore massimo che ho menzionato nel commento è semplicemente quello di escludere ogni carattere come viene usato. Senza la possibilità che un personaggio venga usato due volte, non c'è la possibilità di ripetere una sequenza. Con uno spazio di carattere che inizia con 64 caratteri e una password di 48 caratteri, questo è log2(64*63*62*...*16) che è un massiccio ~ 249,7 bit di entropia. Quindi, poiché sappiamo che dati i tuoi vincoli specifici, l'entropia delle tue password sarà più alta, hai un margine enorme e sicuro, e non c'è possibilità realistica di un attacco di forza bruta riuscito.

Per inciso, se non avessi vincoli e scelto casualmente 48 password di caratteri da un set di 64 caratteri, avresti avuto 288 bit di entropia.

    
risposta data 27.02.2015 - 23:48
fonte