If an app is interacting with server api over https using post method ( JSON objects ), then there is a danger of api endpoint getting exposed and anyone accessing the api.
Is there a way to make sure that api is called only from the designated app.
I did some research on the web and came to know of:
a. manual credential checking using POST method
b. using json web tokens ( jwt)
However my question is: both of these methods a) & b) would require some kind of username/passwd passing from client app to server ( everytime in a. and only once in b.). Now this username/passwd would need to be hardcoded in apk and it can be easily obtained by anyone by decompiling it. So then how are these methods secure?
I think you're misunderstanding how json web tokens or bearer tokens work. Why would a username and password ever need to be hardcoded? You'd supply the user with an interface that accepts a username and password.
In option a, you'd store these locally after the user supplied their credentials and clear it when they exit the application or log out. This would not be recommended as that's what tokens can be used for. Many frameworks already offer support for JWT out of the box.
If using a token, the user still supplies their username and password to authenticate, the server will return a valid authorization token. From that point forward the auth token is passed with each request.
I would somehow use TLS security ... with digital certificates ... to cryptographically secure the network access to the portal. The app would contain the necessary public certificate, possibly obfuscated, which the server could check to make sure that the access is legitimate. Now, no one can intercept the communications, and they can't spoof it without somehow first extracting the certificate information from the app, which is probably unlikely. Knowing that the supplicant does possess a copy of the necessary public key should be sufficient authentication.
Although we don't usually employ it when we use TLS to get to your friendly neighborhood https web-site, modules like mod_ssl do provide a complete TLS implementation including the ability to require and to verify a client-side security certificate, without possession of which the connection attempt will be refused. This might be an ideal situation for that.
Related
I have an iPhone app that is using my php api on the server but it is currently open if someone knows the url. I want to make sure that no one can use this API until I am ready to make it a public api (if I even do)
I have read this article but I am unsure what they mean when they say:
[CLIENT] Before making the REST API call, combine a bunch of unique data together (this is typically all the parameters and values you intend on sending, it is the “data” argument in the code snippets on AWS’s site)
I don't understand how if I hash the parameters I plan on sending with my api secret how this is more secure than just hashing the api secret if I send the parameters/values unencrypted.
HTTPS the API and use an API key. Then you'll know that only people (you in this case) with the key can have access to the API.
You're correct about it not being more secure. That's why I suggest you SSL the connection. Unless you plan on encrypting everything you transmit back and forth.
The public/private key scenario will also work well. HTTPS requires very minimal effort.
Digital signatures provide a way of validating a message sent over an insecure connection.
Setup: each client will have its own private key and public key (only the private key needs to be stored on the client). The server will store the public keys for each client. The public key can be visible to all and can be used by the server to identify the client. The private key, known only to the client, it is never shown to anyone.
The client signs the request: along with the rest of the request data, the client will hash the combined request data and encrypt the hash with the private key. The server will generate the hash the same way (leaving the signature out of the hash calculation), then decrypt the signature using the public key. If the hashes match, the request is authentic.
Note that HTTPS allows for client certificates, so you can leverage existing tools to accomplish all of the above without writing a single line of server-side code (you just have to configure your web server; the only trick is to make sure the server only accepts certificates it already has). Moreover, the amount of client side code should be minimal: you shouldn't need to do much more than set the connection to use the client certificate. Since you're controlling the clients, you can use self-signed certificates and add the server as a certificate authority. There are a number of questions on SO about using client certificates in iPhone apps; you can start by reading through them.
Note also that any scheme to protect the web API only works so long as copies of the app are in trusted hands. Should anyone untrustworthy get ahold of it, they can use the app or extract any secret data used by the app and access the API as they will.
For development purposes you can just use your web server settings to allow requests from your ip only.
I'm working on a user authentication library in PHP. Right now I have both stateful and stateless CSRF protection, everything's secure. My problem is that the API is for remote applications (mobile app, game, etc) and has a public facing script to let a client app perform requests to authorize/log in a user. I would like to include the functionality for creating and removing a user in this API so that the client can do everything itself, but can't figure out a way to make it so that the creation script couldn't just be hit by anybody to flood the database with fake users. When creating a user with the API, I don't require any credentials other than username or password in the request, which means that anyone could hit that script. Does anyone know of a secure solution to this to prevent an attacker from using the API to create/remove users themself?
you could increase obscurity by requiring a secret key. Distribute the key in the client code. However, anyone accessing the client code can see the key and use it. But random people scanning your service wouldn't have the client code, nor the key.
I have an iPhone app that is using my php api on the server but it is currently open if someone knows the url. I want to make sure that no one can use this API until I am ready to make it a public api (if I even do)
I have read this article but I am unsure what they mean when they say:
[CLIENT] Before making the REST API call, combine a bunch of unique data together (this is typically all the parameters and values you intend on sending, it is the “data” argument in the code snippets on AWS’s site)
I don't understand how if I hash the parameters I plan on sending with my api secret how this is more secure than just hashing the api secret if I send the parameters/values unencrypted.
HTTPS the API and use an API key. Then you'll know that only people (you in this case) with the key can have access to the API.
You're correct about it not being more secure. That's why I suggest you SSL the connection. Unless you plan on encrypting everything you transmit back and forth.
The public/private key scenario will also work well. HTTPS requires very minimal effort.
Digital signatures provide a way of validating a message sent over an insecure connection.
Setup: each client will have its own private key and public key (only the private key needs to be stored on the client). The server will store the public keys for each client. The public key can be visible to all and can be used by the server to identify the client. The private key, known only to the client, it is never shown to anyone.
The client signs the request: along with the rest of the request data, the client will hash the combined request data and encrypt the hash with the private key. The server will generate the hash the same way (leaving the signature out of the hash calculation), then decrypt the signature using the public key. If the hashes match, the request is authentic.
Note that HTTPS allows for client certificates, so you can leverage existing tools to accomplish all of the above without writing a single line of server-side code (you just have to configure your web server; the only trick is to make sure the server only accepts certificates it already has). Moreover, the amount of client side code should be minimal: you shouldn't need to do much more than set the connection to use the client certificate. Since you're controlling the clients, you can use self-signed certificates and add the server as a certificate authority. There are a number of questions on SO about using client certificates in iPhone apps; you can start by reading through them.
Note also that any scheme to protect the web API only works so long as copies of the app are in trusted hands. Should anyone untrustworthy get ahold of it, they can use the app or extract any secret data used by the app and access the API as they will.
For development purposes you can just use your web server settings to allow requests from your ip only.
i am writing an iphone app that would need to communicate with our servers. on the server side, im am writing an api in php that the app would talk to. What is the best way to authenticate the apps and basically restrict access to the apps and shut everyone else out?
I need a way of recognizing that an incoming request to the api is a legitimate request from our api.
What other security concerns should i keep in mind and calculate for?
any design suggestions?
i am currently looking into what oauth can do for me here!
I think you don't need oauth because it will only help you when you need authentication involving three parties. Example: your application authenticating a Fecebook user (three parties here: you, Facebook user and Facebook).
I would make sure you use this:
HTTPS (never send password or sensitive data over plain HTTP)
A login.php script that will authenticate your user, and upon valid authentication will generate an access_token for your mobile user.
Each restricted service you provide with PHP will ask for a valid access_token as a parameter to execute.
Make sure your access_token expires after certain time or conditions you might impose.
Look at the big companies? Google uses an API key for all their public APIs so they can track behavior and block if they expect abuse.
Since your API is probably not public you might need more security but then you'd probably need to encrypt all communication :<
I'm planing to create a few simple REST web services to be used by some other applications (everything internal, not facing Internet). For certain reasons the applications should work with SSO (Windows, NTLM or other). The issue I have is how to do the authentication in the web service.
The application calling the web service has no knowledge of the users password so I'm kind of lost on how to authenticate against REST without having the user to login? eg. avoid Basic Authentication
I would like to avoid login due to simplicity for the user and not having to handle passwords in my applications. What are my options? Am I missing something obvious?
Would this be a solution:
create token, pass it to service and store it in database. web service checks if token exists in database. (expiration handling?)
The most common solution to this problem is, as you mentioned, a simple key or token based authentication. This is how a lot of google services (e.g maps) work. You simply generate a key on your service provider for each consumer, store it in your database, and validate that all calls pass a valid key.
More sophisticated options would be HMAC or OAuth authentication. Given your situation, i.e. providing services only within your intranet, I'd say keep it simple and go with a single key authentication.
In the above scenario I don't see the need for handling expiration. Nonetheless, if you'd like to implement it, then you could
on each client request, generate a timestamp based token on the server
in your reply to the request, also include this token
client should use both the static API key and the dynamic token in subsequent requests
server should check the token's lifetime and accept / refuse the request as necessary.