Trying to use HMAC to pass a string to be verified. Is this secure

I am working on a django project and trying to create a REST api to verify email without using any database.

My present server connection is HTTP and not HTTPS

So some one using the api end point POST his email.

REQUEST:  curl --location --request POST '' \ --header 'Content-Type: application/json' \ --data-raw '{ "email":"", }' 

Now i am generating a random 6 digit number eg: 435667 and an email will be sent to

send_mail('PIN TO VERIFY','ENTER THE PIN 435667',None,[]) 

Send the HMAC value of 435667 as a response to this api

    raw = '435667'.encode("utf-8")     key = 'SOME_SECRET_KEY'.encode('utf-8')     hashed =, raw, hashlib.sha1)     pin_hmac_hash = base64.encodebytes(hashed.digest()).decode('utf-8')     eg: pin_hmac_hash = "SOME_HMAC_HASH_OF_PIN" 

So the response for /api/openlogin will be

{ 'email': '' 'pin': "SOME_HMAC_HASH_OF_PIN" } 

Now the user sends me back the pin along with the HMAC hash in the response

curl --location --request POST '' \ --header 'Content-Type: application/json' \ --data-raw '{ 'pin': "SOME_HMAC_HASH_OF_PIN", 'email': '', 'emailed_pin':'435667' }' 

Will someone guess the pin from SOME_HMAC_HASH_OF_PIN.

Ofcourse i will further try to autenticate the api using JWT token. So the email cannot be tampered

This is an example of PIN but it can be any string of sensitive information. Can i rely on hmac

I am signing (HMAC) outgoing webhooks to allow users to verify their source, should I also sign outgoing responses?

To allow api users to verify the authenticity of outgoing webhooks, I am using a similar model to slack:

  • Concatenate timestamp and body, HMAC with pre-shared key, add timestamp and HMAC digest to headers.

  • Recipient does the same, and compares to the digest in the header.

I can either implement this exclusively on outgoing webhooks, or I can implement it as middleware that performs this process on both outgoing webhooks, and responses to requests.

Is doing the latter good practice? A good idea?

Is an index, nonce and HMAC good enough for session management?

I’m researching session management for web applications. I’ve been looking at a couple places, and from my understanding is we shouldn’t use a secret as a session identifier(index). Because it can lead to timing attacks.

Let’s say for the sake of performance sessions on the server-side are stored in cache/memory. And the index is reset(e.g: starts back at 1) every time the server restarts or they are all purged.

session_payload = index || HMAC(server_key, index) 

But doing it like that would leave room for replay attacks, right? An attacker could generate a bunch of session payloads and store them for later to hijack sessions. Something is needed to make each session payload unique to prevent that, right?

So what about:

payload = index || nonce session_payload = payload || HMAC(server_key, payload) 

If my understanding is correct, the nonce just needs to be unique to make the session payload unique. Should it be just the output of a CSPRNG, RNG or the current time(milliseconds?, nanoseconds?)? What are the caveats of each?

So if the above is done right, it should be able to avoid:

  • Timing attacks.
  • Volume attacks.
  • Replay attacks.*
  • Tampering.

Right? And is there any other attacks I should be aware of? Please exclude session fixation, that can be mitigated via session payload regeneration on privilege escalation.

  • What I define by a replay attack, is adversaries could store pre-computed session payloads and hijack sessions later, hence the use of the nonce.

Can the username be used in HMAC during client-side hashing?

I am very new to authentication and cybersecurity in general, so I apologize if I have anything completely wrong.

My goal is to have the client side hash passwords before sending them to server side in order to protect users using the same password on multiple sites. For the sake of this question, assume server-side is secure (in my case, the hashed passwords from client-side are hashed again with Argon2 and then stored in the database). I understand that this provides no security benefit for users on my app and that other things such as SSL are much more important for keeping passwords secure in transit, but I’d still like to do this just in case.

