Risposta breve:

Non puoi decifrare l'hash. Dovrai utilizzare altri mezzi per ripristinarlo.

Spiegazione:

Il risultato di un hash non è una versione crittografata della password. Non può essere decifrato, non più di quanto tu possa prendere hashbrown e ricostruire una patata intera. Il risultato di un hash crittografico è una versione criptata dei dati, con gran parte dei dati originali persi. Puoi indovinare quali potrebbero essere stati i dati persi, ma probabilmente ti sbaglierai, e con le funzioni hash crittografiche, essere un po 'sbagliato in un punto qualsiasi renderà i dati calcolati molto diversi dai dati originali.

Tuttavia, puoi recuperare quella password predefinita usando diversi mezzi, assumendo che tu abbia accesso al codice sorgente del vecchio sistema. Qui ci sono tre possibilità:

1. Poiché è una password predefinita e questa password è identica per tutti, gli sviluppatori originali non hanno prestato molta attenzione alla sicurezza delle password. Controlla il codice sorgente intorno alla creazione dell'utente; la password può essere memorizzata in testo normale.

2. La password predefinita deve essere comunicata in qualche modo al nuovo utente. Crea un nuovo account, chiedi al tuo amministratore IT o chiedi al rappresentante delle risorse umane che fornisce la password ai nuovi dipendenti.

