Chi è responsabile della forza delle password dell'utente?

Non puoi rispondere a questa domanda senza rispondere alla seguente domanda

If a user's password is compromised, does that only put that user/that user's data at risk, or does it also put other users at risk?

Se il sistema non compartimenta account, allora un utente non può mantenere i suoi dati al sicuro scegliendo appropriati credenziali, quindi gli amministratori devono essere responsabili, in parte, della sicurezza generale della comunità.

Se il sistema esegue la compartimentalizzazione degli account, un utente può danneggiarsi scegliendo le credenziali deboli, quindi è possibile che sia opportuno trasferire la responsabilità all'utente.

Ad esempio, le caselle di posta elettronica sono ben divise in compartimenti stagni; compromettere un account non compromette molto gli altri. Alcuni account potrebbero essere impostati per non essere considerati spam da altri account, ma ci sono molti altri modi per impersonare mittenti di e-mail in modo che la possibilità di inviare e-mail come utente non sia spesso un'enorme escalation di autorità. Un amministratore può rinunciare alla responsabilità per la sicurezza della password senza compromettere la sicurezza del sistema.

Ma i file system e gli archivi di codice sorgente non sono ben divisi in compartimenti stagni. Compromettere un account la cui cartella ~/bin è su PATH s di altri utenti, o che ha accesso di commit a un repository di codice sorgente vitale può portare alla compromissione di molti altri account e sistemi tramite trojans . In questo caso, la compromissione di un account aumenta l'autorità a livello di sistema; gli amministratori non possono rinunciare alla responsabilità per la sicurezza delle password perché non possono rinunciare alla responsabilità per la salute del sistema.

Se sei uno sviluppatore, non dovresti essere uno dei requisiti di impostazione - questo dovrebbe essere impostato nella politica dall'organizzazione che stai sviluppando, tuttavia se sei consapevole della sicurezza dovresti essere in grado di discutere quello che pensi una linea di base minima dovrebbe essere. In effetti, potresti essere in grado di utilizzare la sicurezza della tua applicazione come un ulteriore punto di vendita rispetto alla concorrenza nell'attuale contesto di paura di essere violati.

Ma non dovrebbe assolutamente essere la tua responsabilità - la politica organizzativa dovrebbe definire i requisiti della password secondo la loro propensione al rischio, e gli individui possono sempre usare una password più strong del minimo richiesto.

Se desideri password complesse per proteggere il tuo server / servizio, è una tua "colpa" se le tue politiche sono troppo indulgenti. Ciò presuppone che il tuo server / servizio sia minacciato da una singola compromissione dell'utente finale, il che non è sempre il caso.

Nella misura in cui gli utenti desiderano che il proprio account sia protetto, è il loro "difetto" se non scelgono una password sufficientemente solida, indipendentemente dalle politiche in atto.

Se un numero sufficiente di account viene compromesso, il "difetto" viene determinato da chi fa ruotare la propria vista sul supporto più rapidamente e in modo più efficace.

È davvero un'area in cui puoi condurre un cavallo all'acqua, ma non puoi farli bere. I criteri di password draconiani di solito causano problemi di sicurezza in altre direzioni, come la scrittura di password in basso o il ricorso a sequenze non alfa ipotetiche come le date di nascita. Le politiche sulle password mancanti portano a problemi di link più deboli, poiché qualcuno sceglierà sempre "segreto" come password data la scelta.

"colpa" è un concetto abbastanza nebuloso qui. Potresti chiedere informazioni sulla responsabilità legale, che è più solida. Credo che ci sia stato un caso o due che coinvolgono password bancarie che sono state compromesse e che la banca è stata accusata di non aver richiesto una protezione sufficiente, ma non ricordo i risultati.

In realtà, c'è un affascinante esempio che ho visto la scorsa settimana. Un'associazione senza scopo di lucro ha perso $ 70.000 quando qualcuno ha ottenuto le password per il proprio sistema bancario e le ha sfruttate.

“We had declined some of the security measures offered to us, [but if] we had those in place this wouldn’t have happened to us,” French said. “We thought that would be administratively burdensome, and I was more worried about internal stuff, not somebody hacking into our systems.”

e poi

MECA has since added more security features to its online banking account, and access to that account is only possible through a locked-down, dedicated computer.

“All of this is a day late and a dollar short, I guess,” French said. “Why isn’t someone out shouting on the rooftops about this fraud? People need to understand how exposed they are.”

Questo illustra l'atteggiamento delle persone verso la sicurezza delle password proprio lì. "Abbiamo rifiutato di rafforzare la nostra sicurezza ... perché qualcuno non ci ha detto di rafforzare la nostra sicurezza?!?" Quanto sono lontani dal citare in giudizio la propria banca per non richiedere una maggiore sicurezza?

Mi sembra che ci siano due problemi separati che devono essere trattati nella domanda.

Utenti che scelgono password deboli.

