De afkorting staat voor Hash-based Message Authentication Code. Deze bewerking van berichten waarborgt het kunnen controleren of een bericht tijdens het transport niet is aangepast. Door middel van een secret key wordt het bericht versleuteld en is een (kleine) verandering direct detecteerbaar. Op de development pagina staat uitgelegd hoe de afhandeling van de berekening gaat.
De opbouw van de Hash-based code is als volgt : HMAC [Websitekey]:[Base64hash]:[Nonce]:[TimeStamp]. De schuin gedrukte velden in de HMAC staan voor de volgende informatie :
* Aanwijzing : De Base64-hash moet een reeks van 44 tekens zijn. Als de berekende waarde meer dan 44 tekens is, is deze mogelijk in hexadecimaal formaat berekend.
Zie hieronder de waarden die worden gebruikt om de HMAC SHA256-hash te genereren. Al deze parameters (behalve de secret key) moeten worden samengevoegd tot één tekenreeks voor het genereren van de HMAC SHA256-hash.
* Aanwijzing : de Base64-reeks zal uit 24 tekens bestaan. Als er meer dan 24 tekens in de reeks staan, wordt de Base64 waarschijnlijk berekend over de MD5-hash in hexadecimaal formaat
Met de Buckaroo Authentication Debugger op de Buckaroo development omgeving kan de HMAC worden berekend en vergeleken met de uitkomst van de eigen gebouwde functionaliteit. Wanneer in de debugger op Execute wordt geklikt, zal de berekening worden gedaan en staat er uitleg aan de rechterzijde. De gegevens uit de tussenstappen zal ook worden getoond zoals :
In de .NET SDK van Buckaroo staat de manier uitgeschreven waarop de handtekening van een bericht kan worden berekend voor verzending en kan worden geverifieerd bij ontvangst van de berichten. Op die manier kan op eenvoudige wijze worden gecontroleerd of het bericht is verzonden door Buckaroo en onbewerkt is aangekomen bij de Push URL. Gebruik onderstaande knop om direct naar de SDK toe te gaan.
Wanneer er gebruik wordt gemaakt van een JAVA implementatie, zijn een aantal aandachtspunten van toepassing. Op de checkout van Buckaroo is een voorbeeld van java codering uitgeschreven. Hieronder enkel voorbeelden van problematieken uit de praktijk.
De Base64 over de MD5 hash wordt vaak uitgevoerd door standaard JAVA componenten, maar niet altijd met de gewenste output. In een voorbeeld code in ZIP voor java kan worden terug gevonden hoe de handtekening berekening plaats kan vinden. Vergelijken met de eigen ontwikkelde code geeft de bouwer inzicht in de manier waarop de logica kan worden opgebouwd.
Als eerste kan gebruik worden gemaakt van de uitleg van de Timestamp berekening in java op de site van TecAdmin. Wanneer geprobeerd wordt een lokale timestamp te berekenen, maakt het niet uit of het bericht de tijd uit London of Amsterdam heeft. Wat wel uitmaakt is dat de tijd (soms) in milliseconden wordt berekend in plaats van seconden. Een unix timestamp werkt met een uitgerekende tijdsverschil tussen 1 jan 1970 (epoch) en nu, uitgedrukt in seconden. In java wordt deze tijd standaard opgehaald in milliseconden, wat betekent dat het resultaat moet worden gedeeld door 1000. Als dat niet gebeurt, wordt het resultaat 1000 keer groter en lijkt het alsof een bericht uit de verre toekomst wordt ingeschoten. De volgende voorbeeldcode kan daar een oplossing voor zijn:
// EXAMPLE FOR THE CALCULATION OF THE UNIX TIMESTAMP.
// A UNIX TIMESTAMP IS THE TIMESPAN BETWEEN THE UNIX EPOCH (1-1-1970) AND THE CURRENT TIME, DEFINED IN SECONDS.
private String calculateUnixTimeStamp()
{
long unixTime = System.currentTimeMillis() / 1000L; // the division by 1000 is performed to convert msec -> sec
String timeInSecondsAsString = Long.toString(unixTime);
return timeInSecondsAsString;
}
Soms komt een HMAC foutmelding naar voren bij de import van de WSDL in een java omgeving. Daarbij is het mogelijk de volgende WSDL voor soap in java te gebruiken, waarbij die foutmelding niet voorkomt.