Op hashing gebaseerde code voor het authenticeren van berichten (oftewel HMAC) is een cryptografische authenticatietechniek waarbij gebruik wordt gemaakt van een hashing-functie en een geheime sleutel.

Met HMAC kunt u aan de hand van gedeelde geheimen authenticeren en nagaan of data correct en authentiek is. U hoeft dan geen handtekeningen of asymmetrische cryptografie te gebruiken, zoals bij andere methoden.

Hoe HMAC werkt 

Twee partijen die onderling willen communiceren, willen dat de inhoud van hun communicatie privé blijft. Ze wantrouwen het internet en willen zeker weten dat er niet is geknoeid met de pakketten die ze ontvangen. Dan is HMAC een goede optie. 

HMAC bestaat uit tweecomponenten:

1. Cryptografische sleutels. Een versleutelingsalgoritme wijzigt de data en de ontvanger heeft een specifieke code (of sleutel) nodig om de data weer leesbaar te maken. HMAC is gebaseerd op een gedeelde reeks geheime sleutels.
2. Hashing-functie. Een hashing-algoritme wijzigt of verwerkt het bericht nogmaals. HMAC maakt gebruik van generieke cryptografische hashing-functies zoals SHA-1, MD5 en RIPEMD-128/60.

Twee partijen die het systeem gebruiken, moeten afspraken maken over de volgende aspecten:

• Geheime sleutels. Ze moeten een manier hebben om de berichten die ze ontvangen, te decoderen. Voor deze taak kan een geheime sleutel worden gebruikt die met niemand gedeeld mag worden.
• Algoritme. De partijen moeten één hashing-functie kiezen die zal worden gebruikt voor al hun berichten. 

Na het hashen kan er geen reverse engineering op het bericht worden toegepast en is het bericht bestand tegen hackingaanvallen. Iemand die het bericht onderschept, zal niet eens de lengte ervan kunnen raden. Dankzij dit proces is de inhoud van het bericht volledig onbruikbaar als iemand niet over de sleutel of code beschikt. 

HMAC-testtools kunnen worden gebruikt om te laten zien hoe dit in zijn werk gaat. Stel, u hebt de volgende inputs:
 

• Bericht: Ik wil graag 100 eenheden kopen. 
• Geheime sleutel: 666
• Algoritme: MD5

Na het hashen ziet het bericht er zo uit: "fd9f18089206e67b163771a3883185ab." 

Dit lijkt een eenvoudige omzetting, maar er ligt aardig wat wiskunde aan ten grondslag. Om te laten zien hoe HMAC er wiskundig uitziet, gebruiken we dit soort diagrammen. 

Het is van groot belang dat developers de wiskunde achter hashing begrijpen. Diagrammen zijn vaak geschikter dan woorden om uw werk en de bescherming die u biedt toe te lichten.

Maar voor gewone computergebruikers zal deze informatie in de meeste gevallen overbodig zijn. Die willen gewoon zeker weten dat hun berichten goed beschermd zijn.

HMAC implementeren 

Als u HMAC wilt gebruiken, hebt u twee belangrijke dingen nodig, of u nu wel of geen developer bent. En u moet afspraken met de ontvangers maken over deze aspecten, zodat iedereen tegelijkertijd dezelfde tools gebruikt.

De twee dingen die u nodig hebt zijn:

1. een gedeeld geheim 
2. een hashing-tool 

Alleen uw server mag de twee elementen voor al uw gebruikers kennen. En de gegevens moeten buitengewoon goed worden beschermd. Als anderen de geheime sleutels van uw leden in handen krijgen, kunnen ze uw server overnemen en/of frauduleuze gegevens versturen. 

Elke website en codeeromgeving is anders, maar het kan toch nuttig zijn om een voorbeeld te bekijken. Stel, u wilt HMAC gebruiken voor verkeer dat uw website bereikt via dynamische Google-advertenties. U moet dan een paar dingen doen:

• Uw token genereren in Ad Manager. Geef details op over het bezoek en het tijdstip. Gebruik vervolgens de authenticatiesleutel van Google om een "geheime sleutel" te genereren.
• Implementatie. U kunt het nieuwe token nu opnemen in de header van uw autorisatieverzoek of doorgeven als query string of dataparameter voor formulieren. 

Met Google is dit proces snel en eenvoudig. Developers kunnen een eenvoudige tutorial bekijken en binnen een paar minuten de nodige code kopiëren.

U hoeft Google Ads-bezoekers niet te vragen om een code te onthouden of decoderingstaken uit te voeren. De server van de gebruiker begrijpt de coderingsvereisten van uw website en de gebruiker merkt niets van de token-configuratie en -omzetting. 

U moet deze omgeving vóór implementatie wel testen, want een coderingsfout kan tot gevolg hebben dat mensen die uw site willen bezoeken onterecht worden aangemerkt als frauduleus en ze kunnen geblokkeerd worden. Het is de moeite waarde om een systeem als dit vóór een brede lancering op meerdere devices te testen.

Waarom zou u HMAC gebruiken?

Elke organisatie heeft wel gevoelige informatie. Als u bijvoorbeeld betalingen accepteert, zal u mogelijk creditcardgegevens in uw bezit hebben. En als u medewerkers hebt, wilt u natuurlijk niet dat hun burgerservicenummers worden gestolen. 

Voor sommige organisaties is dit een nog serieuzere kwestie. Als u bijvoorbeeld actief bent in een strikt gereguleerde sector, zoals de gezondheidszorg, of handelt in gevoelige goederen, zoals munitie, is het de moeite waarde om meer geavanceerde securitymaatregelen te treffen. 

HMAC kan met zijn dubbele beschermingslaag ideaal zijn voor organisaties die zich extra moeten inspannen om te bewijzen dat hun middelen zo goed mogelijk beschermd worden. 

Hulp van Okta

Bij Okta zetten we in op security-oplossingen op maat die onze klanten helpen succesvol te zijn. Ontdek hoe Okta HMAC-algoritmes voor ondertekening gebruikt om uw organisatie veilig te houden.

Referenties

HMAC: Keyed-Hashing for Message Authentication. (Februari 1997). Network Working Group. 

HMAC and Key Derivation. Practical Cryptography for Developers. 

HMAC Generator/Tester Tool. FreeFormatter. 

How API Request Signing Works (And How to Implement HMAC in NodeJS). (2016). Andrew Hoang. 

Implement HMAC Authentication (Beta). Google Ad Manager Help.