Sorprendentemente, MYSQL è un ottimo esempio attuale. La recente modifica del sito mysql.com di Oracle ( Ironia: i siti Web MySQL e Sun hackerati tramite l'iniezione SQL - TNW Industry ) hanno esposto un sacco di hash non salati per account importanti, con password di alta qualità come "qa" per tre account (qa_r, qa_rw e qa_adm), tutti di cui hash a "077f61a849269b62". Potrebbero essere facilmente ricercati su siti di tabelle ad arcobaleno come Recupero password - MD5, SHA1, MySQL .
Anche l'algoritmo "nuovo, migliorato" usato da MYSQL 4.1.1 è semplicemente una doppia applicazione non salda dell'algoritmo SHA-1 ora deprecato. Vedi Simulazione della crittografia di MySql's password () utilizzando .NET o MS SQL - Overflow dello stack . Nella documentazione per PASSWORD () dicono che dovresti non usarlo nelle tue applicazioni . Ma il consiglio che danno è terribile e non offrono scuse per il motivo per cui non si limitano a migrare a un buon algoritmo con non solo sali ma anche hashing adattivo come bcrypt o PBKDF2 . Nota che se non usi una tecnica adattativa per iterare l'hash, ogni hash salato è molto vulnerabile in questi giorni per attacchi a forza bruta a buon mercato che possono provare miliardi di password candidate al secondo.
Aggiornamento : un esempio sbalorditivo di un enorme database non protetto per le password (con suggerimenti!) è l'insieme di 130 milioni di Adobe, memorizzato utilizzando la crittografia reversibile (3DES), che è stato esposto nell'ottobre 2013 E, naturalmente, anche il fatto che abbiano crittografato piuttosto che l'hashing è terribile. Vedi Come un epico errore da Adobe potrebbe rafforzare la mano di password cracker | Ars Technica . Si tratta di un database, presumibilmente non un'applicazione disponibile, che illustra di nuovo il motivo per cui non dovresti roll-your-own come questo nel mondo della sicurezza.
Era il soggetto del fumetto di XKCD "Encryptic": 1286: Encryptic - spiega xkcd