Thanks for the detailed response. Definitely very helpful! I agree with all your points.
W.r.t API Keys, I am also of the opinion that once they are included in a webapp or mobile, they are in the public domain. As @exadra37
mentions in the chain, typically API keys (in plaintext) are used for server-server communication. Whenever including API keys on the client side, one should always sign & encrypt the token with the client's private key before transmitting over the wire. They then just act as session IDs.
I am a Developer Advocate for Security in Mobile Apps and APIs at approov.io.
Another passion is the Elixir programming language that was designed to be concurrent, distributed and fault tolerant.
Location
Scotland
Education
Self teached Developer
Work
Developer Advocate for Mobile and API Security at approov.io
Whenever including API keys on the client side, one should always sign & encrypt the token with the client's private key before transmitting over the wire. They then just act as session IDs.
Signing anything with a private key on the client side can be bypassed, because once you have the private key in the client side, aka mobile app or web app, it's not anymore a private key, it's a public key.
Now signing and encrypt an API key token on the server side, before it's sent to the client guarantees confidentially during the communication process and allows to anyone having the server public key to verify its authenticity, but doesn't guarantee that when the API key token its sent back to the server that it comes from the same client the server sent it to, because an attacker may be reusing it to impersonate the server as the original client.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the detailed response. Definitely very helpful! I agree with all your points.
W.r.t API Keys, I am also of the opinion that once they are included in a webapp or mobile, they are in the public domain. As @exadra37 mentions in the chain, typically API keys (in plaintext) are used for server-server communication. Whenever including API keys on the client side, one should always sign & encrypt the token with the client's private key before transmitting over the wire. They then just act as session IDs.
Signing anything with a private key on the client side can be bypassed, because once you have the private key in the client side, aka mobile app or web app, it's not anymore a private key, it's a public key.
Now signing and encrypt an API key token on the server side, before it's sent to the client guarantees confidentially during the communication process and allows to anyone having the server public key to verify its authenticity, but doesn't guarantee that when the API key token its sent back to the server that it comes from the same client the server sent it to, because an attacker may be reusing it to impersonate the server as the original client.