Hot answers tagged

82

HMAC is a computed "signature" often sent along with some data. The HMAC is used to verify (authenticate) that the data has not been altered or replaced. Here is a metaphor: You are going to mail a package to Sarah which contains a photograph. You expect her to open the package and view the photograph. At some point in the near future you expect her to send ...


59

Yes, HMAC is more complex than simple concatenation. As a simplistic example, if you were to simply concatenate key + data, then "key1"+"data" yields identical results to "key"+"1data", which is suboptimal. HMAC will yield different results for each. There are other flaws with simple concatenation in many cases, as well; see cpast's answer for one. The ...


53

The short answer is "HMAC provides digital signatures using symmetric keys instead of PKI". Essentially, if you don't want to deal with complexities of public/private keys, root of trust and certificate chains, you can still have reliable digital signature with HMAC. HMAC relies on symmetric key cryptography and pre-shared secrets instead of private/public ...


51

I've added my answer here as I feel the existing ones don't directly address your question enough for my liking. Let's look at RFC 4868 (regarding IPSec, however it covers the HMAC-SHA256 function you intend to use - em mine): Block size: the size of the data block the underlying hash algorithm operates upon. For SHA-256, this is 512 bits, for SHA-384 and ...


43

AES is encryption; it is meant to maintain confidentiality. Encryption does not maintain integrity by itself: an attacker who can access encrypted data can modify the bytes, thereby impacting the cleartext data (though the encryption makes the task a bit harder for the attacker, it is not as infeasible as is often assumed). To get integrity, you need a MAC, ...


32