La responsabilità di questo pezzo può essere concepibilmente divisa in tre modi:

1. Gli uffici di gestione e sicurezza IT all'interno dell'organizzazione devono definire politiche appropriate per rafforzare, aggiornare e riutilizzare la password.
2. Gli sviluppatori devono implementare correttamente le restrizioni tecniche che applicano queste politiche.
3. Gli utenti devono seguire lo spirito di queste politiche, non solo la "lettera della legge", al fine di creare password "forti".

Alla fine, la responsabilità per la "forza" della password dipende assolutamente all'utente. (Anche se la legge può giudicare in modo diverso - non sono un avvocato, quindi non posso parlare per questo.) Tuttavia, sarebbe irresponsabile da parte nostra (sicurezza informatica, gestione, sviluppatori, ecc.) non stabilisce e impone criteri di password appropriati e istruisce gli utenti sulla necessità e sulla corretta implementazione di queste politiche.

Comprensione del database delle password.

Per rispondere completamente alla domanda:

"If a user who has a very simple one word password has his account hacked in a dictionary attack is it his fault or is it our fault that we allowed for such a simple password?"

Dobbiamo anche chiarire in che modo l'attacco con il dizionario è diventato possibile in primo luogo. Cioè, chi era responsabile della protezione del database delle password? Questo rientra in due gruppi e, se i media sono una buona misura, probabilmente riflette chi ha più probabilità di essere biasimato almeno pubblicamente, se non legalmente, per gli account oggetto di dirottamento.

1. Gli uffici di gestione e sicurezza IT all'interno dell'organizzazione devono definire politiche appropriate per quanto riguarda la manutenzione e la sicurezza dei server dell'organizzazione.
2. Gli sviluppatori devono implementare correttamente queste politiche sia nell'applicazione tecnica che nella pratica generale.

Se il database delle password è esposto a un utente malintenzionato, le password possono essere violate indipendentemente dalla forza . È solo questione di quanto tempo e potenza computazionale l'attaccante è disposto a dedicare al compito. È interamente la responsabilità dell'organizzazione (IT Security, Management e Developers) di eseguire la due diligence e dare il massimo per impedirlo.

Se sei uno sviluppatore web, lavorando da solo creando un sito, decidi quanto sarà noioso quando qualcuno ha il suo account compromesso e accusa il tuo sito come non sicuro.

Se lavori in un'azienda, a meno che tu non sia nel grande comitato che decide in merito alla sicurezza, non dovresti preoccuparti.

Se sei responsabile (anche solo parzialmente) della sicurezza, devi discutere che gli utenti sono gli unici responsabili delle loro password, allo stesso modo in cui gli utenti sono responsabili di non perdere i loro portafogli, o di non fare un esterno con la loro banca numeri di conto e password dei pin. Ma ... incolperanno il tuo sito se il loro account è usato, e penseranno solo alla sicurezza della password che è la tua responsabilità. La fuga di Gawker è stata un ottimo esempio di come le persone scarsamente scelgono la propria password.

L'idea migliore che ho letto finora, in una domanda diversa, era questa: (nota che non mi sembra che nessun sito lo stia usando):

• inserisci un misuratore di forza password nella password. Invece di usare la notazione "debole - medio - buono", rendi più livelli, come la misura 1-10

• indica (e implementa) una politica che l'utente dovrà cambiare la password ogni x giorni con quel punto di forza. Se è molto basso, indica che può rimanere più tempo con la password se ha rafforzato un po 'di più.

• se sceglie ancora una password di bassa qualità, fagli fare clic su qualsiasi controllo "Accetto".

Lo sviluppatore perché se è colpa tua o no ti biasimerà quando il suo account verrà compromesso.

Chi è responsabile è chi avrà la colpa. È una decisione politica, quindi può essere "chiunque". Tuttavia, possono accadere decisioni sbagliate. Ecco alcuni spunti di riflessione:

• Gli sviluppatori stessi non devono essere responsabili delle decisioni di progettazione, perché ciò significherebbe che loro fanno decisioni di progettazione (nel qual caso sono designer , una diversa lavoro che possono o meno svolgere in parallelo), o, peggio, che vengono incolpati per gli errori degli altri (non è il modo migliore per tenere i tuoi sviluppatori in giro ...).

• Non è possibile misurare la forza di una password. La forza della password è una caratteristica del processo di generazione della password , non della password stessa. In una piccola misura, potresti dedurre alcuni dati su quel processo osservando molte password scelte da un determinato utente, ma questo non è pratico. I "misuratori di password" non danno risultati molto utili; per esempio. questo sito valuterà "BillClinton1992" a "100%", il punteggio più alto possibile ... Poiché i controlli di sicurezza delle password non possono essere automatizzati in modo affidabile, non ha senso rendere i progettisti di software responsabili della forza della password.

