A MAC is calculated the following way:
mac = sha1(secret || m)[0:8]
[0:8] denotes taking the first 8 characters from the resulting hash.
The length of the secret is unknown. Users (and potential attackers) can check the validity of a particular MAC and message pair online.
if(macInput == sha1(secret || m)[0:8]){
// ok
}else{
// access denied
}
Can this be attacked? I heard it can, but I don't see why and how.
OK, there are two issues with this:
First, the MAC length is at most 64 bit, that is an attacker could try to brute-force-find a valid MAC with "merely" $2^{64}$ submissions, which is border-line feasible for large companies today.
If it actually only is 8 hex character, then each hex character encodes at most 4 bits of information and thus you get $8\cdot 4=32$ bits for the MAC security meaning brute-force would take at most $2^{32}$ (around 4bn) tries to recover a valid MAC.
Second, much more severe is the naive verification of the MAC which will probably allow for a classic timing side-channel attack.
Chances are that this multi-byte equality verification is implemented as an "optimized" check, that is (in a python-ish way):
if len(lb)!=len(rb):
return false
for (lb,rb) in zip(l_input,r_input):
if lb != rb :
return false
return true
Which checks the that the input lengths match and then pairs all the bytes at the same position in both inputs and outputs false as soon as a miss-match is detected and true if no missmatch is found.
Now what we can do is to measure the time it takes to verify our MAC. So we would start of with 7 0 characters and prepend each possible value (character) value to this string. We send all to verification. The one that takes longest has a match on the first character. Now we fix this first character that we just verified and continue with the second with the same method. We continue with this process until we have recovered the full MAC and get access in return.
If we get all-equal times for the first character, we take iterate over all possible choices for the first two characters (enlarge as needed). If we know the size of the information $b$ (in bits) encoded in the constant-time verification data structure (eg 8 for byte-wise, 32 for integer-wise, ...) and we know the mac information $l$ in bits, then we take at most the following amount of calls to the verification oracle to recover the valid MAC:
$$n=2^b\cdot(l/b)$$
If in your case 8 hex characters need to be verified this becomes $2^4\cdot 8=256$ calls to the verification oracle (because the effective information of the hash is 32 bits composed of 4 bit elements).
I will generalize the question somewhat:
Section 3.4 of Coron, Dodis, Malinaud and Puniya's 2005 paper on hash function constructions describes the chop-MD construction, where messages are hashed with a Merkle-Damgård hash function like MD5, SHA-1 or SHA-2, but the last $s$ bits of the digest are dropped. They give a result that this construction is random oracle indifferentiable, with a security level determined as a function of $s$.
Since random_oracle(key || msg) is a secure MAC construction, in principle the construction you propose could be used to construct a secure MAC, if chop-MD's full requirements are met. But this can't be accomplished with SHA-1, because the problem is that the numbers matter: for chop-MD to be secure, you need a sufficient number of both chopped and unchopped bits, and SHA-1's 160-bit output just ain't big enough to satisfy these conditions. Quoting the authors:
While really simple, the drawback of this method is that its exact security is proportional to $q^2 2^{−s}$, where $s$ is the number of chopped bits and $q$ is the number of oracle queries. Thus, to achieve adequate security level the value of $s$ has to be relatively high, which means that short-output hash functions such as SHA-1 and MD5 cannot be fixed using this method. However, functions such as SHA-512 can naturally be fixed (say, by setting $s = 256$).
So, for example, mac = sha512(key || msg)[0..32] (32 bytes of the binary output of SHA-512; that would be 64 hex digits) should be a secure MAC. In your SHA-1 based proposal, the chop size $s = 128$ is uncomfortably small; but of course because your MAC tag size $160 - s = 32$ is tiny, you can't afford to pick a bigger $s$, you just don't have the headroom.
Note also that:
