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
Many thanks for sharing such a very nice post about security in several fronts, with links for the resources.
I would like to make some calls of attention for the readers, but please do not take this as an attack, just as complimentary information.
Authentication vs Authorization
Authenticate individual users for specific actions.
Even when a user is already Authenticated, its good practice to Re-Authenticate and Authorize the user to perform a specific action in sensitive data, like changing the email or password.
Always remember that Authentication is not the same as Authorization. You may prove that your are Bob by passing the login challenge successfully, but that doesn't mean you are Authorized to perform the action you are trying to.
API Keys are not Secure
Use API keys to secure, authenticate and track usage of a REST API.
Lets' clear first a usual misconception among developers, that relates to WHO vs WHAT is accessing the API server.
For a better understanding off the difference between WHO vs WHAT is accessing your API server, I recommend you to read this section of my article, but I will extract here some lines of it:
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
API keys do not truly Authenticate anything, at best they can be used to track usage, and impose rate limits. They are not a secret, because once they are in a web app or mobile app, they belong to the public domain, thus they cannot be used for the purpose of authentication, because they are easy to extract and reuse in automated or manual attacks.
Im with when it comes to security of api-keys, with one difference. They can be secure (or at least as secure as things can be ;) ) as long as they are bound to the session/client who created them, which would result in a broken key if someone would try to reuse the same key on another device/session.
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
Sessions can be reused by an attacker, but definitely it makes up for one more security layer to be bypassed, and I always recommend to use it when possible.
Other techniques exist to make them more difficult to abuse, but an API key on their own, can only be considered secure for authentication purposes when the communication is between 2 servers, and they are stored in both servers in a secure way.
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.
Many thanks for sharing such a very nice post about security in several fronts, with links for the resources.
I would like to make some calls of attention for the readers, but please do not take this as an attack, just as complimentary information.
Authentication vs Authorization
API Keys are not Secure
Lets' clear first a usual misconception among developers, that relates to WHO vs WHAT is accessing the API server.
For a better understanding off the difference between WHO vs WHAT is accessing your API server, I recommend you to read this section of my article, but I will extract here some lines of it:
API keys do not truly Authenticate anything, at best they can be used to track usage, and impose rate limits. They are not a secret, because once they are in a web app or mobile app, they belong to the public domain, thus they cannot be used for the purpose of authentication, because they are easy to extract and reuse in automated or manual attacks.
Im with when it comes to security of api-keys, with one difference. They can be secure (or at least as secure as things can be ;) ) as long as they are bound to the session/client who created them, which would result in a broken key if someone would try to reuse the same key on another device/session.
Sessions can be reused by an attacker, but definitely it makes up for one more security layer to be bypassed, and I always recommend to use it when possible.
Other techniques exist to make them more difficult to abuse, but an API key on their own, can only be considered secure for authentication purposes when the communication is between 2 servers, and they are stored in both servers in a secure way.
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.