Basics of Hashing Tokens

Background

Hashing critical information for security is a technique which is widely used when it comes to server-server communication. It is common that the service provider, Server 1, provides a unique private key(token) for each client, server 2, which is stored at the server-side. This private key is provided by different means like making the client to make an account at the service providers portal and after logging in a unique private key is shown to the user. The user which can be an administrator who is working at the service receiver company copies the private key at the server-side.
Example:
The Nordea bank needs to send requests to the tax agency for receiving some information about their customers. In this case, the Nordea bank shall need to send the private key to identify itself but for increasing the security the token salted with all other parameters is hashed and the result is sent instead of the actual token. A public key shall also be sent along.
Advantages:

• The token is not sent as plain text.
• If the request is picked up, some parameters are changed and then re-sent to the server as the hash value shall no longer be valid then the server will know about the malicious attempt. (Integrity)
• If the hashed value is picked up then it cannot be used In other requests.
• To prevent the replay attack, the current time + a margin can also be used as salt which is not a requirement in this course.

Why do we need to do this when there is HTTPS(SSL)?
This is mainly done as an extra layer of security and there is no question that SSL is always needed to be in place. For example banks can use this technique to double secure their communications. Please have in mind that SSL certificates can be stolen. Slim possibility but not zero. That’s why in critical systems like banks and military which are also popular targets double securing the system is a must.
From the article:
"That seems pretty straight forward. What was confusing you originally is that you thought the original request was being encrypted and sent, but really all the HMAC method does is create some unique checksum (hash) out of the arguments using a private key that only the client and server know."

See the following:
https://www.computerworld.com/article/2510856/security0/hackers-may-have-stolen-over-200-ssl-certificates.html
In this case, it took couple of days to revoke the certificates!

What can be done with stolen certificates:
https://zeltser.com/how-digital-certificates-are-used-and-misused/

Assignment

In this assignment you are expected to practice the same technique but as the token is delivered in the same channel then the security is not 100% though this technique can still improve the security.

What to do:
Upon each request, after login, the token is hashed and salted with other parameters in the request and sent to the server. The user's email address shall work as the public key.
Examples:

/postmessage
The receiver's email address, the message can be used as salt. In the end, the hashed value, the sender's email address(public key), the receiver's email address(salt) and the message(salt) are sent to the server.

/getusermessagesbytoken
In this example there are no other parameters but you can still use the path to the service and the http method used as salt. In this way the hashed value cannot be used in other requests.

Page responsible: Sahand Sadjadee
Last updated: 2018-02-28