MD5 è considerato insicuro?

MD5 per le password

L'utilizzo di md5 salato per le password è una cattiva idea. Non a causa delle debolezze crittografiche di MD5, ma perché è veloce. Ciò significa che un utente malintenzionato può provare miliardi di password candidate al secondo su una singola GPU.

Quello che dovresti usare sono costruzioni di hash deliberatamente lente, come scrypt, bcrypt e PBKDF2. Semplice SHA-2 salato non è abbastanza buono perché, come la maggior parte degli hash di uso generale, è veloce. Consulta Come fare in modo sicuro le password di hash? per i dettagli su cosa dovresti usare.

MD5 per l'integrità del file

L'uso di MD5 per l'integrità dei file può essere o meno un problema pratico, a seconda dello scenario di utilizzo esatto.

Gli attacchi contro MD5 sono attacchi di collisione, non di attacchi pre-immagine. Ciò significa che un utente malintenzionato può produrre due file con lo stesso hash, se ha il controllo su entrambi. Ma non può eguagliare l'hash di un file esistente che non ha influenzato.

Non so se gli attacchi si applicano alla tua applicazione, ma personalmente inizierei a migrare anche se pensi che non sia così. È fin troppo facile trascurare qualcosa. Meglio prevenire che curare.

La migliore soluzione in questo contesto è SHA-2 (SHA-256) per ora. Una volta che lo standard SHA-3 sarà standardizzato, sarà anche una buona scelta.

Per completare la risposta di @CodesInChaos, MD5 viene spesso utilizzato a causa di Tradizione , non a causa delle prestazioni. Le persone che gestiscono database non sono le stesse persone di coloro che si occupano di sicurezza. Spesso non vedono alcun problema nell'utilizzo di algoritmi deboli (ad esempio, vedi lo scherzo di un algoritmo che MySQL stava usando per le password di hashing). Usano MD5 perché usavano MD5 e sono abituati a usare MD5.

Le prestazioni sono molto più spesso discusse che misurate; e tuttavia, logicamente, non può esserci un problema di prestazioni se non c'è nulla da misurare. Utilizzando un core di una CPU di base, è possibile eseguire l'hash di oltre 400 MByte al secondo con MD5, più vicino a 300 MB / s con SHA-1 e 150 MB / s con SHA-256. D'altro canto, un discreto hard disk produrrà dati ad un tasso ancora più basso (da 100 a 120 MB / s sarebbe tipico), quindi la funzione hash non è quasi mai il collo di bottiglia. Di conseguenza, non vi è alcun problema di prestazioni relativamente all'hash nei database.

I soliti consigli, per le funzioni di hash, sono:

1. Non farlo. Non dovresti usare algoritmi crittografici elementari, ma protocolli che assemblano diversi algoritmi in modo da fornire collettivamente alcune funzionalità di sicurezza (ad esempio trasferimento di dati con riservatezza e integrità).

2. Davvero, non farlo. Per memorizzare le password (più precisamente, token di verifica password), non creare un mix personalizzato di una funzione hash e sali; utilizzare una costruzione che è stata studiata appositamente per tale uso. Questo normalmente significa bcrypt di PBKDF2 .

3. Se una funzione di hash è effettivamente ciò che fa il lavoro, quindi utilizzare SHA-256. Prendi in considerazione l'utilizzo di qualsiasi altra funzione solo se qualche problema serio con SHA-256 (molto probabilmente la sua performance ) è stato debitamente rilevato e misurato.

I'm using salted hashes currently (MD5 salted hashes).

Se stai salando gli hash MD5, sicuramente non vuoi usare MD5. Sembra che tu debba utilizzare PBKDF2 o bcrypt.

As far as I know it's always been the algorithm of choice among numerous DBAs.

Questa non è una ragione convincente.

Ho lavorato con molti DBA che hanno almeno 5 anni di ritardo nella tecnologia generale (non usando il controllo di versione, script perl non formattati per tutto, ecc.). Potrebbero essere stati DBA particolarmente cattivi, ma penso che arrivi con la mentalità estremamente conservatrice di non cambiare le cose.

Solo per completare le risposte già date (molte delle quali sono eccellenti) ora abbiamo un esempio reale di dove una violazione dei dati (Ashley Madison) ha portato all'intera tabella delle password trapelata. Hanno usato bcrypt con un salt casuale per cancellare le password. Un ricercatore di sicurezza ha deciso di prendere quegli hash e la forza brutale. Questo è stato il risultato

As a result of all this, bcrypt is putting Herculean demands on anyone trying to crack the Ashley Madison dump for at least two reasons. First, 4,096 hashing iterations require huge amounts of computing power. In Pierce's case, bcrypt limited the speed of his four-GPU cracking rig to a paltry 156 guesses per second. Second, because bcrypt hashes are salted, his rig must guess the plaintext of each hash one at a time, rather than all in unison.

"Yes, that's right, 156 hashes per second," Pierce wrote. "To someone who's used to cracking MD5 passwords, this looks pretty disappointing, but it's bcrypt, so I'll take what I can get."

Pierce gave up once he passed the 4,000 mark. To run all six million hashes in Pierce's limited pool against the RockYou passwords would have required a whopping 19,493 years, he estimated. With a total 36 million hashed passwords in the Ashley Madison dump, it would have taken 116,958 years to complete the job.

Alla fine della giornata, gli unici che era in grado di decifrare erano password ridicolmente semplici o comuni (come "123456").

Sì MD5 non è sicuro e quindi è SHA-1, ti consiglio di usare SHA-256 se la dimensione del digest è un problema. Ricorda, se lo memorizzi in una colonna BINARY, occuperà meno spazio se memorizzato in CHAR. Assicurati che sia fatto correttamente. MD5 è circa 2,3 volte più veloce di SHA-256. Altri parametri di riferimento sono disponibili all'indirizzo link

Per dirla in breve tempo è abbastanza insicuro a causa delle tabelle arcobaleno, la tabella Arcobaleno è un elenco di hash MD5 e le loro stringhe corrispondenti. Quindi fondamentalmente considererei altre alternative come SHA1

State tutti parlando di insicurezza, ma nessuno di voi ha dato una risposta chiara alla domanda.
Ho lavorato con MD5 e Sha512, entrambi facili da decifrare una volta che ho messo il mio piccolo esperto di hacker su di esso, fino a quando non ci ha colpito entrambi come un fulmine! Il modo più semplice ed efficace per fermare "Attacchi di massa" come quelli sopra descritti, sta impostando un limitatore di tentativi di accesso, che significa:

function checkbrute($user_id, $mysqli) {
 // Get timestamp of current time
   $now = time();
   // All login attempts are counted from the past 2 hours. 
   $valid_attempts = $now - (2 * 60 * 60); 

   if ($stmt = $mysqli->prepare("SELECT time FROM login_attempts WHERE user_id = ? AND time > '$valid_attempts'")) { 
  $stmt->bind_param('i', $user_id); 
  // Execute the prepared query.
  $stmt->execute();
  $stmt->store_result();
  // If there has been more than 5 failed logins
  if($stmt->num_rows > 5) {
     return true;
  } else {
     return false;
  }
}
}

Hai capito il mio punto?
La quantità massima di combinazioni che l'hacker vuole provare, è limitata a 5 fallimenti per 2 ore. Puoi anche bloccare l'utente dopo X tentativi.