Citazioni per l'inavvisibilità della password unica globale

Ogni volta che un client tenta di creare una password già esistente, riceve un feedback che l'utente alcuni già usa quella password, di solito una violazione dell'accordo sulla privacy.

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

Dovrebbe esserci qualche pagina su internet da qualche parte che descrive la parte di violazione dell'accordo sulla privacy, a parte il fatto che è solo un buon senso: in pratica darebbero a qualcuno una chiave e un elenco di indirizzi di casa.

EDIT: non vicino all'autorizzazione, ma forse utile dopo aver spiegato loro cosa significa WTF: link

Le migliori pratiche ostacolano il rispetto dei requisiti:

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

Un'altra modifica: Doh! La vista posteriore è facile: puoi ancora controllare l'unicità perché (ovviamente) hai il sale ... semplicemente sparami ora ... ovviamente non devi menzionare questo dettaglio al cliente.

FWIW, non è così stupido come pensi che sia - l'obiettivo è di evitare che gruppi di utenti accettino e condividano la stessa password, che le persone faranno nella convinzione che farà il loro vive più facile.

Se applicato con l'obbligo di modificare regolarmente la password e un vincolo che impedisca alle persone di riutilizzare una o una password (in assoluto, mai utilizzata) e requisiti di "forza" ragionevole (o almeno un dizionario pre-caricato di password "bloccate", arriverete ad un punto, abbastanza rapidamente, in cui le probabilità non sono comunque a favore degli hacker.

Ok, inizialmente la mia risposta è iniziata con:

There's notionally very little wrong with this given a couple of provisos - most of which are that I'm being thick...

Sembra che l'umorismo sia inappropriato - il punto era che se non hai il vincolo unico globale stai creando opportunità diverse, forse meno pericolose - non lo so.

L'applicazione di password irripetibili perde informazioni

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

Generalmente le informazioni sulla sicurezza sono una cosa negativa. OK, le terze parti che sanno che l'algoritmo va bene (ha bisogno della revisione da parte dei colleghi), ma permette a un cracker dedicato di dedurre le chiavi - cattive, davvero, davvero cattive.

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

Leggi questo articolo dell'esperto di sicurezza Bruce Schneier per un approfondimento discussione sulla forza della password.

Leggi questo PDF dei ricercatori di sicurezza Philip Inglesant & M. Angela Sasse per una discussione approfondita su "The True Cost of Unusable Password Policies". Per citare dalla conclusione:

Against the world-view that “if only [users] understood the dangers, they would behave differently” [12], we argue that “if only security managers understood the true costs for users and the organisation, they would set policies differently”.

Falso senso di sicurezza

Quindi il client si confonde con, "Se nessuno ha la stessa password, se uno è decifrato allora solo una persona è interessata." No. Tutti sono interessati perché il cracker ha dimostrato che il tuo sistema di password è fondamentalmente imperfetto: è vulnerabile a un attacco di dizionario in un sistema online. In primo luogo, non sarebbe stato possibile per un cracker tentare tentativi multipli contro una password.

Per l'accesso online bastano 6 caratteri

Andando fuori tema, ma ho pensato che sarebbe degno di nota per i lettori interessati. In termini di sicurezza, un sistema on-line ha un processo attivo di gestione della sicurezza che monitora e controlla l'accesso ai dati. Un sistema off-line è uno che non lo fa (come avere dati crittografati su un hard disk che è stato rubato).

Se hai un sistema di password che è on-line allora non hai bisogno di password ad alta sicurezza. Le password devono essere sufficientemente complesse per evitare supposizioni entro 20 tentativi (quindi un semplice "nome del coniuge / figlio / animale domestico" fallirà). Considera il seguente algoritmo:

1. Cracker indovina la password usando l'approccio "root più suffisso" per minimizzare le ipotesi
2. Le credenziali sono state rifiutate e altri tentativi di accesso sono stati impediti per N * 10 secondi
3. Se N > 20 blocca account e informa l'amministratore
4. N = N +1
5. Informare l'utente che il prossimo accesso può avvenire al tempo T (calcolato sopra)
6. Vai al passaggio 1

Per una semplice password di 6 caratteri, l'algoritmo di cui sopra preverrà gli attacchi al dizionario, consentendo al tempo stesso di superare anche l'utente più inetto su una tastiera mobile. Nulla impedirà il cosiddetto "attacco del tubo di gomma" dove batterai il detentore della password con un tubo di gomma fino a quando non te lo diranno.

Per un sistema off-line quando i dati criptati sono in giro su una chiavetta USB e il cracker è libero di provare qualcosa contro di essa, beh, si desidera la chiave più resiliente che si possa trovare. Ma quel problema è già risolto .

Se li hai avvisati contro questa linea d'azione e li hai forniti con delle motivazioni, li prenderei in base alla loro parola e implementare semplicemente 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 esempio, se le informazioni molto private rischiano di essere compromesse da una violazione della sicurezza), in realtà potrebbe essere un dovere professionale non implementare il sistema che desiderano. Non aspettarti che ti renda famoso 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 nella sua implementazione. Ma dal punto di vista del cliente, non sembra essere troppo preoccupato per questo.

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

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

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

Pensando in termini di luogo appropriato per porre la domanda, la sezione di sicurezza informatica di Stack Exchange dovrebbe essere un punto utile per te. Prova link - una serie di persone focalizzate sulla sicurezza IT dovrebbe essere in grado di fornire risposte specifiche.

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

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