Is HMAC really a benefit for AES-CBC?

I think I quite well understand the theoretical benefit of adding the HMAC (authenticity/integrity on top of confidentiality), but I am looking at this from a key management point-of-view.

Premise: Since anyone could in theory encrypt plain text, I add a MAC tag so the ciphertext origin can be verified. This derives the premise:

  • A malicious party could gain access to the secret shared encryption key and forge a cipher text

Then I argue, if an attacker can access the encryption key, why should he/she not be able to access to MAC key as well (and thus again be able to forge a cipher text)? Next, if we increase the key storage requirements for the MAC key (making its compromise less likely), why not simply store the encryption key more securely in the first place?

In my eyes, this method is adding two very similar security concepts together (shared symmetric secret key), which doesn’t magically increase the security, i.e., 1+1 does not always equal 2 in security.

If someone could briefly explain the error in my chain of thought or shed some light on this matter I would highly appreciate it.

Thanks in advance!

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 'http://127.0.0.1:8000/api/openlogin' \ --header 'Content-Type: application/json' \ --data-raw '{ "email":"test13@test.com", }' 

Now i am generating a random 6 digit number eg: 435667 and an email will be sent to test13@test.com

send_mail('PIN TO VERIFY','ENTER THE PIN 435667',None,[test13@test.com]) 

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 = hmac.new(key, 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': 'test13@test.com' '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 'http://127.0.0.1:8000/api/verifypin' \ --header 'Content-Type: application/json' \ --data-raw '{ 'pin': "SOME_HMAC_HASH_OF_PIN", 'email': 'test13@test.com', '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 data.map { 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.

But

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.

Question:

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?