There's actually a very big problem with SHA256(key||data): SHA-256, along with SHA-512, SHA-1, MD5, and all other hashes using the Merkle–Damgård construction, is vulnerable to a length extension attack: given H(x), it's very simple to find H(x||y), even if you only know the length of x, because of how the construction works. (Essentially, the construction ...


25

It allows for the potential of an existential forgery. An attacker can create a valid HMAC for a chosen message without knowing the HMAC key. Basically, the way the attack works is this: The attacker sends a message, and an HMAC (really just a sequences of bytes the same length as the HMAC) and times the response from the decryption system. The ...


23

According to RFC 7518 - JSON Web Algorithms (JWA): A key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with this algorithm. (This requirement is based on Section 5.3.4 (Security Effect of the HMAC Key) of NIST SP 800-117 (sic) [NIST.800-107], which states that the effective security strength is ...


18

I created the Node Scrypt module. HMAC adds additional security. Using it also lends the scheme to be used as a header in an encrypted file format (like it is done in tarsnap) and not just in an authentication server's database. Also, Colin Percival (who created scrypt) uses this scheme to verify (I actually just copied it from him). To explain why HMAC is ...


17

The risk is that an attacker can forge data. In other words, they can come up with their own ciphertext and then figure out the expected HMAC to make your system accept the input as valid. The whole point of the HMAC is that only you as the owner of the key can “sign” data. However, if the application leaks information about the expected HMAC of the input, ...


15

Looking at OpenVPN's source code, this appears to be a cosmetic quirk of OpenSSL. When using --show-digests, OpenVPN calls OpenSSL's EVP_get_digestbynid() with, as parameter, all integers from 0 to 999. For some of these values, EVP_get_digestbynid() returns a non-NULL pointer that identifies the corresponding hash function implementation, and then OpenVPN ...


13

Important Disclaimer: I wrote CipherSweet for my employer. Everything that follows should be taken with a grain of salt unless otherwise verified by third party security experts. Even if this answer gets a lot of votes, it must never be accepted. I'm merely attempting to answer some of the basic questions about CipherSweet's design, not answer whether or not ...


12

Nope Generally speaking: No. Hashing is not encryption. Hashing is not reversible. At all. It always generates a fixed length output. So with an output fixed to say 32 characters, and an input of 33 characters, there is no possible way to reverse this. The information of that one character is irretrievably lost. -- And along with it all other characters. ...


12

The RFC 2104 defining HMAC functions answers this question: The key for HMAC can be of any length (keys longer than B bytes are first hashed using H). However, less than L bytes is strongly discouraged as it would decrease the security strength of the function. Keys longer than L bytes are acceptable but the extra length would not significantly increase ...


12

HMAC is used to protect against manipulation by someone who has not access to the secret. Typically this means to protect against manipulation by the client if the secret is only known to the server or to protect against manipulation in transit if the secret is known to client and server. An RSA based signature is used to protect against manipulation and ...


11

"Shared secret" in this case typically means between multiple servers, not between the client and the server. Typically, JWTs can be done using symmetric encryption - in which case all servers that need to verify the token need to have the shared secret - or asymmetric encryption, in which case only the server actually doing the authentication needs to have ...


11

I think you're not too far from a possible solution (aka using a modern KDF and effectively treating this like a password). However, there are some more considerations (which were already mentioned in comments): SSNs have very low entropy, which means that brute-force is an especially easy attack Since you need to find if the SSN has been used anywhere, ...


10

I'm responding in specific to the EDIT of lessons learned in the original question. Rfc2898DeriveBytes is called with 1000 iterations. using 1024 byte output. The password size in Db was designed 2k fortunately. Average sample in tests on workstations was around 300 msecs Quick summary: If you like your current CPU load and Rfc2898DeriveBytes, then ...


9

MACs are used all the time. Any time you want authenticated encryption, that is you want to send messages that can't be tampered by an attacker who lacks your secret key, you need to apply a MAC to every message you send as well as check a MAC for every message you receive. Examples that I use on a daily basis include: TLS (formerly known as SSL) used in ...


9

Just a BTW, the new NIST Digital Idendity Guidelines (Draft) strongly recommend to use Pepper as well: https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 5.1.1.2 Memorized Secrets Verifier: ... A keyed hash function (e.g., HMAC [FIPS198-1]), with the key stored separately from the hashed authenticators (e.g., in a hardware security module) SHOULD be ...


8

Overall, I would recommend HMAC unless you have particular requirements for client certificates. The reasons are: Expiry While it is true that there is no mandatory expiry with HMAC, in reality, you should expire any kind of password/secret/encryption key on a regular basis. This is enforced by certificates but you should do it as a matter of policy for ...


8

For preventing interception and reading of the secret content, encryption algorithms like AES are used. HMACs do not matter at all for this part. Assuming AES (CBC etc.) is secure, an attacker could still intercept what you're sending or receiving, but he can't read it. What he could do, however, is to change the data to something else. Again assuming AES ...


8

From RFC 2104 § 6 describing the security requirements for an HMAC: The security of the message authentication mechanism presented here depends on cryptographic properties of the hash function H: the resistance to collision finding (limited to the case where the initial value is secret and random, and where the output of the function is not explicitly ...


7

SSL already provides a secure connection which protects data in transit between client and server. It ensures confidentiality and integrity, and, indeed, uses HMAC for the latter. If your security model is about attackers who might try to alter messages while they travel from the client to the server and back, then adding your own HMAC is redundant and ...


7

Per the Yubikey FAQ they state the following: ..."All YubiKey NEO devices manufactured as of February 10, 2015 supported the current FIDO U2F specification for NFC. To verify you have a YubiKey NEO that supports NFC, check to see your YubiKey is running firmware version 3.4.0 or later."... Likewise, the YubiKey 4 (v4) and Neo (v3) are also listed as ...


7

Performance alone is a reason to use MAC. Consider a TLS connection. For every packet, the receiving party needs to verify that the packet wasn't modified in transit by a man-in-the-middle attacker. So for every packet, the sender needs to calculate a MAC/signature and the receiver needs to verify it. If you want, say, a 10MB/s transfer rate and an average ...


7

The master key must be a sufficiently long, randomly-generated key. It must be at least 16 bytes generated uniformly at random (not 16 random printable ASCII characters and definitely not a human-chosen password or passphrase). Otherwise it would be possible to find the master key from any of the derived passwords. This means that the master key is not ...


6

I see various issues with your approach (in no particular order, and most likely not a complete list): It seems like you're deploying the application without SSL/TLS. If that is the case, you must not rely on the client side, as a MITM can replace your (secure) client-side implementation with anything he/she chooses. There is no way to create a secure web ...


6

Technically, PBKDF2 can produce an arbitrary long output (it is a Key Derivation Function), but it has issues for that: PBKDF2 uses HMAC over some hash function, which has output length k bits (e.g. k = 160 for the usual SHA-1). If you ask for more output than that size, then the computational cost rises quickly: if you want 320 bits, it will cost twice as ...


6

Perhaps it's also important to point out the breaches that have occurred where there was no evidence of compromised data. LastPass, for example, used "5,000 rounds of PBKDF2-SHA256" and a random salt (https://blog.lastpass.com/2015/06/lastpass-security-notice.html/). Since the breach, there have been no indications that the master passwords were broken. ...


Only top voted, non community-wiki answers of a minimum length are eligible