3. (Un po 'losco) Puoi anche copiare le password su wholesale dal vecchio sistema al tuo nuovo sistema e, quando un utente accede utilizzando la password predefinita, la avrai in chiaro per un breve momento mentre il sistema di autenticazione verifica che la password corrisponda all'hash memorizzato. Utilizzalo come un'opportunità per cambiare la password di tutti a un algoritmo di estensione delle chiavi come PBKDF2, bcrypt, scrypt o Argon2id.

E, se tutto ciò fallisce, chiama l'utente al telefono, spiega la situazione e pianifica un orario in cui potrà guardarti mentre lavori e reimpostare la password subito dopo. (La metto solo come ultima opzione, perché è stato menzionato nei commenti che questa è la situazione che vuoi evitare.)

In tutti i casi, dovresti far scadere la password immediatamente (perché tu appena compromesso). Tuttavia, l'uso di una password predefinita suggerisce che l'applicazione probabilmente non ha una funzione di scadenza della password, quindi questo è probabilmente un punto controverso.

E mentre lavori su sistemi di autenticazione, testa oltre alle Linee guida sull'identità digitale del NIST, sfoglia tutto e presta particolare attenzione a SP 800-63B.

Aggiungerò alla pletora di risposte qui un semplice esempio, perché trovo che ridurre le cose alle basi può spesso essere molto istruttivo. La chiave è che gli algoritmi di hashing distruggono i dati. Un hash Argon2 sempre ha 32 byte anche se gli dai da mangiare tutto Wikipedia. L'unico modo per farlo è buttare via molti dati e una volta gettati via non c'è più.

Per dimostrare che ho un algoritmo di hashing semplice (e terribile). Controlla il suo input per eventuali lettere maiuscole. Se trova delle lettere maiuscole, restituisce True . In caso contrario, restituisce False . Qui ci sono alcuni ingressi e uscite esempio:

  123456 -> Falseasdfer -> Falserfjeif -> False27 _ + $ (-> FalseweAdfy -> TrueErYHV1 -> True12345W -> TrueWERERE -> True  

Ora ho l'hash di un utente ed è: True . Qual era la password?

La tua domanda è un po 'confusa, quindi se quanto segue non si adatta perfettamente alla tua situazione, correggi i seguenti presupposti:

• Il tuo sistema memorizza i dati crittografati per più utenti.
• I dati di ogni utente vengono crittografati utilizzando una chiave per utente univoca o una chiave master crittografata (incapsulata) con una chiave per utente.
• La chiave di ogni utente è crittografata (con wrapping ) con una chiave derivata o direttamente dalla password dell'utente.
• Conosci le password di alcuni utenti ma non di altri.
• Conosci l'algoritmo di hashing della password utilizzato per autenticazione.
• Hai accesso agli hash di autenticazione.
• Gli hash di autenticazione non sono salati ("ogni hash predefinito è identico").
• O lo sai oppure puoi accedere all'algoritmo utilizzato per la derivazione della chiave dalle password.
• Desideri decrittografare i dati per gli utenti di cui non conosci le password.

Senza saperne di più sul sistema (come i cifrari utilizzati, gli algoritmi di derivazione hashing / chiave utilizzati e così via), non riesco necessariamente a trovare i punti più deboli del sistema da attaccare. Tuttavia, come descritto, sembra che l'anello debole siano gli hash delle password. Se in realtà sono gli stessi per una determinata password, ciò indica che non sono salati, il che implica uno schema di hashing della password molto debole (forse qualcosa di pessimo come MD5 a round singolo). Per un hash non salato, è probabilmente possibile utilizzare una tabella arcobaleno (una tabella di ricerca che associa digest hash precalcolati ai valori di input). Tuttavia, anche se non puoi (ad esempio, le password che desideri non sono presenti nelle tabelle che puoi trovare), forzare brute tali hash di solito è abbastanza facile; le moderne GPU consumer possono eseguire letteralmente miliardi di tali hash al secondo, quindi tutto ciò di cui hai bisogno è un hardware adatto (localmente o nel cloud), un set di password candidate (e processi per generarne di più, possibilmente includendo letteralmente solo la forza bruta di ogni possibile carattere fino a una certa lunghezza), software come "hashcat" o "john the ripper" e un po 'di tempo.

Per affrontare più direttamente la questione: tutti i moderni standard di crittografia e hashing operano sul presupposto che deve essere sicuro anche se l'aggressore sa esattamente quali sono i passaggi dell'algoritmo. Conoscere l'algoritmo - che domina strettamente il valore della conoscenza di alcune coppie (input, digest) per un algoritmo hash, perché potresti calcolarlo da solo dato che hai l'input e l'algoritmo - è l'assunto di base che tutte le criptovalute moderne devono essere al sicuro contro. Crypto non varrebbe molto se pochi (siamo generosi) milioni di coppie di input / output fossero sufficienti per rompere l'algoritmo di cifratura o hash.

No, le informazioni sulle password note non saranno di alcun aiuto per violare le password sconosciute.

Gli hash sono il risultato di funzioni trapdoor unidirezionali. L'hashing differisce dalla crittografia in quanto la crittografia può essere invertita, mentre l'hashing non può. L'hashing distrugge le informazioni e non c'è modo di ricostruire la password originale da un hash sicuro. Se c'è una leggera modifica nella password originale, l'hash risultante sarà completamente diverso. Quindi non puoi nemmeno confrontare due hash per vedere se le password originali sono simili.

Molti progetti open-source rivelano come vengono sottoposte ad hash le password delle loro applicazioni. Questo non rende gli hash meno sicuri. Esistono anche database costituiti da note combinazioni di hash password. Quelle non aiutano a decifrare le password sconosciute al database.

Sei lasciato ai metodi convenzionali per decifrare le password, che di solito implicano provare le possibili password in modo automatico per vedere se corrispondono all'hash. Questo non è affatto più facile o più veloce di 58 telefonate.

La risposta breve è che tutte le informazioni che hai aiutano ma se non sei disposto a prenderti il ​​tempo per fare 58 telefonate, allora non ti piaceranno le settimane / mesi / anni che potrebbero richiedere , anche con tutte le tue informazioni privilegiate.

Considera questo: ogni sistema di password ovunque è uguale al tuo: conoscono l'hash, il sistema e possono creare quante più password da testare. E l'hashing è ancora considerato sicuro, anche in quelle condizioni.

Potresti provare a eseguire dizionari delle password contro i tuoi hash per vedere se gli utenti hanno utilizzato password indovinabili. Ma non sarà ancora al 100%.

Ghedipunk menziona questa soluzione ma volevo approfondirla.

Se sei in grado di duplicare correttamente il meccanismo di hashing, puoi aggiornare le password degli utenti appena in tempo.

Cioè, quando un utente accede, controlla che le credenziali del suo account siano memorizzate utilizzando il vecchio metodo. In tal caso, convalida le credenziali rispetto al vecchio metodo e quindi aggiorna immediatamente l'account a una nuova credenziale (sicura).

Nel nuovo sistema, consiglierei anche di scadere tutto account utente che utilizzano il vecchio metodo in modo che li costringa a cambiare la password.

Il punto di memorizzare crittograficamente le password come hash è che nessuno, inclusi gli amministratori, può scoprire la password in testo normale.

Infine, per te e per gli altri, se il vecchio metodo di autenticazione è sicuro e segue le migliori pratiche, non è necessario utilizzare un nuovo metodo. È sufficiente spostare il vecchio metodo di autenticazione nel nuovo sistema.

Hai sbagliato

Non esiste un "deve essere". Per vederlo, devi solo considerare questo: se c'è un modo, nessuna password può essere protetta da un precedente dipendente. E poi, da qualsiasi dipendente. E poi, da qualsiasi persona, davvero.

Le password vengono memorizzate con hash crittografico per impedire a chiunque di vedere i dati originali. Ciò include you.

Non è necessario decifrare le password

Sarai responsabile del nuovo sistema e del nuovo processo di accesso completo. Conosci l'intero vecchio processo. Quindi, nel nuovo sistema hai solo bisogno del vecchio database delle password e di una copia del vecchio processo.

Se un accesso sul nuovo sistema fallisce, esegui il processo precedente sul vecchio database delle password per autorizzare i vecchi accessi nuovo sistema.

Dovresti anche creare una nuova credenziale di accesso ed eliminare la vecchia voce del database in caso di successo, in modo che qualsiasi utente venga migrato senza problemi.

Come affermano le altre risposte, il recupero delle password direttamente non sarà possibile.

Tuttavia, dato che i dati desiderati sono le note dell'utente, ci sono altre opzioni:

Utente amministratore DB

Presumendo che tu abbia accesso legittimo al back-end, potresti estrarre i dati come utente amministratore del db. (vedi il commento di Trotski94)

MITM

Puoi distribuire il nuovo dashboard e importare i nuovi dati solo quando l'utente ti dà la propria password. Questo è effettivamente un MITM. (vedi commenti di Conor Mancone ed eckes)

Hashcat

In mancanza di queste opzioni, esegui gli hash contro hashcat (lo strumento di recupero della password). Per lo meno potrebbe ridurre il numero di telefonate che devi fare.

Conclusione

Sfortunatamente, a parte la prima opzione, probabilmente è meno impegnativo solo per effettuare le chiamate .

Definisci semplice.

Dato che conosci e hai l'algoritmo e puoi verificarlo per un esempio, è banale "forzare" le altre password.

risorse sufficienti e tempo. Se suddividi lo spazio in blocchi (unità di lavoro) e collaudi in parallelo, le cose saranno più facili. Escludendo una siccità delle risorse guidata dalla frenesia dei clic, potresti avere centomila thread che funzionano per meno di un giorno fino a 15 caratteri, anche senza istanze GPU e CUDA. Questo viene fatto regolarmente per blockchain, Folding at home, SETI at home ecc.

Hashcat è un buon punto di partenza, ma se gli hash sono troncati o le sottostringhe sarà comunque necessario modificare il codice per confrontarlo con una maschera. Probabilmente non sarai in grado di personalizzare un "Antminer" per questo.

Ovviamente è molto più semplice aggiornare (sovrascrivere) la loro password a un valore noto e costringerli a reimpostarla. È comune nello sviluppo aggiornare semplicemente l'hash con l'hash di una password arbitraria.

Alla radice del problema è che tu (o il tuo sistema legacy) non state monitorando l'età o le modifiche della password. Vuoi estrarre i dati solo per coloro che non hanno cambiato la password o si sono presi il loro tempo o cambiati di rado?

Hai provato un "gruppo per" e "ordine per discendente"? Se hanno tutti la stessa password predefinita, verranno visualizzati all'inizio di quella.

Sostengo l'idea di un'eventuale migrazione, con un negozio legacy e un negozio "modernizzato".

No.

Il punto centrale di una crittografia unidirezionale decente è che il solo sapere come funziona la crittografia non è sufficiente per invertirla.

Se non fosse così , le persone come te sarebbero in grado di decrittografare i dati di altre persone solo con la piccola quantità di informazioni che ci hai detto di avere.

È ovvio che questa non è sicurezza.

Questi algoritmi sono letteralmente progettati per contrastare esattamente ciò che stai cercando di fare.

Inoltre, la crittografia in questo caso è un hash , non esiste una mappatura uno-a-uno dei dati sull'hash. Sostieni di comprendere il concetto di hash unidirezionale, ma mi sembra che tu abbia ancora un po 'di lettura da leggere!