Citazioni per l'invisibilità della password univoca a livello globale

Sono in disaccordo con qualcuno (un cliente) sul processo di identificazione / autenticazione dell'utente per un sistema. Il nocciolo di ciò è che vogliono che ogni utente abbia una password univoca a livello globale (cioè che due utenti non possono avere la stessa password). Ho sollevato tutte le ovvie argomentazioni contro questo (è una vulnerabilità della sicurezza, confonde l'identificazione con l'autenticazione, è inutile, ecc.) Ma stanno insistendo sul fatto che non c'è nulla di sbagliato in questo approccio.

Ho fatto varie ricerche su Google alla ricerca di opinioni autorevoli (o semi-autorevoli, o anche solo indipendenti) su questo, ma non riesco a trovare alcuna (principalmente è solo un passo falso così ovvio che non sembra degno di preavviso, come per quanto ne so). Qualcuno può indirizzarmi verso tale opinione indipendente, per favore?

[EDIT]
Grazie per tutte le tue risposte, ma capisco già i problemi con questo approccio / requisito proposti e posso persino spiegarli al cliente, ma il cliente non li accetta, quindi la mia richiesta di fonti indipendenti e / o autorevoli .

Avevo anche trovato l'articolo del Daily WTF, ma soffre del problema che Jon Hopkins ha sottolineato: che questo è un WTF così evidente che non vale la pena spiegare perché .

E sì, le password verranno salate e cancellate. Nel qual caso l'unicità globale potrebbe essere difficile da garantire, ma ciò non risolve il mio problema - significa solo che ho un requisito che il cliente non si muoverà, che non è solo sconsiderato, ma è anche difficile strumento. E se fossi in grado di dire "Non sto saltando su salatura e hashing", allora sarei in grado di dire "Non sto implementando password uniche a livello globale".

Eventuali puntatori a fonti indipendenti e / o autorevoli sul perché questa è una cattiva idea ancora ricevuto con gratitudine ...
[/ EDIT]

Ogni volta che un client tenta di creare una password già esistente, riceve un feedback sul fatto che alcuni utenti già utilizzano quella password, di solito una violazione del contratto sulla privacy.

