Un buon esempio è il difetto su CBC, dimostrato all'interno di SSL e in particolare per il recupero della password in una configurazione IMAP su SSL. Vedi per i dettagli. In breve, SSL ha un MAC, ma una piccola parte di esso faceva cose con i dati crittografati ricevuti dopo la decrittazione ma prima di verificare il MAC . Vale a dire, il sistema ricevente stava decrittografando i dati, controllando che il riempimento fosse corretto, segnalando un errore al peer se non era così, e quindi controllando solo il MAC. Il messaggio di errore era diverso se il MAC era sbagliato. Quindi il destinatario (il server, nel caso del recupero della password IMAPS) perdeva un singolo bit di informazioni sul fatto che il riempimento trovato dopo la decrittografia fosse corretto o meno. Accade così che SSL utilizzi un riempimento simile a quello descritto in PKCS # 5. I dettagli sono sottili (ma non matematicamente difficili, una volta compreso che XOR è commutativo e associativo) ma ha permesso all'aggressore, modificando alcuni byte ben scelti, di indovinare uno per uno i semplici byte di dati. Supponendo un normale tentativo di connessione con contenuti identici (in genere, un Outlook Express che controlla il server per la nuova posta ogni 5 minuti), l'aggressore aveva 1/256 di possibilità di indovinare un nuovo byte a ogni connessione. Alla fine della giornata, voilà! una password completa.
Questo caso mostra cosa può accadere in presenza di aggressori attivi e nessun MAC, anche quando la parte "nessun MAC" è molto transitoria; poiché SSL ha un MAC, solo che è stato controllato troppo tardi nel processo. La correzione consiste nel controllare sempre il MAC, indipendentemente dal fatto che il padding fosse buono o meno, e segnalare un cattivo padding e un cattivo MAC con lo stesso codice di errore (devi controllare il MAC, perché non fare se il padding è sbagliato può far sì che il server risponda un po 'troppo velocemente in quel caso, facendo trapelare il bit di informazione attraverso il tempo). Senza tale correzione, il server perde alcune informazioni attraverso il suo comportamento, che si tratti di un messaggio di errore distinto o anche di un leggero ritardo (o della sua mancanza) quando risponde. Questo è un singolo bit ad ogni tentativo. Tuttavia è sufficiente montare un attacco per il recupero della password.
Questo attacco è stato pubblicato nel 2002. Tuttavia, nel 2010, lo stesso bug era ancora presente nel modo in cui ASP gestisce i cookie crittografati, consentendo a un utente malintenzionato attivo di dirottare una sessione protetta in meno di un'ora. L'attacco è stato dimostrato come pratico nel 2002; nel 2010 è stato dimostrato come effettivamente praticato sul campo.
Non abbiamo un elenco esaustivo degli attacchi resi possibili dalla mancanza di MAC. Quindi la saggezza comune è che non esiste una protezione adeguata contro un utente malintenzionato attivo quando non esiste un controllo di integrità dedicato, e questo è un MAC. L ' errore comune è credere che in una determinata situazione gli aggressori possano essere solo passivi. Le comunicazioni cablate e wireless sono regolarmente soggette ad attacchi attivi anche da parte di malintenzionati a bassa potenza (ad esempio, studenti annoiati in un Internet cafè).
Quando si esegue la crittografia simmetrica, il modo corretto per aggiungere un MAC è utilizzare un modalità combinata di crittografia e MAC come GCM o EAX. Queste sono modalità che si basano su un cifrario a blocchi (tipicamente AES). Esistono altre modalità simili, ma alcune sono brevettate; si ritiene che questi due non lo siano.
Le firme (al contrario del MAC) sono una questione del tutto distinta, in particolare nel loro rapporto con la riservatezza.