In che modo un utente malintenzionato ottiene l'accesso alle password con hash?

Ci sono diversi modi:

• Iniezione SQL
• Backup trapelati
• Dipendenti scontenti che li perdono
• Qualsiasi tipo di violazione del server che consente l'esecuzione del codice.

Come puoi vedere ci sono molti, molti modi in cui questo potrebbe accadere - come phihag menzionato nei commenti, altro più della metà del OWASP top 10 potrebbe portare a perdite di hash, quindi non possono essere facilmente catalogati in palo.

Questo non significa che sia inevitabile che gli hacker ottengano gli hash, ma dovresti comunque usare un buon algoritmo di hashing per proteggere te stesso e i tuoi utenti per ogni evenienza. Poiché un backup può essere perso o il tuo server viene violato senza che tu te ne accorga, avere le password con hash appropriate dovrebbe essere l'unica cosa che ti consente di dormire la notte. Questa strategia è conosciuta come "difesa in profondità" , o semplicemente "piano per il peggio".

Ci sono molti metodi. Eccone alcuni che posso pensare in cima alla mia testa. Ora potrei essere un po 'in errore con la sintassi perché non mi sono preso la briga di provarlo subito, ma in generale, queste sono cose che dovresti fare per ottenere quei dati.

Si noti che, con i seguenti exploit, sono non necessariamente fornendo esempi che rubano gli hash (con l'eccezione di SQLi), ma esempi di come gli exploit possono funzionare. L'utente malintenzionato utilizza gli exploit di seguito per compromettere ulteriormente un sistema.

1. Iniezione SQL

   Esempio:
   a OR 1=1'; exec sp_msforeachtable "SELECT * FROM ?";--

   Potresti anche usare sp_msforeachdb , in questo modo:

   a'; exec sp_msforeachdb 'USE ?;exec sp_msforeachTable "SELECT * FROM !","!"';--

   Il -- è lì per commentare le parti dell'istruzione SQL che potrebbero interferire con l'iniezione. Questi sono solo esempi di base. Dipende davvero dal formato della query.

2. Iniezione del sistema operativo . %codice%
3. Iniezione LDAP . ; cat /etc/passwd; rm -rf /* , *

4. Riferimento ad oggetti diretti non sicuri che porta alla vulnerabilità di inclusione di file locali / remoti .

   (cn = *)(|(password =*))

   /etc/passwd%00 è un "terminatore null" usato per evitare che qualcosa venga dopo di esso, quindi non provi ad includere qualcosa che non esiste, ad esempio %00 . Potrebbe anche essere /etc/passwd.txt , \x000 , \z , \u0000 , %code% o %code% a seconda della lingua che stai utilizzando.

5. Hacking di uno sviluppatore / utente con accesso ai database.
6. Sfruttare il server del database o il server web con altri mezzi.

Un'aggiunta a Mark Buffalo:
7. Attacco man-in-the-Middle. Guardare il traffico non criptato può spesso rivelare un hash della password. In uno scenario pass-the-hash, i sistemi si fidano dell'hash e della password e consentono a un utente malintenzionato di copiare semplicemente l'hash senza scomporlo.

The only truly secure computer is one that is isolated from the internet, turned off, unplugged, buried in a bunker 100ft under ground, with armed guards at the only entrance. Even then, I'd check in on it every once in a while.

L'hashing delle password fa parte di ciò che è noto come "sicurezza in profondità". Hai ragione nel dire che, in un mondo ideale, non avresti commesso errori che avrebbero consentito agli aggressori di accedere a quei dati, quindi in teoria non avrebbe importanza se si trattasse di password in chiaro o hash. In un mondo reale, si verificano intrusioni, ed è notevolmente difficile prevedere come e dove si verificheranno. L'idea alla base della sicurezza è far sì che, in teoria, anche se un utente malintenzionato compromette in qualche modo il tuo sistema, ti sei sforzato di mitigare il danno.

Nel mondo reale, c'è una necessità naturale di accedere agli hash su base regolare. Ogni volta che un utente effettua l'accesso, è necessario poterlo accedere. Di conseguenza, sono quasi sempre accessibili a qualunque applicazione stia facendo l'autenticazione. Se qualcuno compromette la tua applicazione, potrebbe essere in grado di leggere i dati che non avrebbero dovuto essere in grado di leggere.

I modi in cui si verificano questi attacchi sono infiniti. È possibile avere attacchi SQL injection se non si riesce a disinfettare i dati immessi. Si può avere un sovraccarico del buffer, dando all'aggressore la possibilità di eseguire il proprio codice. Potresti avere un errore di autorizzazione, rendendo casualmente un file leggibile dalle persone quando non dovresti avere. L'utente malintenzionato potrebbe mettere le mani su uno dei nastri di backup a causa della cattiva gestione del servizio di backup!

Tutti questi attacchi danno al malintenzionato un punto d'appoggio sul tuo computer, ma non sempre portano a un'interruzione completa. È possibile che sia stato eseguito il chroot del server SQL, in modo che il processo del server SQL non visualizzi letteralmente l'intero resto del computer. Tuttavia, in tali situazioni, le informazioni di accesso necessarie agli utenti devono trovarsi entro la portata del server SQL o essere prive di valore. Pertanto, le informazioni di accesso vengono generalmente compromesse prima che si verifichino altri compromessi più nefandi.

Tagliando le password, diminuisci il loro valore. Un hash non è utile ai fini del login. Hanno bisogno di avere la password che hash a quel valore. Potrebbero o potrebbero non essere in grado di permettersi il costo di rompere l'hash. Nel migliore dei mondi, in primo luogo non devi mai preoccuparti di questo, ma se ti iscrivi all'approccio di sicurezza in profondità, assicurati che anche un'intrusione di successo non comprometta tutti i tuoi dati.

Alcune installazioni di un * x / linux in rete della vecchia scuola continueranno a utilizzare il servizio NIS / YP per l'autenticazione gestita a livello centrale. NIS pubblica in modo efficace le password hash sulla rete per ogni workstation in cui autenticare gli utenti.