Why does Google still use SHA-1 for securing API keys if its been compromised?

Question

If you read Google's best practices for use account you'd see them warning against using SHA-1. They have even purposefully cracked it in 2017.

If that's the case, then why when you restrict google cloud API keys for android apps, you use a SHA-1 fingerprint of your android app? Seeing as how its trivial to fake a package name (the other required detail to identify your app) you're only left with a security method thats been already cracked.

Why would Google secure such an important thing as an API key with a hashing algorithm that they warn against?

I have searched an answer for this on the web, and while there are some answers that deal with this topic, none specifically deals with the dissonance google has shown.

Answer 1

Im summary: SHA-1 has various use cases and while some are considered broken others are not.

You are mixing apples and oranges:

... them warning against using SHA-1.

They advice against SHA-1 to be used as hash in storing passwords. But this is not specific to SHA-1, it is even a bad idea to use SHA-2 for storing passwords. See also How to securely hash passwords?.

They have even purposefully cracked it in 2017.

They have shown a collision attack. This is not "cracked" in the general sense but it shows a specific weakness and affects only use cases where collision attacks can be a problem.

... then why when you restrict google cloud API keys for android apps, you use a SHA-1 fingerprint of your android app? Seeing as how its trivial to fake a package name (the other required detail to identify your app) you're only left with a security method thats been already cracked.

If you want to reuse an API key which belongs to the app of another party then you have to mount a pre-image attack and not a collision attack. Pre-image attacks against SHA-1 are not feasible so far.