Here is the scenario:
- "SECRET" is a secret key that is kept private and only used in this one application.
- The application allows users to enter in any "VALUE" (within various open-ended limits such as numeric > 50, max length 20, etc... depending on the field)
- The application creates an HMAC-SHA2-256 "HASH" from VALUE and its field name using SECRET as the key
- HASH is displayed to the user
"CONTROL" (comparison) scenario:
- Only a certain number of field VALUEs and their corresponding HASHes are shown to users
- Users cannot input additional VALUEs to see the corresponding HASHes
Other information:
- The HASHes are used to prevent the VALUEs from being changed while being sent to a third party application.
- If a user tries a HASH with a corresponding field name and VALUE, either it works or an error message comes up.
- There are no limits or precautions against automated testing other than network speed.
Real-life application (not necessary for the question):
- The hashes are used as an easy (==low cost) alternative to IPN validation for products sent to FoxyCart, a Javascript-powered secure checkout.
- The hashes prevent a user from spoofing exact values but cannot handle complex conditions such as minimum and maximum values of a user-chosen option. For such situations, FoxyCart provides a special hash value that disables validation of that field.
- The easy solution would be to validate the user input on the server and hash it before forwarding it to FoxyCart.
Questions:
- Does allowing users to test VALUEs increase the likelihood that SECRET will be broken or illegal hashed values generated, relative to the CONTROL scenario?
- By how much?
- How is this calculated or proved?