Live data from Hacker News

How not to write an API

ghost.teario.com

171–172 of 172 posts

Re: How not to write an API

#171

Post by misterjangles » Sun, Mar 16, 2014, 8:27 AM UTC

dawkins wrote: post #153

mmcnickle wrote: post #135

Earlier quoted context omitted.

The user will enter their password on the provider's site via the phone browser. It relies on the user's trust of the system browser.

I meant for a native app and you being the provider. If you don't trust the client app even oAuth won't help you preventing the client app to know the user password.

It is true you have to trust that the native app is not tricking you into thinking that you're entering your password on Facebook.

But, at least if it's implemented correctly and not maliciously, the app doesn't ever see your password.

Re: How not to write an API

#172

Post by misterjangles » Sun, Mar 16, 2014, 8:30 AM UTC

Kiro wrote: post #132

misterjangles wrote: post #97

Earlier quoted context omitted.

#1 is a fairly standard security concept used by protocols like oAuth or JWT. It requires an API key pair (public and secret key). The secret key is only used for signing and is never passed in the request. Used in combination with nonces and time stamps you can make a secure API that isn't susceptible to replay attacks.

Even if it's not passed in the request it's still in the app so isn't it vulnerable to reverse-engineering?

There shouldn't be a key baked into the app. Each user gets their own unique key. so the worst you could do reverse engineering the app is to steal your own key. There should never be any "master" key used for all users.

Post reply on HN