HMAC fornisce integrità e autenticazione dei messaggi. Se ricevi un messaggio con un HMAC corretto, lo sai:
- il messaggio è intatto;
- il mittente ha la chiave.
Poiché il mittente ha la chiave, sai che il messaggio proviene da qualcuno a cui hai dato la chiave. Se si distribuisce la chiave solo agli utenti noti, si può essere certi che il messaggio sia originato da un utente conosciuto.
A volte la chiave viene utilizzata dallo stesso sistema e non è necessario lo scambio di chiavi. Ad esempio, una funzionalità di reimpostazione della password su un sito Web può creare un HMAC e inviarlo via e-mail. Se fai clic sul link nell'email, lo stesso sito verifica l'HMAC. Poiché HMAC è stato creato e verificato dallo stesso software, non è necessaria alcuna verifica.
In altre applicazioni, ad esempio in OpenID, ogni client ha il suo segreto condiviso con il server. Quando si aggiunge un client a OpenID è inoltre necessario specificare la chiave per l'operazione HMAC. Questo passo di configurazione viene eseguito una volta.
Nel tuo esempio con il client e il server C #, la chiave è hardcoded. Il server può quindi verificare che la richiesta provenga realmente dal client. Comunque
sarebbe abbastanza facile estrarre la chiave dal client e falsificare una richiesta.
Un metodo di scambio chiave per HMAC non ha molto senso. Potrebbe essere utilizzabile in un altro meccanismo crittografico, ma normalmente le chiavi HMAC sono abbastanza statiche.
Infine chiedi come funziona in combinazione con HTTPS. HTTPS fornisce l'autenticazione del server. È possibile utilizzare i certificati client per ottenere l'autenticazione del client, ma questo non è abilitato per impostazione predefinita. Con HTTPS, i messaggi non possono essere modificati durante il trasporto. Quindi l'unica cosa che la soluzione HMAC potrebbe aggiungere è l'autenticazione client.