Dovremmo controllare le restrizioni della password sui moduli di accesso?

Consiglierei contro di esso. Se si desidera proteggere dagli attacchi di iniezione, ci sono altri modi fondamentalmente migliori (ad es. Istruzioni preparate per l'iniezione SQL o fuga corretta per altri canali), inoltre la password potenzialmente dannosa probabilmente passerà comunque i filtri di restrizione (dopotutto, probabilmente si applica minimo , non la lunghezza massima della password, consentire 'carattere ecc.)

Come ha detto Tom Leek, aggiunge complessità non necessaria. Se si desidera applicare la modifica della password a causa di nuove restrizioni in atto, è necessario farlo dopo l'autenticazione comunque, in modo da poter memorizzare il flag "la password non è più valida" in sessione, ma il controllo di validità deve essere un'aggiunta all'autenticazione elaborare e non eseguire prima di inviare la password a LDAP.

Controllare nuovamente una password già registrata è utile SE le regole che vuoi applicare sono cambiate E hai la possibilità di far cambiare la password dell'utente in modo che la nuova sia conforme alle nuove regole. Altrimenti è una perdita di tempo e aggiunge complessità (la complessità è Bad).

should we be intercepting the password the user has provided and check it against our original restraints the user was required to follow when creating the password before sending it to LDAP for authentication.

A che scopo? Questa è un'altra caratteristica per ottenere informazioni errate e perdite. Quanti vantaggi può offrire questa funzionalità per quanto costa ottenere, correggere errori e gestire problemi imprevisti che bloccano i clienti?

Bene, sono d'accordo con i commentatori, che una funzionalità che non implementate non può andare storta. Se lasci che il server LDAP gestisca la verifica della qualità della password, hai una posizione unica per configurarlo e sei sicuro che sia applicato.

Tuttavia ci sono due cose da considerare, prima di tutto dal punto di vista dell'esperienza utente è buono se il modulo di password (AJAX) dà effettivamente un feedback diretto se la password va bene o meno. Quindi implementerei sempre alcuni assegni banali per avere questo feedback (indicatore della forza della password con il livello minimo prima di poterlo inviare).

Inoltre, se si dispone di un'applicazione che dipende da un'infrastruttura condivisa, le capacità del server di directory esistente potrebbero non consentire il livello di controllo che si desidera eseguire (ad esempio l'esecuzione di cracklib estesi su un dizionario di grandi dimensioni). O potrebbe essere il caso che gli amministratori di directory non vogliano / possono considerare il tuo caso d'uso. In tal caso, la directory potrebbe non avere controlli abbastanza potenti.

Buone novità: se implementi i tuoi controlli e la directory ne ha una propria, e dato che usi effettivamente un protocollo corretto per impostare una nuova password (cioè impostala come utente target non come amministratore) puoi essere certo che il più strong di entrambi i controlli rifiuterà sempre, quindi non puoi indebolire la difesa.

Direi che se programmi un software COTS che dovrebbe essere usato in un contesto diverso, offri alcune politiche da limitare. Se ti trovi in un ambiente specifico, potresti ottenere uno stile di controllo di base dell'interfaccia utente.

Nota: non sto affatto discutendo l'idea delle politiche sulle password, ci sono pro e contro. È molto importante cercare di non limitare la complessità massima (set di caratteri e lunghezza). Questa non è solo una funzione di sicurezza, ma anche un'usabilità (accetta password generate automaticamente che sono comuni con le password sicure).

Password cannot be created unless all restraints are met.

I vincoli che hai menzionato sono raccomandati. Solo per ricapitolare.

• Lunghezza minima della password
• Caratteri consentiti
• Entrambi i numeri e le lettere
• Minima combinazione di caratteri alfa maiuscoli

Should we be intercepting the password the user has provided and check it against our original restraints the user was required to follow when creating the password before sending it to LDAP for authentication[?]

Which way is better? Why?

Nella prima domanda hai implicito (ma non hai esplicitamente dichiarato) che avresti mantenuto i vincoli di creazione delle voci LDAP originali (sopra) e poi hai chiesto "In che modo?" Penso che questa seconda domanda possa aver confuso le persone che cercavano di rispondere bene. Presumo che il tuo reparto NON stia pensando di sostituire il controllo originale, ma piuttosto di duplicarlo in precedenza nel flusso di dati tra la tastiera e la ricerca LDAP.

There is no reason to check what the user provides as a password to log in after they've already created it.

Non per sicurezza. Il segreto nel LDAP non è né più né meno a lungo termine se i vincoli vengono controllati in precedenza. Inoltre, non stai aumentando o diminuendo la forza della sicurezza LDAP controllando prima. Tutte le probabilità a lungo termine sono intatte.

Notate che continuavo a dire "a lungo termine". La velocità di un attacco di forza bruta potrebbe essere aumentata aggiungendo il controllo aggiuntivo perché le risposte negative potrebbero tornare più rapidamente con un controllo precedente. Lo spazio di permutazione valido (set di vincoli) potrebbe essere determinato più rapidamente da un aggressore intelligente se la risposta negativa ritorna più rapidamente.

Dall'altro lato, gli attaccanti possono avere comunque molto tempo. Inoltre, il tuo reparto potrebbe aggiungere un ritardo della risposta di errore di vincolo se lo ha scelto.

Other individuals in my department feel that those restraints should be checked again before sending the username/password combination to authenticate.

Per un attimo con gli altri individui per un momento, potrebbe esserci un valore per l'utente se le voci errate della password vengono rilevate prima. A nessuno piace aspettare 10 secondi durante i tempi di alto volume solo per scoprire che è stato premuto un tasto sbagliato non specificato.

Potrebbero esserci dei valori nella rete, nel server LDAP e nei livelli inferiori del sistema durante i periodi di caricamento elevati se gli errori di digitazione sono stati rilevati in precedenza. Dubito che il miglioramento sarebbe abbastanza significativo da giustificare l'aggiunta.

Personalmente, non aggiungerei il controllo extra perché ritengo sia più probabile ridurre la sicurezza piuttosto che aumentarla e aggiunge un'operazione di manutenzione. Ogni volta che i vincoli vengono modificati nel server LDAP, i vincoli devono essere modificati nel controllo precedente. Aggiungere un po 'di automazione per evitare tale necessità sarebbe un altro componente di sistema che dovrebbe essere mantenuto. Non è una grande idea.

Non vi è alcuna necessità impellente di contestare l'aggiunta se si crea un consenso nel dipartimento fornito

• I vincoli LDAP originali vengono lasciati sul posto,

• Il set di vincoli password è abbastanza conservativo in modo che gli attacchi di forza bruta non siano realistici anche se l'attaccante viene a conoscenza dei vincoli,

• E non sei personalmente addetto alla responsabilità di mantenere il nuovo controllo dei vincoli funzionante e perfettamente allineato con i vincoli del server LDAP.