What is HMAC?<\/p>\n
HMAC stands for Hash-Based Message Authentication Code. It’s a specific way to use a cryptographic hash function (like SHA-1, SHA-256, etc.) along with a secret key to produce a unique “fingerprint” of some data. This fingerprint allows someone else with the same key to verify that the data hasn’t been tampered with.<\/p>\n
How HMAC Works<\/p>\n
Keyed Hashing: The core idea is to incorporate the secret key into the hashing process. This is done in a specific way to prevent clever attacks that might try to bypass the security.
\nInner and Outer Hashing: HMAC uses two rounds of hashing. First, the message and a modified version of the key are hashed together. Then, the result of that hash, along with another modified version of the key, are hashed again. This two-step process adds an extra layer of protection.<\/p>\n
HMAC in OpenSSH<\/p>\n
OpenSSH uses HMAC to ensure the integrity of messages sent back and forth during an SSH session. This prevents an attacker from subtly modifying data in transit.<\/p>\n
HMAC-SHA1 with OpenSSH: Is it Weak?<\/p>\n
SHA-1 itself is considered cryptographically broken. This means that with enough computing power, it’s possible to find collisions (two different messages that produce the same hash). However, HMAC-SHA1 is generally still considered secure for most purposes. This is because exploiting weaknesses in SHA-1 to break HMAC-SHA1 is much more difficult than just finding collisions in SHA-1.<\/p>\n
Should you use it?<\/p>\n
While HMAC-SHA1 might still be okay for now, it’s best practice to move to stronger alternatives like HMAC-SHA256 or HMAC-SHA512. OpenSSH supports these, and they provide a greater margin of safety against future attacks.<\/p>\n
In Summary<\/p>\n
HMAC is a powerful tool for ensuring data integrity. Even though SHA-1 has weaknesses, HMAC-SHA1 in OpenSSH is likely still safe for most users. However, to be on the safe side and prepare for the future, switching to HMAC-SHA256 or HMAC-SHA512 is recommended.<\/p>\n
Following are instructions for creating dataproc clusters with sha1 mac support removed:<\/p>\n
I can appreciate an excess of caution, and I can offer you some code to produce Dataproc instances which do not allow HMAC authentication using sha1.<\/p>\n
Place code similar to this in a startup script<\/a> or an initialization action<\/a> that you reference when creating a cluster with gcloud dataproc clusters create<\/a>:<\/p>\n If this code is hosted on GCS, you can refer to it with <\/p>\n or<\/p>\n\n#!\/bin\/bash\n# remove mac specification from sshd configuration\nsed -i -e 's\/^macs.*$\/\/' \/etc\/ssh\/sshd_config\n# place a negative MACs specification in the \/etc\/ssh\/sshd_config.d\/ config directory\nmkdir -p \/etc\/ssh\/sshd_config.d\nssh -Q mac | perl -e \\\n '@mac=grep{ chomp; \/sha1\/ }--initialization-actions=CLOUD_STORAGE_URI,[...]<\/pre>\n
--metadata startup-script-url=CLOUD_STORAGE_URI,[...]<\/pre>\n\n