Hot answers tagged hmac
34
(Note: using a salt is only half of the job; you also need to make the hash function slow -- so that attacking a single low-entropy password is still difficult. Slowness is usually achieved through multiple iterations, or hashing the concatenation of 10000 copies of the salt and password.)
What your "pepper" does is that it transforms the hash into a MAC. ...
8
HMAC is a Message Authentication Code, which is meant for verifying integrity. This is a totally different kind of beast.
However, it so happens that HMAC is built over hash functions, and can be considered as a "keyed hash" -- a hash function with a key. A key is not a salt (keys are secret, salts are not). But the unique characteristics of HMAC make it a ...
8
Modern browsers do the smart thing: they ask the operating system. The OS interacts with hardware all day long; that's its main purpose. So it is in the right place to gather randomness and mix it with a properly secure cryptographic random number generator. On Windows systems, this is made available to application though the CryptGenRandom() function. Linux ...
7
Encryption, or a deterministic MAC, may offer you an extra gain of security on the off-chance that the attacker could grab the database of hashed-and-encrypted passwords but not the encryption/MAC key (which the same server must necessarily know to do his job). Some people call that "pepper" (as a pun with the notion of "salt" -- IT security people are a ...
6
If the hash function is a Random Oracle then hashing the concatenation of the key (your "secret salt") and the message is indeed a perfect MAC (I say "key" because if a salt is a secret piece of data then it matches the definition of a key; let's use the proper name).
Unfortunately, random oracles do not really exist... instead, we are stuck with hash ...
6
You should avoid the "weak" cipher suites:
Cipher suites with no encryption (with a NULL in the name).
Cipher suites with 40-bit or 56-bit symmetric keys (DES, DES40, RC4_40, RC2_CBC_40)(3DES is fine, though).
Cipher suites marked "for export" (with EXPORT in the name: they are weakened to comply with pre-2000 US export regulations).
Cipher suites with no ...
6
Rfc2898DeriveBytes implements PBKDF2: a function which turns a password (with a salt) into an arbitrary-length sequence of bytes. PBKDF2 is often used for password hashing (i.e. to compute and store a value which is sufficient to verify a password) because it has the needed characteristics for password hashing functions: a salt and configurable slowness.
...
5
The MAC is there to detect alteration of the data you are interested in, i.e. the result of the decryption. So you have the following choice:
either you compute HMAC over the plaintext data (i.e. before encryption when encrypting, after decryption when decrypting);
or you compute the HMAC over the encrypted data itself (i.e. after encryption when ...
5
HMAC/SHA-1 is not broken. SHA-1 has a weakness with regards to collisions (and it is still "theoretical" since producing a collision for SHA-1, though conceptually easier than the generic attack, is still so expensive that nobody has computed one such collision yet). But HMAC resistance does not rely on resistance to collisions.
Indeed, HMAC is proven ...
5
It doesn't prove that you initiated the transaction. It may be evidence, but not proof that you initiated the transaction.
Read up on non-repudiation, as explained elsewhere on this site: e.g., How to achieve non-repudiation? and What is the difference between authenticity and non-repudiation Those pages will explain the many limitations and challenges of ...
4
Recommended approach. I recommend that you use SSL and authenticate the client using their password. Then you won't need any fancy MAC, hash, PBKDF2, etc.
Details. You asked how to authenticate the user. Here is a simple approach. Use SSL sitewide. When the user logs in (entering their password in via a web client), then set a session cookie that ...
4
I'm not sure if i understand your problem entirely.
The salt is usually encoded in the bcrypt string representation.
However using the username as salt probably won't work as bcrypt expects exactly 16 bytes as salt. So you'd need to transform the username before.
What i don't understand is, why can't both sides have the salt? As you said, the salt is only ...
4
It really depends on what security feature you want to achieve. Each pair "m,HMAC(k, m)" provides integrity in the following sense: the adversary will not be able to forge a pair declared valid by the receiver, that the sender did not compute in the first place.
You may want additional properties, though. For instance, you have a sequence of messages, and ...
4
The SHA2 family is not a good choice for password storage. It is significantly better than md5, but really you should be using bcrypt (or scrypt!).
RNGCryptoServiceProvider is a good source of entropy. Ideally a salt is not base 64, but base 256, as in an entire byte. To understand this better, you need to know how rainbow tables are generated. The ...
3
The approach you're asking about is also known as a length extension attack, and HMACs are explicitly not susceptible to these kinds of attacks.
Given HMAC(K, m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m)), the best you can do is precompute
Ko = K ⊕ opad
Ki = K ⊕ ipad
m'0 = Ki ∥ m0
m'i = m'i-1 ∥ mi
HMAC(K, mi) = H(Ko ∥ H(m'i))
which doesn't actually save you ...
3
HMAC is designed to be very fast and is in this context a good way to add salt to password instead of just appending it. Bcrypt is much slower due to slow initialization, while scrypt is even slower than Bcrypt because it is intentionally designed in such a way. Scrypt is designed to make brute forcing it very computationally expensive. It consumes a lot of ...
3
The most important thing you should be doing is: use SSL. Use HTTPS, not HTTP.
Justification:
If you use SSL, your approach is reasonable.
Tactical detail: I suggest using PBKDF2 with a large iteration count to generate the HMAC key from the password. You can use a fixed value (or a hash of the username) as the salt.
This will admittedly have some ...
3
The paper on the invention of salting and iterations, for Unix passwords (Password Security: A Case History, Morris & Thompson, 1978), also described the equivalent of a pepper:
The first eight characters of the user’s password are used
as a key for the DES; then the algorithm is used to encrypt a constant. Although this constant is zero at the
...
3
See HOTP, section E.4. This is reasonably well explained. The gist of the solution: when the counter on the server contains n, the server actually accepts as valid the one-time passwords corresponding to values n, n+1, n+2... up to (say) n+99. If what the client sent matches the one-time password for value n+37, then the client is accepted, and the new ...
3
The key used in HMAC is, by definition, symmetric: the same key is used to compute the MAC value, and to verify the MAC value. Digital signature algorithms are asymmetric, which means that the key for verification is distinct from the key used for generation; this "difference" is strong: the key used for generation cannot be recomputed from the key used for ...
2
I would like to point out what a pepper really can do.
When does a pepper help?
As the others already pointed out, adding a pepper is only an advantage, as long as the attacker has access to the hash-values in the database, but has no control over the server, and therefore does not know the pepper. This is typical for SQL-injection, probably one of the ...
2
HMACS are used when you need to check two "integrity" and "authenticity". For eg: consider a scenario where you are sent a piece of data along with its hash -- you can verify the integrity of the message by recomputing the hash of the message and comparing it with the hash that you received. However, you don't know for sure if the message and the hash was ...
2
I working also on a webservice sessionless authentication.
Check also amazon s3 auth.
They also do HMAC_SHA256 to "sign" the request with a timestamp.
But it's no strong over http (non ssl) because someone could sniff your request.
Amazon works agains that by only allow request with timestamp within +/- 15 min of the amazon server time.
Of course they ...
2
Short answer:
Kind of, but not really. A salt is simply random data added to the message before it is hashed, with the object of making the hash produced by a salted message different from anything an attacker may have already computed on his own with the same but unsalted message (or with any other salt, for that matter). Usually, salts must be public, in ...
2
If you don't know the key, you can't generate the HMAC. That's the whole point of a HMAC - it's a quick way to provide message integrity using existing key material. If you could regenerate the HMAC without the key, an attacker could simply generate a HMAC for a different message and alter the payload.
2
Combining MAC and encryption is hard. Depending on how you do it, the result will be secure, or not, or only "mostly secure" modulo a zillion of implementation details. GCM is an Authenticated Encryption mode which does all the hard work for you, so it is warmly recommended that you use GCM (or an equivalent mode like EAX) instead of designing your own ...
2
Typically the solution for this is either to a) check it against the values going forward several to see if this occurred and increment accordingly if it is found to have drifted ahead. (This is how time based tokens account for clock drift.) or b) if the systems can interact, do an exchange of the current counter value on both systems. They can agree on ...
2
If you do your protocol over plain HTTP, then attackers meddling with the communication may drop, duplicate or reorder requests, within your time frame. They may also send to the client (respectively the server) some of its own requests as if they were responses from the server -- depending on your protocol, this may or may not be a problem, but it could be ...
2
Technically, HMAC is a MAC, not a signature. Some people get the terminology wrong (in particular Microsoft's documentation) and call HMAC a signature, but things are clearer if you use the right words.
HMAC, when used with a secure hash function (say, SHA-256, but SHA-1 is fine too), is resistant to forgeries; that is, the attacker cannot succeed in ...
2
Theoretically, MAC algorithms may reveal part of their input data, because confidentiality is not part of their root characteristics. In practice, though, HMAC is safe for that. Similarly, a hash function does not reveal much about its input because it would make it more vulnerable to preimage attacks, and good hash functions are strong against that.
If you ...
Only top voted, non community-wiki answers of a minimum length are eligible
