0
$\begingroup$

I have come across some security implementations in which party A will compute MD = sha256(secret + rand) and transmit MD and rand to a counterpart B. If the second party knows the secret, then when it computes sha256(secret + rand), it will match that from sender A and validate it.

This may be a loaded question, but is this secure at all? Meaning, would it be very hard for an attacker to discover the secret given the resultant hash and the random number?

Part 2: Another potentially loaded question Would it be more/less secure to instead use an hmac using the secret as the 'data'? So HMAC(rand, secret) ?

The goal of both security systems is to ensure that both A and B possess the same key K without transmitting it, but is either more secure? Are these implementations 'traditional' or more of a 'cluge'?

Improve this question
$\endgroup$
3
$\begingroup$

Using HMAC is more principled and flexible here, because HMAC with a random secret key is a pseudorandom function, while sha256(secret + nonsecret) isn't.

In your case where the non-secret is a random value there might not be a security difference. But I mentioned also flexibility, because this sort of authentication scheme—when implemented with a proper pseudorandom function like HMAC—doesn't need a random value. A counter or wall clock time will do. In fact, if you've seen those two-factor authentication tokens or apps that display a six-digit code that changes every minute, those are based on the TOTP algorithm, which is basically hmac(secret, current_time / refresh_interval).

Improve this answer
$\endgroup$
  • $\begingroup$ So, the HMAC is more suited for this, and from what you're saying is that instead of a random number you could/should use a timestamp, so it means a bit more. Maybe you can use it to ensure that the code was not intercepted and re-transmitted at a later date? Like the 2 factor rolling codes $\endgroup$ – Code Wiget Feb 21 '18 at 23:03
  • $\begingroup$ I'm not saying you should use a timestamp, only that you could. It would, for example, save you the overhead of transmitting the rand value along with MD, by using instead a changing value that is predictable to both parties A and B at the time the authentication happens. The use of a proper MAC guarantees that it's not a problem that the timestamp is also predictable to an adversary. While in the scheme you describe, we appear to be relying on the fact that the rand values are unpredictable to adversaries. $\endgroup$ – Luis Casillas Feb 22 '18 at 23:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.