• Ciò di cui i progettisti di applicazioni possono essere resi responsabili è quello che possono fare, cioè offrire modi per implementare le norme sulla password . Non dovrebbero editare le politiche stesse (questo è il lavoro di un architetto della sicurezza) ma possono implementare (o meglio, hanno gli sviluppatori implementare) alcuni strumenti come i vincoli di lunghezza della password o i generatori di password.

• Incolpare gli utenti è inutile. Per una corretta protezione della password, gli utenti devono essere arruolati; non andrai da nessuna parte senza la loro collaborazione. Ma gli utenti non sono solo utenti, sono anche esseri umani; in quanto tali, a loro non piace affatto essere padroneggiati, e tendono a reagire negativamente ai vincoli. Se si tenta di applicare "regole rigorose per le password" con uno strumento, inventano in modo creativo i modi per far fronte a queste regole, con il minimo sforzo da parte loro, e non necessariamente per il meglio quando si tratta di sicurezza. Ad esempio, aggiungeranno sistematicamente "1A". alla loro password (che altrimenti è una parola comune minuscola) in modo che superino i test di "bisogno di cifre, bisogno di simboli, lettere maiuscole"). Oppure scriveranno le password, il che non è male quando lo fanno su una carta che tengono nel loro portafoglio, ma piuttosto orribile quando la carta è una nota adesiva nascosta sotto la tastiera.

Una buona politica consiste nell'imporre la generazione di password tramite uno strumento informatico. I computer sono bravi a caso (a patto che usino /dev/urandom , ovviamente). Lo strumento incarna il processo di generazione della password, in modo da poter sapere "quanto sono forti" tali password. Dal momento che agli utenti non piace lo sforzo di ricordare le password, informale che a loro è permesso di annotare la password su pezzi di carta (ad esempio biglietti da visita), a condizione che li tengano in un luogo sicuro. In questo modo, gli utenti non sono responsabili della password forza , ma sono responsabili del mantenimento della sicurezza fisica del loro portafoglio. E, cosa più importante, fai sapere che gli utenti che hanno perso la password non saranno biasimati perché l'unica cosa che è peggio di una password rubata è una password rubata non dichiarata .

Anche se preferisci la soluzione più tradizionale di lasciare che gli utenti scelgano le loro password, dovresti comunque offrire un generatore di password e promuoverne l'uso.

Per aiutare gli utenti a ricordare le password, chiedi loro di digitare la password ogni giorno. Non troppo spesso: a nessuno piace digitare una password di 15 lettere ogni dieci minuti. Ma se inseriscono la password ogni mattina, la ricorderanno e questo lo rende più semplice per far rispettare le password generate automaticamente. Per favore, oh per favore, fai non rendere obbligatorie le normali modifiche della password. Questo ha solo vantaggi di sicurezza molto minori, ma irrita anche gli utenti e promuove comportamenti anti-sicurezza (ad esempio la condivisione delle password, che gli utenti tendono a fare come protezione contro la perdita di password attraverso l'oblio).

Ho intenzione di affermare che gli sviluppatori di software sono non liberi di responsabilità su questo conteggio.

Se sei lo sviluppatore, sembra giusto affermare che è almeno tua responsabilità fornire un solido meccanismo per applicare la politica scelta dal cliente?

Quale dovrebbe essere la politica predefinita per i clienti non esperti? In altre parole, per la maggior parte dei tuoi clienti?

Sicuramente il valore predefinito non dovrebbe essere quello di lasciare un sistema aperto fuori dalla scatola.

I ancora vediamo casi in una storia piuttosto recente (come in oggi) di, ad esempio, fornitori di server di database che impostano l'utente amministratore di sistema su "dba" e la password su "sql" (chiedo chi ?).

"Un grosso problema, tocca al cliente cambiarlo" dici?

Il problema è che avere quel tipo di livello di sicurezza predefinito risibile porta direttamente ad almeno un prodotto di spedizione di ISV che non solo non modifica le credenziali predefinite, ma si basa sulle credenziali predefinite deboli e ben note e, per finire, pubblica la dipendenza dalla documentazione ufficiale sul supporto del prodotto in inchiostro indelebile in bianco e nero.

Potrei facilmente nominare più prodotti, ma non lo farò. Fidati di me, è vero. Un tempo era vero per SQL Server con il suo account utente "sa" integrato nel corso della giornata, ma Microsoft ha subito il buco nell'installazione patch per un po 'di tempo. Ma è ancora vero altrove.

Sono perfettamente a conoscenza dei sistemi in esecuzione in aziende di vasta e ampia oggi oggi , contenenti ciò che è in ogni caso dati molto sensibili, con front end dell'applicazione che implementano i controlli di accesso in-app fornendo < strong> illusione di una certa sicurezza, ma che sono di fatto completamente aperti per un accesso amministrativo completo a qualsiasi utente vagamente esperto con una copia di Excel e accesso al manuale di installazione del software, o qualsiasi indizio sul database di back-end e una propensione all'esperimento.