I was planning on using SHA256 but heard that rainbow tables are a major security threat. Would using the username as the key in an HMAC hash mitigate that? Moreover, are there any better ways of protecting users who reuse passwords on multiple sites? Keep in mind that I can’t use a salt because the resulting hash has to be consistent between logins when given the same username/password combo, and I can’t use a secret key because it’s client-side.

Swift HMAC doesn’t match NodeJS HMAC, but only sometimes!

I have discovered a HUGE issue in my code, and I have literally no idea what is causing this.

SO, when I send requests to my server I hash a string thats in the request. This is sometimes user input.

My app is multi language so I have to support all “ä” chars etc.

So with the normal english letters/chars numbers etc, this hashing method works like a dream. BUT when the string being hashed and compared contains a “ä” or a “ö” (Not specifically those, it literally might be that any char not in the Base64 set will cause this) the hash doesn’t match!

This is an absolute and complete disaster, and I have not noticed it this far. I have tried basically everything I know to try to fix this, and googling, and I am out of luck so far.

I generate the hash in Swift inputting the string and secretToken into this function and saving the output as a HTTP header:

func hmac(string: String, key: String) -> String {      var digest = [UInt8](repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))      CCHmac(CCHmacAlgorithm(kCCHmacAlgSHA256), key, key.count, string, string.count, &digest)      let data = Data(digest)      return { String(format: "%02hhx", $  0) }.joined()  } 

How I compare the hash in NodeJS:

if (hashInTheRequest === crypto.createHmac('sha256', secretToken).update(stringToHash).digest('hex')) {     //Good to go } 

Thanks in advance!

Is HMAC required when using TLS communication?

We have SSL communication between our mobile app and our servers.

The request from mobile is creating a hash on all the request fields – based on a secret key which is “stored” on the app.

So it sends json with all the fields data, plus a signature value which is :

hash = hashBasedOnKey ( all request data fields) 

Later, the server does the same thing. It reads the fields and run hash on those fields ( server also has the secret key) and if the hash are the same , then it means that the data was not altered.


Is it really needed when using SSL communication ?

A MITM can’t alter the data , except for SSL stripping. But again, the mobile app uses SSL communication.
IMHO – ssl stripping is when non ssl “thinks” it connects to ssl , without noticing, where the MITM does the SSL by itself to the destination, and strip the https data , and return the http data.


Is hashing the data in the client, crucial? or is it useless?

Can I securely share an HMAC key over a TLS connection?

In a game client/server that I’m developing, I want to allow a user to authenticate over TLS (via a REST endpoint on an HTTPS server) before dropping to an unencrypted low-latency UDP protocol. To prevent spoofing and replay attacks, the UDP protocol uses a SHA-256 HMAC and a nonce in each packet.

I want to make sure that the shared secret used as the HMAC key is secure. Not being a security expert, my first thought is to use a secure RNG to generate the secret at the server, then send it to the client over the TLS connection. Is this approach secure, or is this somewhere that I should be wary of “rolling my own crypto”? And if it’s insecure, am I better off using e.g. libsodium’s key exchange APIs? Or is this second key exchange (after the key exchange that happens when the TLS connection is established) redundant?

Using HMAC for storing low-entropy input data (e.g. SSN)

I am looking for a solution to storing SSNs in a secure way in a database. The following references are related:

  • How to safely store sensitive data like a social security number?
  • HMAC – Why not HMAC for password storage?

Especially the second reference was an interesting read. However, I would like some other inputs on the security of this system. Social security numbers (in my country, at least) can easily be enumerated since they have a fixed format. I could therefore create an exhaustive list of all possible social security numbers, and it would be a pretty small list (let’s say, 70 million). Also, accessing these SSNs must be fast, and happens all the time.

For these two reasons (limited amount of SSNs, access must be fast) I doubt that using default password hashing algorithms such as bcrypt, scrypt, argon-2 is the way to go.

The HMAC option is appealing to me, since it is fast, and the security of the system depends on the security of the secret key. Keeping this key secure is of course not easy, but feasible. Also note that all SSNs are unique, so there will never be duplicate outputs.

Is using HMAC for storing social security numbers in this case the way to go, or are there better alternatives?