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.