È richiesta la complessità della password

1

Per un sito web sto usando quello che spero sia lo schema di archiviazione delle password più sicuro che riesca a trovare, che si riduce ad avere una password salata e hash memorizzata in un database di contatti: -

        Byte[] lPassword;
        var lRNG = new System.Security.Cryptography.RNGCryptoServiceProvider();
        var lSalt = new Byte[16];
        lRNG.GetBytes(lSalt);
        using (var lPDBGen = new Rfc2898DeriveBytes(Password, Salt, 1000)) {
            lPassword = lPDBGen.GetBytes(16);
        }
        ... Save lPassword and lSalt to the database ...

Se un utente malintenzionato accede a queste informazioni, in sostanza ha accesso ai dati protetti (non posso permettermi un server password sicuro separato).

Quindi, usare questo schema ha assolutamente lo scopo di richiedere qualsiasi forma di complessità sulla scelta della password dell'utente, fino a includere una password vuota?

    
posta Richard Petheram 07.10.2013 - 11:43
fonte

3 risposte

4

Sfortunatamente, non è possibile chiedere semplicemente per la complessità della password.

Quello che vuoi veramente, per la sicurezza della password, è che la password ha una alta entropia ; ma entropia non è una proprietà della password. Invece, l'entropia qualifica il modo in cui viene scelta la password. "Alta entropia" significa "la password potrebbe essere stata un sacco di altri valori".

Le usuali "pedine di password" non possono entrare nel cervello dell'utente umano, quindi non possono davvero indovinare come l'utente sceglie le sue password. Allo stesso modo, le "regole di complessità della password" non possono garantire password complesse; cercano solo di sfrattare l'utente dalla sua zona di comfort, per evitare alcuni metodi di generazione di password deboli classici. Ma in pratica, non funzionano. La casualità è difficile per il cervello umano. Gli umani non possono fare scelte davvero casuali nella privacy delle loro menti; invece, fanno scelte spiritose . Inoltre, non come sono costretti a fare scelte pseudo-casuali. Quando sono in vigore le regole sulla complessità della password, il risultato normale è che gli utenti creano soluzioni intelligenti, con la conseguente password che rispetta le regole, ma non sono casuali; quindi, password deboli.

