È sicuro mostrare agli utenti perché la loro password non è permessa?

33

/////////////////////////////// Updated Post Below ////////////////////////////

Questa domanda ha ricevuto molti successi, più di quanto avessi mai pensato avrebbe avuto su un argomento così fondamentale. Quindi, ho pensato di aggiornare le persone su quello che sto facendo. Inoltre continuo a leggere nei commenti che sto memorizzando le password come testo normale. Giusto per chiarire Non lo sono.

La mia funzione di convalida aggiornata:

public function is_password($str) {
        if (strlen($str) < 10) { // Less then 10
            $this -> set_message('is_password', 'Password must include at least one number, one letter, one capital letter , one symbol and be between 10 and 100 characters long.');
            return FALSE;
        } elseif (strlen($str) > 100) { // Greater then 100
            $this -> set_message('is_password', 'Password must include at least one number, one letter, one capital letter , one symbol and be between 10 and 100 characters long.');
            return FALSE;
        } elseif (!preg_match("#[0-9]+#", $str)) { // At least 1 number
            $this -> set_message('is_password', 'Password must include at least one number, one letter, one capital letter , one symbol and be between 10 and 100 characters long.');
            return FALSE;
        } elseif (!preg_match("#[a-z]+#", $str)) { // At least 1 letter
            $this -> set_message('is_password', 'Password must include at least one number, one letter, one capital letter , one symbol and be between 10 and 100 characters long.');
            return FALSE;
        } elseif (!preg_match("#[A-Z]+#", $str)) { // At least 1 capital
            $this -> set_message('is_password', 'Password must include at least one number, one letter, one capital letter , one symbol and be between 10 and 100 characters long.');
            return FALSE;
        } elseif (!preg_match("#\W+#", $str)) { // At least 1 symbol
            $this -> set_message('is_password', 'Password must include at least one number, one letter, one capital letter , one symbol and be between 10 and 100 characters long.');
            return FALSE;
        } else {
            return TRUE; // No errors
        }     
    }

Ogni volta che restituisce FALSE , dico sempre loro che è necessaria l'intera password.

Solo per rispondere ad alcune domande sul motivo per cui è così lungo:

Perché non così tanto tempo? Le persone nel mio lavoro con cui parlo usano frasi. Quelli molto lunghi.

Come faccio a tagliare le mie password? / Perché usare 100 caratteri? - > basta usare un algoritmo di hashing migliore

Per PHP, sto usando il meglio che c'è per questa lingua. Sto usando questa libreria che è l'equivalenza di PHP 5.5 di nuova API hashing password creata da Anthony Ferrara. Il mio ragionamento per questo hashing l'uso è semplice, molto elevato nella CPU (se lo provi su una macchina Linux / Windows l'utilizzo della CPU è al 100%). Inoltre, l'algoritmo è molto scalabile a causa del fattore costo, più alto è il costo, più faticoso è il compito della CPU di registrare una persona. Last I "Tested" , ho messo il costo a 24 Mi è passata un'intera ora per provare ad accedere e ho ricevuto un errore di timeout PHP prima ancora di aver superato la schermata di accesso (questo era un fattore di costo folle). Uno studio condotto da Jeremi Gosney (QUESTO È IL DOWNLOAD PDF DEL REPORT) che ha testato la forza di questa funzione rispetto ad altri più popolari (sì, più popolari) ha concluso che anche con 25 - GPU, mentre si utilizza bcrypt al costo di 5 l'hashing della password è l'ultimo dei tuoi dubbi. Io uso un costo di 17 ...

La mia funzione se qualcuno è interessato (le parti che riguardano almeno questo argomento):

