7 ms·

Also Twitter had changed their policy regarding API keys. You no longer just ”get” them. You need to apply. I was rejected for getting key to export my own twee

Also Twitter had changed their policy regarding API keys. You no longer just ”get” them. You need to apply. I was rejected for getting key to export my own tweets. Of course, this means everyone is using web scrapers for what was used API keys before, because of you can use public internal API.

arsome 5y ago
I prefer to just steal keys by reverse engineering mobile apps. So easy to get keys for just about anything and charge someone else for it that way.
- alanhaha 5y ago
  But as a developer, I won't put the API key in the client.
  - OrangeMusic 5y ago
    How will the client communicate with the API then?
- anon9001 5y ago
  Excellent replies to everyone in this thread. You're spot on. Just out of curiosity, is there a marketplace for private APIs? I'd love if you could elaborate on the "charge someone else for it" part.
  - mguerville 5y ago
    I know of RapidAPI by rakuten, it operates as an API marketplace like this
- hn_99 5y ago
  Interesting. As someone who hasn't done any mobile dev at all, is there a way to prevent something like this from happening? Can't you somehow encrypt such secrets in the app?
  - addandsubtract 5y ago
    You could proxy requests over a server you control. This might just shift your problem, depending on the use case.
    - Anunayj 5y ago
      Rate-limiting works really well in most cases, though CGNATs makes that a horror nowadays too.
  - aabbcc1241 5y ago
    Frontend is in the hand of enemy. There is no secret on the client side.
  - arsome 5y ago
    You can try, but you won't succeed against a dedicated reverse engineer, simply dropping a hook in on the API calls would be enough to grab the decrypted key in a case like that, if not simply statically reading the encryption keys and decrypting it. That's not to say it's useless - some reversers will simply move on to the next app when there's a list of dozens. You can also send requests via your own server, which would allow you more control over the requests that get sent out to your 3rd party APIs and just restrict tokens as much as possible to the minimal set of features necessary for your application.
    - gligorot 5y ago
      What about secure key import on Android? It's still not that widely available, but should be everywhere in a few years. The idea is: -a keypair is generated in secure hardware - you send the public key to a server which encrypts the secret key with it - the server sends the encrypted key back - then it goes inside the secure hardware where it gets decrypted The decrypted secret key is never in the userspace.
    - powvans 5y ago
      Mobile developers can implement certificate pinning to prevent man in the middle snooping. Twitter's app does this.
Macha 5y ago
And this is likely because there were a few years of "insert your own API key" third party clients after Twitter limited their max user count. This from the site that used to indicate on every tweet the client used

arsome 5y ago

I prefer to just steal keys by reverse engineering mobile apps. So easy to get keys for just about anything and charge someone else for it that way.

alanhaha 5y ago
But as a developer, I won't put the API key in the client.
- OrangeMusic 5y ago
  How will the client communicate with the API then?
anon9001 5y ago
Excellent replies to everyone in this thread. You're spot on. Just out of curiosity, is there a marketplace for private APIs? I'd love if you could elaborate on the "charge someone else for it" part.
- mguerville 5y ago
  I know of RapidAPI by rakuten, it operates as an API marketplace like this
hn_99 5y ago
Interesting. As someone who hasn't done any mobile dev at all, is there a way to prevent something like this from happening? Can't you somehow encrypt such secrets in the app?
- addandsubtract 5y ago
  You could proxy requests over a server you control. This might just shift your problem, depending on the use case.
  - Anunayj 5y ago
    Rate-limiting works really well in most cases, though CGNATs makes that a horror nowadays too.
- aabbcc1241 5y ago
  Frontend is in the hand of enemy. There is no secret on the client side.
- arsome 5y ago
  You can try, but you won't succeed against a dedicated reverse engineer, simply dropping a hook in on the API calls would be enough to grab the decrypted key in a case like that, if not simply statically reading the encryption keys and decrypting it. That's not to say it's useless - some reversers will simply move on to the next app when there's a list of dozens. You can also send requests via your own server, which would allow you more control over the requests that get sent out to your 3rd party APIs and just restrict tokens as much as possible to the minimal set of features necessary for your application.
  - gligorot 5y ago
    What about secure key import on Android? It's still not that widely available, but should be everywhere in a few years. The idea is: -a keypair is generated in secure hardware - you send the public key to a server which encrypts the secret key with it - the server sends the encrypted key back - then it goes inside the secure hardware where it gets decrypted The decrypted secret key is never in the userspace.
  - powvans 5y ago
    Mobile developers can implement certificate pinning to prevent man in the middle snooping. Twitter's app does this.

Macha 5y ago

And this is likely because there were a few years of "insert your own API key" third party clients after Twitter limited their max user count. This from the site that used to indicate on every tweet the client used