Accanto a questo, i nomi utente sono molto più facili da indovinare (e se c'è un forum, potresti trovare molti nomi utente lì) e stai suggerendo agli utenti modi per hackerare il sito web.

Dovrebbe esserci qualche pagina su Internet da qualche parte che descriva la parte della violazione dell'accordo sulla privacy, a parte questo è solo buonsenso: in pratica darebbero a qualcuno una chiave e un elenco di indirizzi di casa.

EDIT: non vicino all'autorevolezza, ma forse utile dopo aver spiegato loro cosa significa WTF: http://thedailywtf.com/Articles/Really_Unique_Passwords.aspx

Le migliori pratiche impediscono di soddisfare i requisiti:

Non puoi farlo perché non sai quali sono le password, quindi non puoi confrontarle perché tutto ciò che memorizzi è l'hash della password e un salt (che puoi memorizzare accanto alla password con hash). Questa è la migliore pratica, quindi è quello che fai. Fatto.

Un'altra modifica: Doh! Il senno di poi è facile - potresti ancora verificare l'unicità perché (ovviamente) hai il sale ... sparami solo ora ... ovviamente non devi menzionare questo dettaglio al cliente.

FWIW, non è così stupido come pensi che sia - l'obiettivo è impedire a gruppi di utenti di concordare e condividere la stessa password, cosa che le persone faranno nella convinzione che renderà le loro vite più facili.

Se applicato con l'obbligo di cambiare regolarmente la password e un vincolo che impedisce alle persone di riutilizzare una password corrente o utilizzata in precedenza (affatto, mai) e requisiti di "forza" sensibili (o almeno un dizionario precaricato di "bloccato" "password) arriverai a un punto, abbastanza rapidamente, in cui le probabilità non sono comunque a favore dell'hacker.

Ok, la mia risposta inizialmente è iniziata con:

A livello teorico, c'è un po 'di sbagliato in questo dato un paio di clausole - la maggior parte delle quali sono che sono spessa ...

Apparentemente umorismo inappropriato - il punto era che se non hai il vincolo unico a livello globale stai creando diverse opportunità, forse meno pericolose - non lo so.

L'applicazione di password non ripetibili perde informazioni

Come? Perché ogni volta che un cracker tenta di creare un nuovo utente con una semplice password il tuo sistema risponde con "No, non può avere quella password", il cracker dice "Goody, quello è uno per la lista".

Perdere informazioni sulla tua sicurezza è generalmente una cosa negativa. OK, le terze parti che sanno che l'algoritmo va bene (ha bisogno di una revisione tra pari) ma che consente a un cracker dedicato di inferire le chiavi - male, davvero, davvero male.

Risorse che descrivono le politiche di gestione delle password buone e cattive

Leggi questo articolo dell'esperto di sicurezza Bruce Schneier per una discussione approfondita sulla sicurezza delle password.

Leggi questo PDF dei ricercatori sulla sicurezza Philip Inglesant e M. Angela Sasse per una discussione approfondita di "Il vero costo delle politiche password inutilizzabili". Per citare dalla conclusione:

Contro la visione del mondo secondo cui "se solo [gli utenti] comprendessero i pericoli, si comporterebbero diversamente" [12], sosteniamo che "se solo i responsabili della sicurezza comprendessero i costi effettivi per gli utenti e l'organizzazione, imposteranno le politiche in modo diverso".

Falso senso di sicurezza

Quindi il client convince con "Se nessuno ha la stessa password, allora se uno è incrinato, solo una persona è interessata". No. Tutti sono colpiti perché il cracker ha dimostrato che il tuo sistema di password è fondamentalmente difettoso: è vulnerabile all'attacco di un dizionario in un sistema online. In primo luogo, non avrebbe dovuto essere possibile per un cracker tentare più ipotesi su una password.

Per l'accesso online sono sufficienti 6 caratteri

Andando fuori tema, ma ho pensato che valesse la pena menzionarlo per i lettori interessati. In termini di sicurezza, un sistema online ha un processo di gestione della sicurezza attivo che monitora e controlla l'accesso ai dati. Un sistema off-line è uno che non lo fa (come avere dati crittografati su un disco rigido che è stato rubato).

Se disponi di un sistema di password online, non hai bisogno di password ad alta sicurezza. Le password devono essere sufficientemente complesse da impedire congetture entro 20 tentativi (quindi un semplice attacco "nome del coniuge / figlio / animale domestico" fallirà). Considera il seguente algoritmo:

1. Cracker indovina la password usando l'approccio "root plus suffix" per minimizzare le ipotesi
2. Credenziali rifiutate e ulteriori tentativi di accesso impediti per N * 10 secondi
3. Se N> 20 blocca l'account e informa l'amministratore
4. N = N +1
5. Informare l'utente che il prossimo accesso può avvenire al momento T (calcolato sopra)
6. Vai al passaggio 1

Per una semplice password di 6 caratteri l'algoritmo di cui sopra previene gli attacchi del dizionario, consentendo alla fine anche all'utente più inetto su una tastiera mobile. Nulla impedirà il cosiddetto "attacco del tubo di gomma" in cui si batte il titolare della password con un tubo di gomma fino a quando non te lo dicono.

Per un sistema off-line quando i dati crittografati sono in giro su un'unità flash e il cracker è libero di provare qualsiasi cosa contro di esso, beh, vuoi la chiave più resistente che puoi trovare. Ma quel problema è già risolto .

Se li avessi sconsigliati di questo corso d'azione e avessi fornito loro dei motivi, li prenderei in parola e implementerei il sistema come suggeriscono. Potrebbe non essere soddisfacente, ma hai fatto il tuo lavoro e stanno pagando il conto, quindi dovrebbero ottenere quello che vogliono.

C'è un'eccezione. Se le conseguenze negative di una violazione del sistema sarebbero gravi (ad es. Se un'informazione molto privata rischia di essere compromessa da una violazione della sicurezza), si potrebbe in effetti avere il dovere professionale di non implementare il sistema desiderato. Non aspettarti che ti renda popolare se rifiuti, ma non lasciare che sia la tua guida.

Voglio solo rafforzare la risposta di Murph. Sì, è un problema di sicurezza e ci sono vulnerabilità nella divulgazione di informazioni nell'implementazione. Ma dal punto di vista del cliente, non sembra essere troppo preoccupato per questo.

Quello che dovresti sottolineare è che è fisicamente impossibile implementare effettivamente un controllo "password unica". Se stai salando e hashing password e non le memorizzi come testo in chiaro, allora è O (n) (costoso) operazioni per eseguire effettivamente il controllo di unicità.

Riesci a immaginare se hai 10.000 utenti e ci vogliono 30 secondi per passare attraverso la password di ogni utente per verificare l'univocità ogni volta che qualcuno si iscrive o cambia la sua password?

Penso che questa sia la risposta che devi dare al tuo cliente.

Basti pensare in termini di spazio adeguato per porre la domanda, la sezione sulla sicurezza IT di Stack Exchange dovrebbe essere un punto utile per te. Prova /security/tagged/passwords - una serie di persone focalizzate sulla sicurezza IT dovrebbe essere in grado di fornire risposte specifiche.

Probabilmente vorrebbe la crittografia a due fattori RSA. Se si utilizza l'appartenenza ad Active Directory o ASP.NET, questo è un gioco da ragazzi.

Il token hardware o software genera una password univoca dipendente dal tempo seguita da un codice PIN. Questo insieme fornisce una password unica per ogni utente.