Custom RPC end-point security best pratice?

Question

I trying to figure out how a custom entry point can be secured without loading the entire WP-stack. The built-in AJAX entry point is pretty slow and actually unusable on sites with lots of plugins. So I have to write something myself. I found some old coder called 'wp_session'. Its basically the base to secure my end-point.

Currently I am implemented it like this :

1. Within my WP-Back-end plugin, i initiate the wp_session class and store some data to be used for verification later in my end-point.

2. As soon a client makes a RPC through my end-point, I am getting my 'session instance' back and check that the parameters in that session object are ok; the user is privileged then, for now.

3. In the RPC URL, I am adding a 'signature' which is being calculated on the client side, using a HMAC_SHA1 and secret key based on md5(user_id + user password) + wp_nounce (adds a time limit) and the Wordpress salt key (adds site specific salt). The client 'signs' the payload with that token. This very token is passed to the client due to the plugin rendering (action). He can't get such token without being logged in.

4. In my end-point, i am checking that the signature built by the client is correct and is still valid.

5. Do the RPC thingy.

I am still hesitating to feel all-right about this way. Can anyone suggest a better practice or simply confirm, that this measures are enough? For instance wp_nounce is a great and quick method to add some security for Ajax calls but as soon you need to enable RPC calls for remote services it won't work (eg: share a RPC based download link). In that case I could only build the token without wp_nounce and verify that the md5(user_id + password hash + site-salt_key) in the RPC url is correct. That would do the trick but its not time limited. To make a time limit on the token, I would need to store things in the database without the WP API because again of performance reasons.

Any suggestion is welcome. thank you!

Answer 1

I think your paradigm is not optimal. You are starting on premise of "WordPress Ajax endpoint is slow" and your solution is to "build alternate authentication scheme". This completely spells trouble.

Anything security should be reused as much as possible and coded by people specializing in security. Trade-off of reimplementing security for the sake of performance is major red flag.

So back to square one. If your issue is "WordPress Ajax endpoint is slow" then build a faster WordPress Ajax endpoint. You can do so with SHORTINIT (there are answers about it around on site) to have very customized core load. It's a nightmare to ship in public code and pain on upgrades, but for private high–performance Ajax it's the way to go.

PS I am not sure how your Ajax needs relate to RPC (XML RPC?) needs, since you mention both.