web services – Securing REST API with hashed signature

web services – Securing REST API with hashed signature

There is nothing inherently wrong with this plan. If the client sends:

data . nonce . hash(data . nonce . shared-secret)

Then the server verifies the message by checking that hash(data . nonce . shared-secret) matches the hash provided by the client, you would be safe against both tampering and replay (assuming, of course, that youre using a reasonable cryptographic hashing algorithm).

Under this design, the client can even generate its own nonces, provided there is no risk that two clients will generate the same nonce.

However, eavesdroppers will still be able to see all the data you send… So, unless there is a very good reason not to, I would simply use https (which, unless there are other requirements Im unaware of, be entirely sufficient).

web services – Securing REST API with hashed signature

Leave a Reply

Your email address will not be published. Required fields are marked *