VP dell'IT afferma di aver diseredato il 100% dei PW di tutti i 16k impiegati. Ci sta mentendo?

Ci sono alcune possibilità qui, alcune delle quali sono già state chiamate. Ognuno di questi renderebbe abbastanza banale il fatto che il tuo VP (IT) abbia "decrittografato tutte le password degli utenti" indipendentemente dalla definizione che sta utilizzando per "decrittografato".

1. Le password in questione sono, infatti, archiviate con crittografia reversibile.
   • Il tuo VP potrebbe riferirsi a password per un'applicazione Web interna, in cui hanno scelto di utilizzare la crittografia anziché l'hashing.
   • Il tuo VP potrebbe in realtà riferirsi alle password di Windows e il criterio di gruppo della tua azienda consente l'archiviazione con crittografia reversibile.
2. Le password a cui si riferisce il VP vengono memorizzate utilizzando algoritmi di hashing deboli e / o vengono sottoposte a hash senza sale per utente.
   • L'hash LM è un esempio di un algoritmo debole, comune alle implementazioni di Windows ottimizzate per la compatibilità con le versioni precedenti.
   • Il mancato utilizzo di un sal per utente rende dizionario & il rainbow table attacca molto più facilmente.
3. Le password a cui si riferisce il tuo VP potrebbero essere effettivamente archiviate in testo semplice, e sta solo dicendo che sono state "decodificate" per nascondere il fatto che non sono mai state crittografate / hash in primo luogo.
4. I dipendenti della tua azienda in realtà fanno utilizzano tutte le molto password deboli.
   • Indipendentemente da quanto sia casuale la tua password, 8 caratteri non sono stati considerati "forti" per un bel po 'di tempo.

Considero l'articolo 4 in tale elenco piuttosto improbabile, quindi a meno che nessuno degli altri tre sia vero, è possibile che il tuo VP stia esagerando un po '. Tuttavia, a meno che tu non abbia l'orecchio di qualcuno a livello C della tua azienda, dubito che ci sia molto che puoi fare per cambiare qualsiasi cosa eccetto la forza effettiva della tua password. A tal fine:

• Alcuni dicono "12 è il nuovo 8". Dico andare per 15. Questo non solo renderà la password naturalmente più strong, ma impedirà anche a Windows di memorizzarla nel debole formato LM dell'hash. L'hash LM può gestire solo password lunghe fino a 14 caratteri. Windows può generare un messaggio di avviso quando si cambia la password con una lunghezza di 15 caratteri o più, ma questo può (nella maggior parte dei casi) essere ignorato in modo sicuro.
• Non utilizzare la stessa password su più applicazioni. Per lo meno, ti suggerisco di mantenere la tua password di lavoro diversa dalle password utilizzate per gli account personali. Idealmente, nessuna delle due applicazioni dovrebbe utilizzare la stessa password.
• Mantieni il resto delle cose buone che stai facendo. Generare casualmente le tue password da un set di caratteri ASCII completo è grandioso. Assicurati che il prodotto finale includa tutti e quattro i tipi di caratteri e non parole reali.

L'unico modo realistico in cui il 100% delle password si incrina è se stai memorizzando gli hash LM su Windows. Gli hash LM si dividono in 2 blocchi di sette personaggi che rendono praticabili attacchi brute force / rainbow table (sono anche insensibili alle maiuscole e alle minuscole). Le tabelle arcobaleno esistono per questo ed è facilmente fattibile.

