I have an API key that needs to be called from a particular file and as I do not want to store the API key in a source code, I've decided to encrypt the API key using PBKDF2 and decrypting the file once with my password to retrieve my API key whenever I start or restart my server.
However, I could not find a way to store the API key as a persistent variable where I only have to activate the PHP file that retrieves the API key once. Having tried include, require_once and global in php. I also could not use any files or database to store the API key retrieved as this would make what I did pointless.
Is there any way to store the API key as a variable where I am able to call it with let's say my API.php whenever the users need to use the API on my website without using any databases and files?
I am also using nginx as my server.
Thanks!
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.
Ive recently started looking into authenticating with azure active directory using client credentials grant with public/private certificates as detailed here: https://learn.microsoft.com/en-gb/azure/active-directory/develop/v1-oauth2-client-creds-grant-flow
Im running an external PHP/LEMP server outside of the azure hosting platform etc etc.
I've managed to get the connection to azure ad working successfully as seen below:
The question is more how we do the credential storage so i can actually do the authorisation. The ironic thing is, i need to store these credentials so i can access ones stored securely within the key vault! So im just wondering does anyone have any recommendations for storing of the:
Tennant ID
Client ID
Scope Uri (i guess i should include this to, as it's an id/guid as such)
Is it safe to store these values as plain text within a sites database?
Would you recommend environment variables? Just wondering what peoples approach is to this.
Many thanks!
I would suggest you store these variables in Key Vault, that's the most secure option. However, then obviously you need keys to access Key Vault.
If you were running your web app in Azure then this would be easy. You can use managed identity to give your web app an identity, and grant this access to KV, done. As your running outside of Azure, the next best method would be to generate a service principal that authenticates with a certificate, grant this service principal access to key vault, then store the private key on your web server and use this to auth. See here for details on creating a service principal.
I have a security-related question - I'm developing an app that populates its database by using a PHP script on a remote server. I wouldn't like to make the PHP script publicly available, but just use it from the specific mobile application (written with TypeScript using the Ionic Framework). How could I accomplish this?
Make your mobile application to provide with the query some kind of secret string / token. And your server side PHP script will not proceed without valid token provided from the request.
The token can be part of your POST/GET/HTTP header or so.
What I've done in the past to achieve something like this is to setup an API key system. You generate API keys server-side, and you lease out valid keys that you have generated to your application(s). You would then use that key in your application, and that would get sent to the server and parsed by a php script whenever you call the script from your mobile application. If the key is valid, then the request is valid.
There are some security considerations to think about, i.e what happens if someone gets your API key? Are you logging remote IP's (and fully qualified domain names) and API usage, will your system be able to invalidate the key whenever necessary? Is the API request utilising TLS connections?
I'm building an App who access a MySQL database from my server, and I'm sending the data from the app and receiving the PHP response from the server. I'm trying to create a Login system for this App using this database.
What's the process? What's the best practice for build this?
You will have to store some kind of session value in your app and send it with your requests. You may be able to utilize PHP sessions to do this, but what I usually prefer to do is create database entries for API keys. On a successful login an API key is generated for that user and stored on the device. Then on each request you will pass the username/api key combination for authentication on the server side. This method will easily port over if you wish to expand your codebase into android/blackberry/toaster ovens. It makes for a very portable authentication system. Also, this keeps you from having to store the password on the device, which is a security concern.
This is how one programmer chooses to do it.
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.