public function create_user($value) {
        $this -> CI = get_instance();
        $this -> CI -> load -> library('bcrypt');

        foreach ($value as $k => $v) {// add PDO place holder to the keys
            $vals[":$k"] = $v;
        }
        $vals[":password"] = $this -> CI -> bcrypt -> password_hash($vals[":password"], PASSWORD_BCRYPT, array("cost" => 17)); // Take old $vals[":password"] and run it through bcrypt to come up with the new $vals[":password"] 

Speriamo che questa domanda aiuti gli altri là fuori.

/////////////////////////////// Original Post Below ////////////////////////////

Attualmente sto lavorando a un nuovo progetto e un problema mi ha colpito.

È sicuro divulgare i requisiti della password? Se è così, perché è sicuro?

Ho una funzione che esegue la convalida su una password e ogni fase mostra all'utente perché la convalida non funziona.

Ecco la mia funzione:

public function is_password($str) {
    if (strlen($str) < 10) {
        $this -> set_message('is_password', 'Password too short.');
        return FALSE;
    } elseif (strlen($str) > 100) {
        $this -> set_message('is_password', 'Password is too long.');
        return FALSE;
    } elseif (!preg_match("#[0-9]+#", $str)) {
        $this -> set_message('is_password', 'Password must include at least one number.');
        return FALSE;
    } elseif (!preg_match("#[a-z]+#", $str)) {
        $this -> set_message('is_password', 'Password must contain at least one letter.');
        return FALSE;
    } elseif (!preg_match("#[A-Z]+#", $str)) {
        $this -> set_message('is_password', 'Password must contain at least one capital letter.');
        return FALSE;
    } elseif (!preg_match("#\W+#", $pwd)) {
        $this -> set_message('is_password', 'Password must include at least one symbol.');
        return FALSE;
    } else {
        return TRUE;
    }
}

Il mio pensiero su questo è, se lasciamo che l'utente / utente malintenzionato sappia in cosa consistono le mie password, non sarebbe più facile per l'hacker saperlo? So che la sicurezza attraverso l'oscurità non è una buona pratica, ma potrebbe essere un argomento valido in questa situazione?

Vorrei sapere se sto andando su questo nel modo giusto. Qualsiasi aiuto sarebbe fantastico.

    
posta Rixhers Ajazi 13.08.2013 - 20:21
fonte

4 risposte

100

Se non divulghi i tuoi "requisiti per la password", i tuoi utenti ti odieranno. Alcuni non riusciranno a trovare una "password accettabile" e chiameranno l'helpdesk. O, peggio, se gli utenti sono clienti allora andranno a comprare altrove. Un ottimo modo per uccidere la tua attività!

D'altra parte, se divulgare i "requisiti della password" aiuta davvero gli aggressori in modo non trascurabile, i requisiti della tua password sono terribilmente pessimi: non solo si contrappongono agli utenti, ma limitano anche gli utenti in un troppo piccolo set di password possibili.

Nota che gli attaccanti di solito riescono a indovinare piuttosto bene quali sono i tuoi "requisiti per la password", ad es. cercando di registrarsi.

In ogni caso, i "requisiti della password" sono controproducenti e riducono la sicurezza, salvo per una "lunghezza minima" che può essere giustificata razionalmente. Quindi non farlo. La chiave per la sicurezza della password è educazione dell'utente , eventualmente supportata da alcuni strumenti (ad esempio un generatore casuale per password complesse). L'applicazione dei vincoli non aiuta; e applicare i vincoli nascosti è solo peggio. Ad esempio, se le tue regole richiedono almeno una cifra e un simbolo, una percentuale sorprendentemente alta di utenti aggiungerà semplicemente "1". alla fine della loro password; gli attaccanti lo sanno. Il suffisso aggiuntivo non aggiungerà molto all'entropia della password (ovvero il numero di potenziali password che l'utente malintenzionato deve tentare per un'interruzione riuscita) ma utilizzerà una parte della risorsa scarsa nota come "pazienza dell'utente": gli utenti preferiranno password più brevi, dal momento che devono aggiungere il "1" suffisso per placare il tuo server.

    
risposta data 13.08.2013 - 21:00
fonte
27

Se non comunichi all'utente esattamente ciò che è necessario nella sua password per passare attraverso la convalida della tua funzione, come potrebbe sapere cosa aggiungere o modificare per renderlo valido?

Fornire tali informazioni potrebbe portare a un attacco di forza bruta più facile. Tuttavia, considerando le tue esigenze, non aiuta affatto l'aggressore perché ci sono troppe possibilità di password per rendere un attacco utile.

    
risposta data 13.08.2013 - 20:38
fonte
17

Probabilmente gli utenti / clienti si astengono dall'utilizzare il servizio una volta che il terzo tentativo di inserire una password valida non è riuscito. Gli hacker al contrario cercheranno di registrarsi arbitrariamente spesso per capire i requisiti della tua password nel modo più preciso possibile.

Per contrastare questo, convalidare l'utente prima tramite i soliti mezzi (email, captcha ecc.) e inviare loro un token password. Ciò riduce già la quantità di utenti falsi e validi, e bloccando troppe modifiche della password in un momento specifico, rendendo più difficile la vita degli hacker. Tuttavia dovresti comunque rivelare i requisiti della tutti della password entro e non oltre il primo tentativo di inserirne uno non valido.

Ma ancora meglio, raccomando non di forzare gli utenti a scegliere una password arbitrariamente complessa che semplicemente finiranno con scrivere su un post-it accanto a il loro monitor (o averli reimpostare la propria password come "login" semplificato). Invece, fagli sapere che la loro password è debole, digli che cos'è una password buona ma memorabile (es. Usa una pass-em> frase ) e permetti loro di procedere comunque dopo facendo clic su "Sì, ho capito che la mia password non è molto sicura, lasciatemi procedere comunque" - è colpa loro se l'account viene violato e quindi non si dovrebbe essere ritenuti responsabili dopo questo avvertimento esplicito. Supponendo che tu hai usato un hashing della password corretto e definito invece di homebrew-crap o, peggio, testo in chiaro.

    
risposta data 14.08.2013 - 11:40
fonte
8

Pensa allo scenario: in che modo l'attaccante ottiene i requisiti? Molto probabilmente perché possono registrarsi. In tal caso è banale decodificare le tue esigenze a meno che non siano troppo complesse da usare senza una spiegazione. Quindi, sì, è sicuro che l'utente sappia quali sono le sue esigenze.

Ma un approccio migliore è quello di non richiedere affatto una password, OpenID se possibile. È quasi certamente sicuro almeno quanto qualsiasi altro per la raccolta e la memorizzazione delle password. E per chiunque abbia un account gmail o yahoo, sarà sicuramente più semplice.

    
risposta data 14.08.2013 - 03:45
fonte

Leggi altre domande sui tag