SHA-1 and HMAC are not broken by brute-force
In a real-life scenario, let's calculate the minimum HMAC key length that would take more than 10 years (315,360,000 seconds) to break. Using eight Nvidia GTX 1080s as a theoretical baseline (see this performance sheet), it is possible to generate about \(6.87 \times 10^{10}\) SHA-1 hashes per second.
By approximating — HMAC performs two SHA-1s and one XOR, so ~0.5× the SHA-1 throughput — let \(k\) be the key length in bits. The number of possibilities is \(2^k\), with an average of \(2^{k-1}\) keys tested before recovery:
\(k\) is around 64 bits — an 8-byte string. This means a common password could be broken, but the recommended 20 bytes for an HMAC key are safe. Breaking SHA-1 directly takes half the time.
SHA-1 is vulnerable to collision
Brute-force is not the real threat. In 2017, Google demonstrated how to collide two SHA-1 hashes — the SHAttered attack — at a cost of approximately $130,000, exploiting the birthday paradox.
The SHAttered attack — Google, 2017
In May 2019, French and Singaporean researchers found a way to reduce the number of tries needed for a chosen-prefix collision:
We are currently working on further improvements (unpublished yet), and we evaluate now that one can find a chosen-prefix collision for SHA-1 with a budget of less than $100,000, which is really practical.
HMAC is still OK
First SHA1 was shattered. Now it's reduced to shambles. It's time to stop using SHA1. (HMAC-SHA1 is still okay.)
The compression function of HMAC successively applies several SHA-1s. The ability to create SHA-1 collisions does not predict the output of an HMAC. A much deeper break of SHA-1's round function would be needed. M. Bellare's paper New Proofs for NMAC and HMAC: Security without Collision-Resistance shows that the security of HMAC holds assuming only weaker properties on its round function than needed for collision resistance of the underlying hash.