Devo forzare i miei utenti a cambiare le password each n giorni / settimane / mese?

La domanda dice tutto. Stiamo progettando un sistema in cui la sicurezza sia molto importnte. Una delle idee che qualcuno avesse dovuto costringere gli utenti a cambiare le password each 3 mesi. La mia presa su questo è che, mentre è più sicuro perché la password cambia spesso, inoltre obbliga i nostri utenti a ricordare password mai cambiate e rende più ansible che lo scrivano giù da qualche parte per aiutare a ricordare.

Nella stessa idea è veramente buono per costringere gli utenti a utilizzare una password molto difficile da indovinare. Forzarli ad usare% &% e maiuscole maiuscole. So che è proprio il problema di inventare una tale password e di ricordarla.

  • mysql error 2002 "non è ansible connettersi alla presa"
  • Quale demone FTP devo utilizzare se voglio utilizzare MySQL per l'authentication?
  • Il server MySQL non si avvia dopo lo spostamento di dir di dati
  • Memorizzare each database in una directory diversa
  • Opzioni per ridurre la dimensione di un database MySQL
  • Imansible installare MySQL
  • Poi di nuovo non vogliamo che chiunque utilizzi 12345.

    Così. C'è qualche documento su questo argomento? Buona pratica?

    Sto parlando di un sito web creato con PHP. MySQL in un ambiente lampada se questo cambia qualcosa.

  • Come posso impostare un server web fuori casa?
  • Quali sono le autorizzazioni unix perfette per le directory usuali del web project?
  • I vantaggi concreti di mantenere separate le applicazioni web e il server web?
  • Mitigare l'attacco "firesheep" allo strato di networking?
  • Perché i "bots di configuration degli hacker" ripetono più volte i moduli web?
  • Dove è la posizione migliore per un'applicazione eseguita in NodeJS su un server?
  • 14 Solutions collect form web for “Devo forzare i miei utenti a cambiare le password each n giorni / settimane / mese?”

    Penso che potrei essere nella minoranza in questo (sulla base della mia limitata esperienza in materia di reparti IT a scuola e lavoro), ma credo che le politiche di cambiamento delle password obbligatorie e basate sul tempo siano inutile al meglio e dannose nel peggiore dei casi. Le persone tendono ad essere molto cattive nella scelta delle buone password e nel mantenerle segnetworking. Le politiche di scadenza della password sono state progettate per attenuare ciò limitando la quantità di tempo in cui una password può essere fatta crollare / socializzate / rubate; tuttavia, essi non riescono a raggiungere questo objective nella pratica, soprattutto perché costringono gli utenti a continuare a apprendere la propria password continuamente. Rendendo più difficile per l'utente di impegnare le proprie password in memory, si finisce per causare molte di loro a scegliere password più deboli e / o scrivere le loro password in un luogo where gli occhi indiscreti possono trovarli.

    Inoltre, quando è costretto a cambiare la propria password regolarmente, molti utenti scelgono le password che seguono un model molto riconoscibile, ad esempio [base string][digit] . Diciamo che un utente vuole usare il nome del loro gatto Fluffy come loro password. Potrebbero iniziare con una password di fluffy , poi cambiarla a fluffy1 , fluffy2 , fluffy3 e così via. In questo caso, la politica non aiuta veramente la sicurezza; anche se l'utente sceglie una string di base più sicura di quella fluffy , e anche se mantengono la propria password memorizzata in modo sicuro, il carattere suffisso singolo che cambia each pochi mesi non è molto sufficiente per mitigare gli attacchi di cracking o di ingegneria sociale.

    Vedere anche: Scadenza password considerata Nociva , un breve articolo (non scritto da me) che credo dà una buona introduzione a questi problemi.

    La mia big organizzazione (15.000 utenti +) ha implementato "cambiamenti di password" each 120 giorni nella caduta del 2009. È una grande mal di testa IT e spreco di risorse di supporto. Ogni volta che la window di 120 giorni si rotola intorno a noi abbiamo migliaia di utenti costretti a cambiare la loro password …. che molti di loro fanno in modo errato e bloccano il loro account …. o dimenticare il giorno successivo. Il nostro helpdesk è sconvolto con le chiamate di password anche se abbiamo cercato di rendere il più ansible il self-service ansible.

    Se vuoi che i tuoi utenti / clienti ti odiano …. e il tuo personale IT di prima linea per bruciare voi in effigie each possibilità che ottengono … implementare le modifiche alle password.

    Le politiche di cambio di password sono una casella di controllo in qualche gestore di IT come prenotare da qualche parte … ed è stato scritto 15 anni fa. Nessuno nelle trincee che realmente implementa o support la politica dirà mai che è una buona idea.

    Ho sostenuto qui per "frasi di passaggio" invece di password … grasso molto di buono che … quella luce alla fine del tunnel era un treno in arrivo. 🙂

    Una frase di passaggio è una string lunga quasi impensabile che è molto facile da ricordare come "MyCatIsFromSpainAndICallHimElGato". O forse una linea da una poesia o una canzone.

    Se vuoi rendere veramente difficile da rompere … scompigliare con il caso, aggiungere qualche punteggiatura, cambiare alcuni di essi, ohs a zeri, a @, ecc … Ma tenga la memory … che è la chiave. Ci sono anche modi per prenderli in modo che possano scorrere facilmente dalle dita alla tastiera … quindi non stai rimbalzando da tutte le mani o con gli SHIFT e le strane punteggiature.

    Così…

    • Utilizzare lunghe "frasi di passaggio".
    • Prova internamente per forza.
    • Implementare "single sign-on" in tutta l'intera infrastruttura in modo che i clienti devono utilizzare solo una o due volte al giorno.
    • Non forzarle mai a cambiarla.
    • E educare, educare, educare sul loro uso corretto.

    opaco

    EDIT: 8/24/2011 XKCD è d' accordo e ha detto che è meglio di me.

    No. La mia opinione personale è che è inutile e anche controproducente . Ho risposto sul mio blog, ma tu puoi cacciare questo se sei interessato.

    In breve, si scende a due ragioni:

    1. Forzare un utente a cambiare costantemente la propria password port a cattive password.

    Non ci sarà carenza di prove aneddotiche su questo, ma ha senso che se sono obbligato a ricordare una nuova cosa each x giorni, farò queste cose facilmente memorizzabili e probabilmente collegate tra di loro.

    Gli utenti sono molto più propensi a scegliere le password "guessable" come "Jan2010" o "Password05" se sanno che dovrà cambiare presto. L'attuazione di una politica rigorosa sui caratteri rischia di produrre un segno di esclamazione aggiunto o un nome pienamente scritto piuttosto che un'abbreviazione. C'è una grande differenza tra una password tecnicamente complessa e quella che non verrà indovinata.

    2. Fornire modifiche regolari delle password non impedisce gli attacchi, riduce solo il rischio (e non molto)

    Pensateci: se la tua password viene indovolta o scoperta in qualche modo, quanto tempo ci vorrebbe un utente malintenzionato ad utilizzare queste informazioni? Mettiti nelle scarpe dell'attaccante. Hai appena scoperto una password. Non entrare in contatto e estrarre each informazione che potresti fare subito se qualcuno scoprirà? In 30 giorni, hai già tutto quello che vuoi.

    La mia raccomandazione:

    • Fornire una politica di password estremamente rigorosa (come 15 caratteri con caratteri superiori, inferiori, numbers e caratteri speciali, senza parole inglesi> 3 caratteri)
    • Non fare mai l'utente cambiare la propria password. Se wheressero scrivere la password su un pezzo di carta e tenerlo nel portfoglio, questo è veramente bene. La gente è brava a fissare pezzi di carta, ma non è così bello ricordare stringhe casuali di personaggi.

    Dal punto di vista dell'utente, wherer cambiare la mia password è incredibilmente scomodo. Assolutamente odio di whererlo fare e userò solo siti che devo assolutamente bisogno se mi chiedono di cambiare la mia password.

    C'è stata anche una discussione sul fatto che questa sia davvero una buona pratica, poiché alcune persone finiscono per wherer scrivere le loro password per ricordarle.

    Potresti implementare uno di quei widget che mostrano a chi è forte (o debole) la password mentre lo stanno riempendo. Trovo che siano utili (sorta) utili, anche se non so se risultano in realtà più forti Le password.

    Come utente di un ambiente di policy di password molto rigoroso ("super difficile da indovinare le password" e la password cambiare allo stesso modo) il mio parere è che solo la password è necessaria. Anche se ci vuole un po 'per i tuoi utenti per abituarlo (specialmente se sono gli utenti di 12345) dovrebbero essere in grado di ricall e digitarlo facilmente entro una settimana.

    Tuttavia, posso prevedere utenti finali scomodi se si hanno tali password forti e che costringe loro di cambiare.

    Dal punto di vista dell'amministrazione IT, l'opzione migliore è studiare la possibilità di consentire all'applicazione di utilizzare le funzionalità di firma singola degli schemi di authentication esistenti che i clienti utilizzano. Ovviamente Active Directory è un grande giocatore, ma se la tua applicazione funziona con la politica che l'IT in loco ha già configurato, non devi preoccuparti di reinventare la ruota.

    Dal momento che tanti dibattiti si sono ripresi su se le modifiche di password forzata siano una buona idea (anche se penso che fosse secondario alla tua domanda principale), ho pensato che potresti godere di alcune idee e collegamenti qui . Per la maggior parte delle situazioni, se non intendi applicare una complessità di password e cambia pianificazione, puoi anche non avere tutte le password, ma il modo in cui viene implementato (formazione, supporto alla gestione ecc.) È più importnte di quanto posso sottolineare.

    Le modifiche delle password spesso possono portre all'utente che le scrive. Che non è una ctriggers idea secondo Bruce Schneier ( http://www.schneier.com/blog/archives/2005/06/write_down_your.html ).

    Vorrei addirittura sostenere che avere una sicurezza in grado di utilizzare l'usabilità può essere una cosa buona, solo perché ricorda all'utente di agire in modo sicuro. Ad esempio, nella banca where lavoro, molte delle misure di sicurezza esistenti sono il teatro di sicurezza (ad esempio il riconoscimento di faccia alla port, ma il ragazzo di sicurezza apre la port per se il riconoscimento non riesce). Mentre queste misure non migliorano la sicurezza da soli, essi sono sempre lì per ricordarci che la sicurezza è un'importnte concerne sul lavoro, che c'è una certa quantità di logging e di controllo in corso e che se si arriva a fare qualcosa di "non sicuro" saranno in difficoltà.

    Naturalmente, questo vale per la sicurezza per i dipendenti di una banca, potrebbe non essere applicabile agli utenti del tuo sito web …

    Dovresti obbligare gli utenti a cambiare each n giorni se la vostra politica di sicurezza lo richiede. Lavoro per un'agenzia statale, e questo è un obbligo proveniente dall'ufficio del revisore dello Stato. Non posso fare niente, quindi devo forzare cambiamenti.

    Se non sei vincolato dalla normativa per forzare le modifiche alle password, non forzarle. Assicurarsi che le password che si ottengono soddisfino determinati requisiti minimi di complessità. La lunghezza complessiva dei tridimensionali per la maggior parte dei sisthemes di password, in modo che uno standard variabile è il caso migliore a mio parere. Ad esempio:

    • Nessuna password deve essere inferiore a 10 caratteri.
    • Le password tra 10 e 25 caratteri richiedono alless 3 caratteri.
    • Le password tra 25 e 40 caratteri richiedono alless 2 caratteri.
    • Le password più lunghe di 40 caratteri possono utilizzare un singolo set di caratteri.

    I sisthemes di complessità incorporati per oggetti come Active Directory non supportno questo tipo di sistema a livello. Se crei un proprio ambiente di modifica della password puoi fare cose come questa. Poiché each utilizzo del tasto di spostamento aumenta la probabilità di un evento di grasso-barretta, le password lunghe con set di caratteri multipli sono molto più probabili a causare events di login non riusciti, soprattutto durante le fasi di apprendimento. Se hai un sistema di block dell'account, questo può essere un grosso problema. Per la persona che usa la terza row della loro poesia preferita (63 caratteri!) Come la loro frase di passaggio, non wherer h @ x0r rende l'ingresso veloce ed efficiente.

    Se la tecnologia o l'ambiente di rischio cambiano in modo significativo e le password non sono così complesse come dovrebbero essere, mettere in un modo per scadere le password per un periodo di tempo. La gente sussulterà sulla necessità, soprattutto se non hai mai fatto un cambiamento prima, ma ti aiuterà a mantenere la tua posizione di sicurezza.

    Difficile da indovinare le password sono una buona cosa. L'esecuzione di livelli di complessità che comportno che gli utenti dimenticano le loro parole d'accesso o che devono scomparire è una cosa negativa, perché each sicurezza acquisita dalla complessità è completamente persa nel process. In un mondo ideale (che purtroppo non è where viviamo) dovrebbe esistere un equilibrio tra la complessità e l'usabilità. Naturalmente persone diverse vedranno quel punto di equilibrio in luoghi diversi.

    La logica che cambia regolarmente le password in X giorni è un po 'perduta su di me. Il motivo per cui solitamente sento per questo è quello di limitare l'utilità di una password rubata, alla quale rispondo che qualsiasi danno reale sarà quasi certamente fatto entro le prime ore comunque. ad esempio Fred "si mette a conoscenza" della password di Mary. A less che non accada quasi nello stesso momento in cui Mary cambia quella password, quale differenza lo fa se cambia domani o il prossimo mese? È veramente probabile che Fred attenda un'altra settimana o due prima di utilizzare la password (supponendo che fosse l'intento tutto il tempo)?

    Ovviamente cambiando le password se c'è qualche ragione o sospetto che potrebbe essere necessario è un'altra cosa.

    Se l'applicazione necessita di un elevato livello di sicurezza, hai pensato di utilizzare qualcosa come i token SecurID? Ciò significa che l'utente riceve una nuova password each 60 secondi; non wherete preoccuparvi di loro usando la scrittura delle password. Tuttavia, questi costano denaro. Quanto è sicura la soluzione?

    Penso che le informazioni agli utenti siano importnti. Spiega loro come creare una password e quanto sia importnte non utilizzare la stessa password due volte. Un modo semplice per creare una password è prendere una frase e prendere la prima lettera in each parola e aggiungere alcuni numbers.

    Ex. Mi piace regolare il mondo = Iltrw99

    Non forzarli a cambiare la password li confonderà solo.

    Sebbene non sia d'accordo con la modifica delle password each tre mesi, questo è un requisito se la tua azienda è quotata al pubblico e fa parte dell'essere SOX conforms. Nota laterale: Sarbanes-Oxley succhia.

    Qualcosa che non ho visto accennato è l'accesso esterno alle risorse.

    Mi sento d'accordo che se scegli una politica di password sensibile, a less che qualcuno non lo scrivi, nessuno è in grado di indovinare quella password.

    Tuttavia diciamo che è ansible accedere a un sito web fuori sede, ora potenzialmente gli utenti che scrivono le loro credenziali su "qualsiasi vecchio PC" e IMO che aumenta il rischio per i dati aziendali rappresentati da spyware / malware / trojan e così via che possono sniff / rubare quelle password .

    Se le persone scrivono semplici password, cosa ti fa pensare che non scrivere una passphrase enorme o una password super complicata. Queste modifiche incrementali delle password comportno una spazzatura di ID utente che non è più in uso automaticamente e consente a un singolo utente di avere alcuna responsabilità in tutto questo. Le persone saranno persone, cercando la strada facile per realizzare qualcosa; le password ripetute e le password modificate in modo incrementale possono essere rilevate e negate. I requisiti di complessità possono essere comunicati, le modifiche obbligatorie della password possono anche aprire gli occhi degli utenti non IT alla loro responsabilità in tutto questo. La maggior parte degli utenti che si lamentano della modifica della password sono i pigri che pnetworkingndono di cambiare la propria password come la chirurgia del cuore aperto. Smettere di sbattere, essere responsabile e smettere di cercare di trovare una via facile o cercare un nuovo lavoro con requisiti "limpidi" …

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.