Le uscite di questo software di generazione di stringhe casuali sono sicure da utilizzare come password complesse?

1

Più di un anno fa, ho creato un piccolo software basato su moduli.

È uno scopo, come afferma il titolo, è generazione di stringhe casuali .

Ha opzioni per combinare numeri, maiuscoletto, maiuscoletto e caratteri speciali all'interno del set di caratteri ASCII (94 in totale). Avrà presto il supporto per UTF-8 (e sarà contrassegnato come opzionale / sperimentale, perché alcuni siti Web non consentono nulla tranne ASCII per le password).

Utilizza RNGCryptoServiceProvider class e i suoi metodi ( GetBytes() e ToString() ) per produrre un output.

Se selezioniamo tutte le opzioni (ASCII intero), abbiamo 94 caratteri. Specifichiamo che vogliamo che il nostro output sia lungo 64 caratteri.

La nostra forza in bit è: 94 ^ 64 o log (base 2, 94) * 64 = 419

EDIT: Esempio: 4Ed(R{MQ_U9pQ#?9k'V2p1bpW+UrEBkebif9w'Qsp>n7i~PF,]DCdV18sqilN(ou

Domanda 1: È sicuro utilizzare questo output come password complessa?

Domanda 2: C'è altro che dovrei implementare per migliorare la sicurezza?

Linguaggio di programmazione: C #

IDE: SharpDevelop 4.4

Framework: .NET 4.5

    
posta Miloš Veljanoski 30.05.2017 - 10:06
fonte

3 risposte

1

Il modo ingenuo di fare questo:

... {
    result.Append(chars[b % (chars.Length)]);
} 
tbOutput.Text = Convert.ToString(result);

produrrà una password con distribuzione di caratteri non uniforme, che è un punto debole.

Un modo per generare un output non distorto (non testato e non sono un programmatore C #, quindi parte della sintassi potrebbe essere disattivata), nota che probabilmente questo non è il metodo più efficiente per fare ciò:

RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider(); 
System.Text.StringBuilder result = new System.Text.StringBuilder();

// assumption: chars.Length < ulong.MaxValue
ulong bound = ulong.MaxValue - (ulong.MaxValue % chars.Length);

while (result.Length < desiredPwLen) {
    // assumption: ulong is 64-bit
    ulong rndNum;
    do { 
        byte[] rndBytes = new byte[8]; // assumption: 1 byte is 8 bits, so 8 bytes is 64 bits
        rng.GetBytes(rndBytes);
        rndNum = BitConverter.ToUInt64(rndBytes, 0);
    } while (rndNum >= bound); // rndNum above bound is biased, so we discard them, and roll again

    result.Append(chars[rndNum % chars.Length]);
}
string password = result.ToString();

Rispondi alle tue domande:

  1. Is it safe to use this output as a strong password?

Probabilmente sì, mentre il metodo di codifica della password ha la debolezza che ho menzionato sopra, se la lunghezza della tua password è abbastanza lunga, allora avrebbe compensato il bias.

  1. Is there anything else I should implement to enhance security?

Ho fornito sopra un miglioramento che corregge il bias.

    
risposta data 30.05.2017 - 16:36
fonte
0

Da un punto di vista della sicurezza, quello che descrivi sembra ok, a patto che tu chieda effettivamente un personaggio da un set (detto in modo diverso come un intervallo casuale compreso tra 1 e 94 per un set completo di dimensioni del set effettivo per un sottoinsieme) .

Dal punto di vista dell'usabilità, ciò che descrivi non è lontano dal generatore di password dell'eccellente Keypass . Infatti, forniscono diversi set di caratteri speciali:

  • puoi includere separatamente - , _ e spazio
  • le parentesi hanno una propria classe ( (){}[]<> )
  • tutti gli altri caratteri speciali si trovano in un'altra classe

Suppongo che abbiano dovuto implementarlo perché alcune regole di sicurezza (mal progettate) lo richiedono.

Come funzionalità avanzate, consentono anche:

  • ogni carattere può apparire solo una volta nella stringa password
  • non consentire caratteri simili (0 e O, 1 e l)

Anche in questo caso è stato necessario implementarlo per far fronte a stupide regole di sicurezza.

Spetta a te includere o meno tali regole, dipende principalmente dall'utilizzo previsto.

Potresti anche guardare altri generatori di password esistenti per vedere se altre restrizioni potrebbero essere rilevanti.

    
risposta data 30.05.2017 - 11:24
fonte
0

Come è stato accennato a serge, se è "sicuro" dipende da ciò che fai con esso. Recentemente ho avuto qualche problema nel garantire che le password generate funzionino quando vengono incollate nei file di configurazione o anche incorporate in file .bat. Si scopre che esiste un lotto di software scritto male là fuori che non fornisce alcun mezzo per l'escape sicuro delle stringhe e ho riscontrato problemi con virgolette, caratteri di reindirizzamento dell'IO e altro.

Riguardo alle "classi" - queste regole di solito esistono per incoraggiare gli esseri umani a scegliere password migliori (ma non ho visto alcuna seria ricerca sul fatto che effettivamente funzionino). Ciò annulla la possibilità di utilizzare un set di caratteri "sicuro" più piccolo (minuscolo + maiuscolo + cifre) con una lunghezza maggiore per ottenere la stessa entropia.

Senza vedere il tuo codice, ho alcune riserve sulla tua stima dell'entropia. Sembra che tu stia utilizzando RNGCryptoServiceProvider.toString () su una stringa binaria ma documentation rivela poco su come viene eseguita questa conversione. Mentre considererei qualcosa di più lungo di 10 caratteri (e che richiede regole come le classi) troppo difficili da ricordare, ci sono contesti in cui c'è una complessità minima richiesta.

    
risposta data 30.05.2017 - 17:01
fonte

Leggi altre domande sui tag