Un caso tipico è quando le regole di complessità impongono che una password abbia almeno una cifra e almeno un segno di punteggiatura: in pratica, gli utenti reagiscono aggiungendo sistematicamente "1!" a qualsiasi password avessero voluto. Quindi le regole rendono la password più ma non più strong . Infatti, rendono anche le password più deboli perché quel tipo di suffisso sistematico conterrà comunque due caratteri per quanto riguarda la lunghezza della password. Se il tuo sistema impone una lunghezza minima della password di otto caratteri, le persone dovranno scegliere password di otto caratteri; ma se aggiungono un suffisso sistematico di due caratteri (e gli aggressori lo sanno, perché l'attaccante è un ragazzo intelligente che sa come pensano gli utenti tipici), allora possono farla franca con la regola della lunghezza della password con solo 6 caratteri casuali reali. In tal caso, la complessità della password si ritorce contro il fuoco: inducono comportamenti utente dannosi per la sicurezza, ovvero password più deboli.

L'unica "regola di complessità" che è ragionevole è una lunghezza minima (tipicamente 8 caratteri) perché mentre una lunga password non è necessariamente strong, una password molto corta è sempre debole, perché non ci sono abbastanza password possibili di 6 caratteri .

Tutti gli obiettivi sopra illustrati mirano a spiegare che le password scelte dall'utente saranno deboli, per una parte sostanziale degli utenti. Questo è un problema, ma il punto è che le "regole di complessità della password" non migliorano la situazione.

Ciò che può essere fatto è il seguente:

  • Utilizza una funzione di hashing della password corretta. . Questo è ciò che fai con PBKDF2 ( Rfc2898DeriveBytes implementa PBKDF2). Sali e iterazioni aiutano a gestire le password a bassa entropia, in una certa misura. Potresti voler aumentare il conteggio delle iterazioni, tuttavia: è probabile che il tuo server possa sostenere molto più di 1000 iterazioni e più alto è, meglio è.

  • Prova a rendere nulla la domanda. L'hashing della password deve essere utilizzato perché a volte capita che gli hacker ottengano una copia (parte del) database del server, con tutte le password hash; L'iniezione SQL, in particolare, spesso si traduce in un simile risultato. Tuttavia, è molto meglio se lo impedisci. L'hashing della password è una seconda linea di difesa necessaria, ma ciò non significa che la linea di difesa prima non sia importante.

  • Per gli attacchi al dizionario online , in cui l'utente malintenzionato parla al tuo server per ogni password indovina, applica i deterrenti: se troppe richieste di accesso provengono da un singolo IP in un tempo troppo breve, temporaneamente vietare l'IP.

  • Educa i tuoi utenti . Un buon modo per fare in modo che gli utenti scelgano password sicure è fornire un generatore di password . È importante che il generatore sia opzionale , altrimenti gli utenti lo ritengono un vincolo e si rifiutano di usarlo. Un generatore può fare affidamento sulla casualità reale (che è un computer, ha RNGCryptoServiceProvider ) e quindi soddisfare un obiettivo di entropia ragionevole. Un metodo di generazione password preferito è un pattern "aa00aa00" (due lettere, due cifre, due lettere e quindi due cifre). Tali password sono relativamente facili da ricordare e da digitare, e forniscono ancora un po 'più di 32 bit di entropia, il che è sufficiente purché si utilizzi PBKDF2 con un conteggio di iterazione sufficientemente elevato.

risposta data 07.10.2013 - 15:50
fonte
4

Non importa quanto sia strong l'algoritmo di hashing della password (beh, importa, ma non tanto) quando la password è stupidamente debole.

Le password comuni come password123 o ilovehowmileycyrustwerks scenderanno rapidamente a attacchi dizionario a prescindere.

    
risposta data 07.10.2013 - 11:47
fonte
0

La risposta di Tom riguardo a "educare i tuoi utenti" è tutto ciò che la comunità della sicurezza ha affermato a lungo. Tuttavia, non ha funzionato così bene nella pratica. Le ragioni sono complesse, ma si riducono a due concetti fondamentali: una catena è strong solo quanto il suo anello più debole e la vecchia battuta che il 50% dei tuoi utenti è al di sotto della media.

In primo luogo, l'analogia della catena. Di solito a un utente malintenzionato non interessa quale ID intromettersi. Se vengono dati 10.000 a crack, non appena hanno una sola password debole, sono dentro. E applicarlo agli utenti sotto la media, questo significa che se solo uno dei tuoi utenti è trascurato, distratto o ingannato, l'attaccante è in. La formazione delle persone aiuta a ridurre l'esposizione, ma a causa dell'analogia della catena non può fermare gli attacchi. Può mai essere invocato per fermare tutti gli attacchi.

Qui è dove devi eseguire il backup dei tuoi sistemi con la classica strategia di sicurezza della difesa in profondità. Non puoi semplicemente inserire una casella di password di fronte a un sito e lasciare tutto il resto così com'era, perché dovresti accettare come dato che uno o più dei tuoi utenti sono trascurati o in altro modo non attendibili.

Dal punto di vista di un attacco montato da un utente "fidato", molti sistemi sono meno testati per la sicurezza e presentano vari difetti che consentono l'escalation dei privilegi. Indirli prima, naturalmente. Ma hai ancora bisogno di proteggere adeguatamente anche i tuoi sistemi di back-end. È costoso, ma se hai mai visto un pen tester attraversare un sistema insicuro, capirai esattamente perché tutte le porte devono essere chiuse.

Dopo aver applicato le patch a tutti i tuoi sistemi, hai ancora l'insicurezza dell'utente "fidato" e ciò che gli permetti legittimamente di fare. Può trasferire facilmente tutto il suo bilancio a una banca della Cayman Island alle 3 del mattino da un indirizzo IP in Estonia? Forse non è una buona idea. Forse si aggiunge una fase di autenticazione a due fattori per le normali transazioni di medie dimensioni; qualcosa fuori banda come un messaggio SMS o e-mail? Forse hai bisogno di un ufficiale per contattarlo prima di approvare il trasferimento di una grande quantità?

    
risposta data 10.10.2013 - 00:16
fonte

Leggi altre domande sui tag