Oltre a questo, chiunque abbia 10+ password di caratteri che non sono in un dizionario (o che si possano trovare modificando le parole del dizionario) non si incrinano su nessun sistema ragionevole, anche con algoritmi deboli (es. md5) e senza sale . Le tabelle arcobaleno AFAIK non sono pratici sulle password lunghe (per riferimento tabelle arcobaleno gratuite hanno un pacchetto da 2.8 TB di hash MD5 che supera le nove password dei caratteri (non set completo di caratteri).

Un punto che vorrei fare è che se fossi il vicepresidente dell'IT mi concentrerei a sbarazzarmi degli hash LM piuttosto che dire alle persone delle buone pratiche per le password proprio perché era in grado di recuperare il 100% di password:)

"Decrittografato" non è il termine giusto. Cioè, le password potrebbero essere crittografate invece di essere sottoposte a hash, ma la decifrazione sarebbe semplice da parte di chiunque conosca la chiave di crittografia (che è anche la chiave di decodifica); non avrebbe senso applicare strumenti di cracking come John the Ripper .

Pertanto, il VP sta usando una terminologia approssimativa. È quindi plausibile che possa aver usato anche sintassi e grammatica approssimative. Molto probabilmente, hanno presentato le password 10k + agli strumenti di cracking, e hanno rotto alcuni di loro (una proporzione abbastanza grande da richiedere un intervento VP, ma non tutti). Il suo uso di "tutti" è solo, diciamo, entusiasmo eccessivamente enfatico.

Ora sono pronto a credere che potrebbe rompere metà delle password. È stato documentato che il worm Morris , nel 1988, poteva rompere circa il 10% delle password esistenti con un dizionario di meno di mille parole ...

Decrittografato non è la parola giusta, ma probabilmente stava andando per la leggibilità piuttosto che per la precisione tecnica. Sono anche d'accordo che probabilmente non ha ricevuto tutti di loro, ma piuttosto una porzione alta.

Ora la tua password ha un problema: 8 caratteri non sono molto lunghi se la tua azienda usa un hash veloce come MD5 o LM. Un cracker decente basato su GPU può raggiungere circa 50M MD5 hash / sec. Se si assumono 100 caratteri stampabili su una tastiera QWERTY, questo è uno spazio chiave di 10.000.000.000.000.000 per una password di otto caratteri, che è un tempo di cracking previsto di ~ 3.15 anni. Improbabile che abbia catturato il tuo, ma non è particolarmente sicuro.

In alternativa, potrebbe avere una tabella arcobaleno gigante di 8 caratteri per un set completo di caratteri, che catturerebbe immediatamente la tua password.

C'è qualcosa a cui riesco a pensare su come li hanno fatti a pezzi così velocemente:

• Usano LM Hash nella tua azienda per Windows (molto pericoloso e quindi hai un problema più grande delle semplici password deboli)
• Hanno usato un attacco da tavolo arcobaleno e hanno un tavolo arcobaleno molto grande (8 caratteri è possibile)
• Hanno le tue password archiviate crittografate piuttosto che hash e le hanno decodificate con la loro chiave

Ad ogni modo 8 caratteri sono considerati dagli standard attuali abbastanza forti per la maggior parte degli utenti normali, ma consiglio sempre di usarne almeno 12. Se parliamo di amministratori di sistema o persone con accesso ad alcuni sistemi critici, consiglio sempre 16. Alcuni la gente considera questo "overkill" ma piuttosto li rende "troppo" forti di troppo deboli. Se utilizzi KeePass per proteggere le tue password, non devi preoccuparti di ciò che sono perché non devi ricordarle comunque.

Ho fatto un esercizio simile a un client (hash di Windows LM) e ho ottenuto oltre il 75% delle password utente con strumenti simili menzionati dal poster originale. Questo tipo di attacco di solito ottiene oltre il 90% di password derivate da 8 caratteri umani (occidentale e inglese). Più lunga è la password, più ampio è il charset - più difficile diventa questa e minore è la frequenza di trasmissione. Al mio cliente, molte password erano 8 caratteri o meno che mi rendevano la vita abbastanza facile. Il 25% era composto da caratteri lunghi o contenuti non inclusi nelle tabelle arcobaleno.

Se il tuo vicepresidente dell'IT aveva speso denaro per questo, avrebbe potuto usare una delle liste di passwd commerciali o una soluzione SaaS che ha veramente enormi repository di tutte le password disponibili per set di caratteri ampi (la maggior parte non include £ per esempio) e se le password erano generalmente inferiori a 10 caratteri, allora c'è una buona probabilità che abbia ottenuto un tasso di successo che si avvicina al 100%.

Molte persone hanno menzionato questo aspetto in modo molto più elaborato, e molti di loro sono tecnicamente corretti con le loro opzioni (prestare particolare attenzione alla risposta di Iszi in quanto tecnologicamente corretta e completa). Tuttavia, volevo solo dare i miei due centesimi e dire che probabilmente è una delle due cose che succedono.

1. Stanno memorizzando le password utilizzando la crittografia reversibile (un'opzione di gruppo di criteri AD), quindi utilizza solo la crittografia e le ha davvero "decodificate". Questa è un'idea orribile, ma le persone lo fanno per il controllo della password o per la compatibilità con le applicazioni legacy.

2. Sta mentendo e hanno decifrato la maggior parte, ma non tutte, le password.

C'è anche la possibilità che stiano memorizzando gli hash LM; la ragione per cui non penso che questo sia quello che stanno facendo è perché in quel caso avrebbero una grave mancanza di sicurezza adeguata.

Riscrivo continuamente le password nel mio lavoro e devo dire che non le ho mai affatto violate. Lavoro per un'azienda con circa 50.000 dipendenti e tipicamente creeremo circa 8.000 password con 1 ora di lavoro, ovvero il frutto basso in sospensione.

Una volta superata la fase di 1 ora di sforzo, diventa esponenzialmente più difficile decifrare le password (dal momento che in genere sono parole complesse non di dizionario di lunghezza sufficiente), quindi in genere ci fermiamo qui a meno che non ci proviamo per dimostrare un punto o crackare una password specifica. La maggior parte dei team di sicurezza non è in grado di monitorare e controllare continuamente le password di ogni singolo dipendente in una grande azienda, quindi selezioniamo il modo più semplice per decifrare e reprimere le password su base trimestrale.

Consentitemi di dire che se il vostro vicepresidente IT ha effettivamente violato il 100% delle password, avete dei vistosi buchi di sicurezza WAY al di sopra e al di là della relativa debolezza o forza della password in chiaro scelta dagli utenti.

Alcune possibilità:

• In realtà non stai utilizzando un hash. Molte librerie di sicurezza "incorporate", come per Criteri di gruppo o ASP.NET, rendono un'opzione le password crittografate anziché con hash. Lo scopo è quello di consentire a un amministratore di recuperare un account la cui password è stata persa senza far svanire completamente l'account. Ma, se è progettato per essere reversibile in modo efficiente, allora, beh, può essere invertito in modo efficiente. Se qualcuno avesse quel tipo di accesso per decrittografare le password in modo legittimo, è il CIO, ma potrebbe aver usato gli strumenti di cracking solo per dimostrare che non ha bisogno di l'accesso all'amministratore.
• Stai utilizzando un hash compromesso. MD5, LMHash, ecc sono danneggiati e dovrebbe mai essere utilizzato per l'archiviazione delle password.
• Stai utilizzando un hash tecnicamente crittografico, ma non adatto alle password, come SHA1 / 2. Questo di solito è per uno dei due motivi:
  • L'hash è troppo veloce per il calcolo, rendendo fattibile un attacco parallelo come una GPU o un cracker basato su botnet.
  • Le password, anche quelle buone, hanno un'entropia relativamente bassa rispetto ad altre cose per cui viene utilizzato un hash sicuro, come i digest dei messaggi / i checksum. A meno che l'entropia non sia aumentata artificialmente usando un salt casuale, in genere richiede un cracker a forza bruta meno tempo per trovare una password colliding piuttosto che trovare un messaggio colliding di input più grande.

Chiedi al VP di mostrarti cosa ha fatto per ottenere le password in chiaro e le password stesse. Non dovrebbe essere stato così facile. Se si ha il controllo sulla funzione di hashing utilizzata (il che significa che non è integrata, come per i Criteri di gruppo), vorrei passare a un hash progettato specificamente per l'hashing delle password, come bcrypt o scrypt. Questi due funzionano bene perché sono molto lenti e non solo sono lenti ora, ma possono essere configurati per essere sempre lenti, usando le funzioni di derivazione della chiave che prendono il sale ed eseguono un'operazione di complessità esponenziale variabile su di esso per "riscaldare" "l'hash basato su cipher. BCrypt è un hash completo, con KDF e cipher integrati; scrypt è solo il KDF, che può essere abbinato a qualsiasi crittografia sicura, come AES.

Dubbi che lo abbiano fatto senza un'enorme (irraggiungibile) quantità di potenza di elaborazione (per la parte a forza bruta, a meno che non costituisse solo una piccola parte dell'intero processo.) Un algoritmo di hashing di qualità è quasi impossibile da decifrare, quindi se ha "decrittografato" le password, probabilmente ha dovuto usare principalmente la forza bruta.

Inoltre, "decriptare" non è il termine corretto, decifrare ovviamente implica che le password erano una volta crittografate e la crittografia implica una funzione bidirezionale. L'hash è solo una funzione unidirezionale, cioè non può essere decodificato (beh, tipo, ma questo va oltre lo scopo di questa risposta).

8 caratteri non sono sufficienti! (permettimi di spiegare di seguito)

First though I'd like to add, for all correctness that 16k passwords can be all cracked if they are hashed with a weak algorithm. First, one will crack what can sometimes even be more than half of them(depending on the average IQ and carelessness of your colleagues) with a dictionary attack, then one bruteforces the rest using rainbow tables(let's say it's MD5 unsalted). It will take time, but not years, unless of course several people had a very long strong password. This will take a lot of time to bruteforce, possibly too long, but what are the odds, "the intellectual majority" doesn't care about good passwords, and even when they do like you for example, they use 8 characters. ;)

