This is a pretty nifty tool. I believe there’s a small security issue where this is vulnerable to replay attacks from a previously-used IP address, since it doesn’t use anything that changes or expires (such as a nonce or timestamp) in the string that’s used to generate the authorization hash.
This can be fixed if lambda function generates a nonce during the initial exchange and the client includes it in the string that’s hashed. This requires the lambda function to maintain state between requests however, so it’s not ideal.
A simpler method is to have the client’s hashed string include a timestamp with second-precision, and the lambda function verify by generating a hash including it’s own timestamp. If it fails to match (which could happen if the client’s clock has drifted), the lambda function could generate and check hashes within a 10-second (for example) window around the current time.
This does add some complexity, but protects against replay attacks which could happen on shared networks that the client has previously used. Since everything’s going over SSL, this shouldn’t normally be a problem, but with incidents like the Lenovo Superfish adware that broke SSL, it’s something to consider.
