Menu
Question: Is this API authentication technique easily hackable?
apiKey = "123456789"
apiCallId = "1256341451"
apiSecret = "67d48e91ab2b7471d4be2a8c2e007d13"
sig = md5(apiKey + apiCallId + apiSecret) = 09c297a354219f173bfc49c2e203ce03
where
apiKey: some unique identifier for the userapiCallId: a unique integer that must be increasing in value (e.g. UNIX time stamp)apiSecret: string known only to the user, and us - not passed in URLsig: "unhackable" signature of this API call - MD5 hashExample API call:
http://api.domain.com/?apiKey=123456789&apiCallId=1256341451&sig=09c297a354219f173bfc49c2e203ce03¶m1=x¶m2=y
This API does not require a session, and is not designed for a 3rd party to use on behalf of a user. Instead, it is to be used by the user themselves.
I really like the simplicity of this. The requirement of apiCallId being unique, and always increasing means reusing a sig is not possible, so I feel like it is secure (protected against replay attacks), but I am not an expert.
Other APIs use all of the GET parameters sorted alphabetically when calculating the sig, but I do not see why this is necessary when including apiCallId.
Please try and hack this now before it is implemented and released.
I welcome any feedback, suggestions and security education.
383
The API authentication process validates the identity of the client attempting to make a connection by using an authentication protocol. The protocol sends the credentials from the remote client requesting the connection to the remote access server in either plain text or encrypted form.
Another form of REST API authentication known as hash-based message authentication code (HMAC) is often used when the integrity of the REST API's data payload is a priority. HMAC uses symmetric encryption -- sometimes called single-key encryption -- to determine the hashing of a REST API's data payload.
It's the process of using a software protocol to ensure that clients on a network are who they claim to be before granting them access. The goal of API authentication is to prevent attacks from cybercriminals who snoop around websites looking for the slightest vulnerability to take advantage of.
Users of the REST API can authenticate by providing a user ID and password to the REST API login resource with the HTTP POST method. An LTPA token is generated that enables the user to authenticate future requests. This LTPA token has the prefix LtpaToken2 .
What you are doing seems reasonably sane, except for not checking the parameters (which is going to be a pretty big problem).
Something which is very similar to your design which it might be wise to copy is the Amazon Web Services Request Authentication Scheme
In particular make sure your encoding scheme for the parameters is unambiguous and invertible; Amazon screwed this up at one point. Learn from their mistakes. :)
Cryptographically speaking, what you are doing is not called a signature but rather a message authentication code (MAC). A MAC can be created and verified by anyone who shares the secret key (the term 'signature' is normally reserved for public key schemes like DSA or RSA). MD5(msg || K) is a known and reasonably sane MAC; I'm not sure if you missed it by accident or on purpose, but a method that seems on the surface to be equivalent, MD5(K || msg), is quite insecure, because a quirk in how MD5 (and most other hash functions) are designed means that if you know H(m) you can easily compute H(m || m2) for any m2 - so if you were using MD5(K || param1=5), someone could pull this off the wire and then create MD5(K || param1=5,param2=666). (It's perhaps a bit more technical than you're interested in, but this is called the length extension property).
However while MD5(K || msg) is probably 'fine', you are better off using something like HMAC, because it was actually designed as a MAC. MD5 has a lot of problems but nothing directly affecting its use as a MAC (yet - MD4 has been broken in this way). So for future-proofing (and audit-proofing) use HMAC with SHA-1 or SHA-256 instead. Even if you don't want to pull in a crypto library, HMAC is quite simple and there are known values available for SHA-1 and SHA-2 so you can check your code.
82
No. The integrity of the other parameters (param1 and param2 in your example) is not protected. An attacker can intercept the call and alter these as he likes before forwarding it. The apiCallId only prevents replays, not alteration of the first call.
I'm no expert. If I saw that immediately, there are probably other problems lurking.
34
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