-Torna alla lunghezza della password -

Anche se dipenderà molto da ciò che l'amministratore usa per hash la tua password con

Come per esempio bcrypt, o forse anche meglio scrypt, con un elevato numero di iterazioni migliorerà drasticamente la sicurezza di ogni password (accettabile).

Ma quando parli di un'azienda con 16k dipendenti, c'è una possibilità di cose come lo spionaggio aziendale. Le persone che fanno queste cose sono la maggior parte delle volte molto tecnologiche e probabilmente hanno una botnet non molto grande, ma comunque decente, acquisita con un virus minuscolo scritto personalmente e distribuito, ad esempio un videogioco che hanno messo in una baia pirata.

Ho usato questo esempio per illustrare in che modo sono indirizzati ai giocatori con questo, il che significa che avranno un sacco di gpu che possono sanguinare quando necessario .

In questo modo il "tempo atteso di cracking di ~ 3.15 anni" come suggerito in precedenza dal Polinomio è diviso rapidamente, diciamo un migliaio di computer con schede gpu molto decenti che possono essere mollate quando sono inattive.

Ora la tua password hash MD5 è incrinata solo in ~ 1.149 giorni

(so let's say 1% has a 8 character random generated password like you, that's 160 x 1.149 = 221.37 days so it'll take him a little more than half a year to test all the passwords.)

Sebbene Lucas Kauffman abbia affermato correttamente che una password da 12 o anche 16 caratteri è tecnicamente la più appropriata, io personalmente preferisco una passphrase .

Jeff Atwood, il creatore di questo stesso sito web, li ha a lungo sostenuti !

Quindi inizia a usarne uno! Facile da ricordare, improbabile da decifrare.

Poche cose che mi infastidiscono in questa storia che mi fanno credere che stia bluffando (o così voglio crederci)

• Esistono strumenti per applicare la politica delle password a livello aziendale, è più rapido ed economico usarli piuttosto che violare tutte le password degli utenti solo per educarli all'uso di password migliori / più sicure

• Ha detto che ha decodificato le password, il che è un pessimo segnale, allude all'uso di una crittografia bidirezionale e non un hash unidirezionale + casuale, per utente salt (e una funzione hashing lenta come bcrypt , scrypt o PBKDF2) di nuovo, probabilmente è più facile risolverlo piuttosto che andare a decifrare tutte le 16.000 password. Dimostrare che la mancanza di attenzione alla terminologia di sicurezza, non va di pari passo con le abilità di hacker rockstar necessarie per incrinare 16.000 password.

• Qualunque sistema protetto da questa password non sembra avere alcun meccanismo di ritardo per tentativi falliti (che consente attacchi brute force) in modo che o abbiano accesso a qualche database interno e bypassato qualsiasi meccanismo di blocco / ritardo, oppure non hanno 't hanno tali protezioni sul loro sistema.

Spero davvero che la tua azienda non stia gestendo i soldi delle persone, gestendo processi medici sensibili o qualsiasi cosa abbia a che fare con la vita delle persone, in quanto è un paradiso per gli hacker. Assicurati che il nome della tua azienda rimanga anonimo perché non sembra valido da qui.

Per quanto riguarda il vicepresidente IT, spero davvero che stia scherzando, ma è un errore 22, se è riuscito a fare quello che ha fatto, significa solo che non sta facendo il suo lavoro giusto, e se non lo ha fatto, quindi è solo disonesto ed è altrettanto brutto.

Con una serie di tabelle arcobaleno è del tutto possibile che abbiano infranto tutte le password dell'azienda. Le tabelle Rainbow sono insiemi di hash precalcolati creati in anticipo rispetto ai tentativi di cracking della password che vengono utilizzati per crackare la password molto più velocemente dei metodi di forza bruta. rcracki è uno degli strumenti elencati nella tua domanda che fa proprio questo. hashcat e JtR sono strumenti a forza bruta, sebbene possano essere usati anche per creare tabelle arcobaleno.

Quindi non c'è dubbio che ciò che dice è interamente possibile.

A proposito, una password di 8 caratteri non è abbastanza in questi giorni, usa almeno 9.

Non sono un esperto di sicurezza, ma la mia comprensione è che la crittografia delle password quando salvate nel Database è unidirezionale, non può essere annullata. Quindi la password viene sottoposta a hash e salvata nel DB.

Tutto ciò che puoi fare è quando una persona vuole accedere, la password appena immessa viene sottoposta a hash e confrontata con l'hash nel DB e, se corrisponde, la password è corretta.