it-swarm-eu.dev

È pratica comune registrare le password rifiutate?

Mentre selezionare password uniche per ogni scopo è un'ottima idea, in pratica ciò accade raramente. Pertanto, molte password selezionate da un pool personale di password che sono facilmente ricordabili. Quando si esegue l'autenticazione in sistemi usati raramente, è molto probabile che vengano provate in sequenza un numero di password di tale pool. In alternativa, le password non riuscite sono molto simili alla password effettiva in caso di errore di battitura.

Dal momento che quasi nessuno descrive la politica delle password in vigore, incluso il modo in cui vengono gestite le password rifiutate, si dovrebbe iniziare a supporre che vengano raccolte in un database venduto al miglior offerente?

Esiste una guida all'implementazione? Cosa succede di solito con una password candidata quando questa viene rifiutata? Vengono registrati, immediatamente scartati o lasciati in giro fino alla raccolta dei rifiuti? Le procedure di gestione delle password non riuscite fanno parte dei controlli controllati? Sembra che ci siano molti requisiti di implementazione e raccomandazioni su come gestire le password valide, ma vaghe per quanto riguarda i valori delle password rifiutate.

[~ ~ #] modifica [~ ~ #]

Proverò a elencare qui le varie implementazioni che registrano le credenziali di sicurezza dell'accesso non riuscite per avere un'idea di quanto sia diffusa questa procedura:

Sistemi di gestione dei contenuti:

Joomla tramite Login Log non riuscito plugin

Questo plug-in di piccole dimensioni raccoglie registri su ogni tentativo di accesso non riuscito dell'amministratore del tuo sito Joomla e invia un'e-mail su ciascuno di questi al super amministratore del sito con nome utente, password, indirizzo IP ed errore.

KPlaylist v1.3 e v1.4 - un sistema gratuito PHP che rende il tuo raccolta di musica disponibile via Internet.

sta registrando i nomi utente e le password dei tentativi di accesso non riusciti nel registro errori di Apache

Drupal 5.x prima della versione 5.19 e Drupal 6.x prima della versione 6.1 .

Quando un utente anonimo non riesce ad accedere a causa di errori di digitazione del suo nome utente o password e la pagina in cui si trova contiene una tabella ordinabile, il nome utente e la password (errati) sono inclusi nei collegamenti sulla tabella. Se l'utente visita questi collegamenti, la password potrebbe essere trasferita a siti esterni tramite il referrer HTTP.

Software autonomo

Server di report incluso in Symantec Client Security 3.1 e SAV CE 10.1

La password dell'amministratore per Symantec Reporting Server potrebbe essere divulgata dopo un tentativo di accesso fallito.

Linux:

OpenSSH tramite modificato auth-passwd.c ; utilizzo di PAM tramite sovraccarico della funzione pam_sm_authenticate

EDIT # 2

Sembra che vi sia consenso e che la registrazione di password o PIN non riusciti sia considerata un rischio di sicurezza grave/grave, tuttavia, per quanto ne so, i seguenti standard non forniscono indicazioni, procedure controllate o controlli che affrontano specificamente questo rischio:

  • PCI-DSS : procedure password descritte in 8.4. e 8.5. (le password non riuscite sono protette solo durante la trasmissione; dopo la convalida non vengono considerate le password, pertanto non è necessario che siano protette)

  • FIPS140-2 : autenticazione indirizzata in 4.3 (ciclo di vita dei dati di autenticazione falliti indirizzati solo parzialmente)

61
Drew Lex

Registrare il valore di un tentativo di password fallita (testo in chiaro o altro) sembra un anti-schema di sicurezza. Non ho mai visto un'app Web che lo fa e non sono a conoscenza di servizi di sistema predefiniti come SSH che lo facciano. Come sottolineato da @tylerl di seguito, la maggior parte dei sistemi registra semplicemente meta-informazioni su un tentativo di accesso (ad esempio nome utente, ora, forse indirizzo IP, ecc.).

Perché questo dovrebbe essere un anti-pattern di sicurezza

Di persona, posso pensare a tre motivi per cui la registrazione del valore di un tentativo di password fallita è una cattiva idea:

1. Utente Typos

È estremamente comune per le persone digitare in modo errato una password di uno o due caratteri. Esaminare un file di registro di tentativi falliti renderebbe molti di questi facili da capire, specialmente se si potesse contrastare una sequenza di tentativi falliti con un'autorizzazione riuscita.

2. Indovina e controlla

Molte persone hanno due o tre password che attraversano per tutto. Di conseguenza, quando dimenticano la password che hanno usato su un determinato sito, passano in rassegna tutti loro fino a trovare una corrispondenza. Ciò renderebbe banale hackerare i propri account su altri siti.

. Log Bloat

La memorizzazione di password non riuscite non ha scopi utili per la stragrande maggioranza dei servizi di autenticazione attualmente in produzione. Mentre ci possono essere alcuni casi Edge, per la maggior parte delle persone, la memorizzazione di questi dati sta semplicemente gettando via lo spazio su disco.

Sulla legislazione/norme pertinenti

Non conosco alcuno standard (PCI, HIPAA, ecc.) Che affronti in modo specifico le procedure per la memorizzazione di tentativi di accesso falliti, ma ritengo che, dati i fatti di cui sopra, si possa formulare un valido argomento legale sul perché gli stessi standard che si applicano alla memorizzazione le password in generale dovrebbero applicarsi anche ai tentativi di password non riuscite. In altre parole, potresti argomentare legalmente che una password non riuscita è ancora categoricamente una password e come tale è soggetta agli stessi standard.

Anche se non sono certamente un avvocato, non vorrei che un giudice dovesse decidere se ero negligente o in violazione degli standard del settore perché le password non riuscite venivano archiviate in chiaro e i consumatori ne subivano le conseguenze. Non penso che finirebbe con una decisione favorevole.

Concordo con il PO che potrebbe essere utile per i vari organismi di normalizzazione affrontare specificamente questo problema (se in effetti non lo hanno già fatto). A tal fine, il mio suggerimento sarebbe quello di creare uno standard di conformità di non memorizzare affatto il valore dei tentativi falliti di password.

68
Mark

Non esiste uno scopo legittimo per registrare password in chiaro per qualsiasi applicazione; soprattutto per un accesso errato. Potrebbe essere registrato per caso: ho guardato casualmente auth.log per altri scopi e ho visto un utente digitare accidentalmente la propria password nel campo di accesso (e io registro i campi di accesso per vedere a quali account si sta tentando di accedere) - tuttavia l'ho notificato all'utente e hanno cambiato il loro parola d'ordine.

D'altra parte, come utente il presupposto prudente è quello di dire che ogni applicazione casuale che si utilizza registra ogni password di tentativi errati. Questo è il motivo per cui è una cattiva idea avere un piccolo (tre) di password casuali attraverso cui si scorre, rispetto a una password univoca per ogni sito gestito in un elenco di password crittografate (possibilmente utilizzando uno strumento come keepass).

In questa nota, Mark Zuckerberg (fondatore di Facebook) è stato accusato da businessinsider.com di utilizzare i registri delle combinazioni di login/password (anche da voci errate) da thefacebook.com (una versione precedente di Facebook) per hackerare gli account e-mail dei giornalisti di Harvard Crimson che lo stavano indagando. Dalla posta quotidiana: :

Tuttavia, dopo che sono emerse ulteriori affermazioni, Zuckerberg apparentemente è diventato ansioso che il giornale gli avrebbe raccontato una storia dopo tutto.

Business Insider ha affermato di aver poi detto a un amico come aveva violato i conti del personale di Crimson.

Presumibilmente ha detto all'amico che ha usato TheFacebook.com per cercare membri che dicevano di essere il personale Crimson.

Quindi, ha presumibilmente esaminato un rapporto di accessi non riusciti per vedere se qualcuno dei membri Crimson avesse mai inserito una password errata in TheFacebook.com.

Anche un po 'rilevante xkcd (immagina che anche gli account malvagi abbiano registrato password tentate per aumentare il loro tasso di successo).

17
dr jimbob

Ci sono alcune fantastiche risposte sopra, quindi questa è solo una prospettiva rapida e semplificata dalle politiche del governo degli Stati Uniti sulla gestione dei sistemi informatici che elaborano informazioni classificate.

(1) L'intero sistema informatico deve essere protetto secondo lo standard più elevato richiesto da qualsiasi dato su quella macchina. Ciò include i registri memorizzati all'interno o all'esterno della macchina.

Ad esempio, se intenzionalmente o accidentalmente si inseriscono dati "segreti" su un computer, OGNI parte di quel computer deve ora essere protetta come informazione "segreta". Questo è il caso anche se avevi un computer non classificato (come ad esempio a casa) che ha ricevuto un'email con informazioni classificate. L'intero computer e tutto ciò che contiene è ora classificato "segreto".

(2) I password a quella macchina sono anche classificati al massimo livello di protezione richiesto da qualsiasi dato su quella macchina.

Ad esempio, se si dispone di dati "segreti" su quella macchina, ovunque si memorizzi la password, richiede anche lo stesso livello di protezione.

Come applicato alla tua domanda, indipendentemente dallo standard che stai applicando, come PCI-DSS, NISPOM, ecc., Non puoi avere password in chiaro nei registri se il requisito è che devono essere protetti (come hash e salato) .

Quindi, in sintesi, se qualsiasi schema normativo viene applicato al tuo sistema informatico in questione, e tale regolamento dice che non puoi avere password di testo chiare, quindi non puoi avere password di testo chiare nei tuoi registri.

6
OnTheShelf

Non è raro registrare il fatto che un tentativo di autenticazione non è riuscito e per quale utente era. Ciò può rivelarsi molto utile nella risoluzione dei problemi forensi. È estremamente raro e irresponsabile dal punto di vista della sicurezza registrare la password che è stata rifiutata. Queste informazioni non servono a nessuno scopo utile e possono essere utilizzate contro di te.

[~ ~ #] modifica [~ ~ #]
Si spera si spera di essere in grado di aspettarsi che un'azienda rispettabile e ben organizzata non venda le informazioni sulla propria password, dal momento che male per loro se fosse scoperto. Ma nell'interesse della tua sicurezza, dovresti sempre essere pronto per le informazioni che fornisci per essere usate contro di te perché è sempre una possibilità. Questo vale il doppio per qualsiasi organizzazione la cui reputazione non è possibile stabilire in modo affidabile.

6
tylerl

No. È comune che gli utenti dispongano di un pool di password e di scorrere tra loro cercando di capire quale è in uso per un determinato sito. La registrazione significa solo che quando vieni compromesso, i loro supplenti vengono aggiunti al pool di cracker di chiunque ti colpisca.

2
John Haugeland