I'm using Azure as cloud storage, i'm able to upload and download the images/files in Azure blob container using following link.
Azure Blob storage
Now to provide security we are planing to use key vault. Using key vault keys need to access the blob storage in azure.
There is no information available for android to use key vault. If anyone knows anything please post it.If i miss anything to mention please comment i will update it. I'm new to azure implementation.
Edit:- My goal is to display images in app which are stored in Azure blob storage.Instead of accessing azure storage directly by using Key vault i want to access it. After getting secrete key from key vault how to connect azure with that key ?
keys are stored in key vault i want access them and use them to access blob storage
Don't use Azure Keyvault when you're building a mobile app. At least not directly.
You see, we want to keep all app secrets off the device if possible. Even if they're never being stored and will only be in memory transiently.
To solve this particular conumdrum, we're still going to take advantage of Keyvault and all it has to offer and put the Azure Storage API key in there.
But instead of having the mobile app directly access the Table storage, we're going to have an Azure Function do that.
For more details, you could refer to this article.
A small bit of anatomy, in case you're not very familiar with azure cloud: we have Azure Function -> block of executable code, triggered by a http request or other (e.g. database triggers) and Azure Function App which is an umbrella for having multiple functions.
Azure Functions have different levels of security: anonymous, function and host keys https://learn.microsoft.com/en-us/azure/azure-functions/security-concepts?tabs=v4
By creating an Azure Function App, you can secure the function app itself with the OAuth2 protocol https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization
if you're using other cloud providers, like gcp you can also authenticate with a federated token, see https://learn.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation-create-trust-gcp?tabs=azure-cli%2Ctypescript
Because you created this authentication flow, even if your function doesn't have a key (your function security is anonymous), the function app (which you need to authenticate to with OAuth2 flow) can now call the unprotected function URI.
One more note, to actually grasp this, try creating a FunctionApp yourself, where you disable authentification, and if you access the link, you'll see no credentials requirement and check if by copying your AzureFunction uri that you can call the function (anonymous level security).
Now add authentification on FunctionApp and see for yourself that you can no longer call the AzureFunction.
To sum up https://codemilltech.com/mobile-apps-azure-keyvault-dont-do-it/
Now you no longer have to manage secrets, or api codes in your app. All your api's codes and secret now reside where they should - your backend.
Sorry for the wrong answer, I know it might be a bit redundant but this is how I understood the entire access of an Azure Resource(keyvault) through an Azure function which is under the umbrella of Function App, which counterintuitively has the security level to anonymous.
Related
Im currently building an app, back-end and front-end and I use Firebase for saving pictures that the users can upload and download, up till now I've been uploading them from the front-end and if the upload is successful then I send the image link with the rest of the data to the back-end, but as Im saving firebase credentials (in order to connect) in the app, now Im questioning if it would be better/safer doing it all in the back-end, sending all the information (image included) and the let back-end upload the image to firebase. I don't how how secured are those credentials being of the app
I usually handle things in the front-end if the Firebase SDK has what I need. The only common reasons not to do this, is when there is a requirement to do them in the back-end. This is only common for operations that: require a lot of memory/CPU/bandwidth, require access to secret information (e.g. an API key for a payment gateway), or where the code itself is secret (e.g. detecting cheats in a game, or malicious messages in a chat app).
In your case for example, uploading directly from the front-end to Cloud Storage is a great reason to use the Firebase SDK. Doing so means that Firebase takes care of the encoding, of retrying, of security, and many other things. If you'd want to introduce your own server in the middle, you'll have to write the (client and server) code to handle all of that yourself.
Note that the keys that Firebase tells you to add to your app through the google-services.json are not credentials, but merely configuration data that the app needs to find your Firebase project on the servers. For more on this, see my answer here: Is it safe to expose Firebase apiKey to the public?
But that said, with the configuration data anybody can call Firebase API methods on your project. So you need to secure access in some way, to prevent other users from coming up with their own code that uses your project.
The common way to do this is by using Firebase Authentication on the client to sign the users of your app in. You'd then use the Firebase security rules to limit who can read/write what files in Cloud Storage.
I have read about Parse server which was created by facebook , but I think there are serious security issues.
I can decompile other people apk and get Parse master key, appId and then I can connect this people parse server from my own application and can do whatever I want to do with his data which very dangerous
Even I can make while(true)loop and insert infinite data to the parse server.
So how can I connect any API in Android Studio securily?
You shouldn't put the master key anywhere publicly available. If it's in your APK, you're doing something dangerously wrong. Master key should only be an environment variable on your server.
Sure, you could get anybody's app id and client key (if they added one) by decompiling, but that's the same with basically any API. You need to use the security tools provided by Parse, namely CLPs and ACLs. You shouldn't have any data too sensitive on your server at all. I.e., you never need to store a user's actual payment information, you should use a payment API, pass any information needed to them directly from clients, and store the tokens they give you. I.e. with Stripe, there is a "public key" that is used on the client to talk to their secure server, pass credit card info, and create a card token, and you pass that card token back to your server, which can use the secret key, which should absolutely never be put in a client app, to create charges and things.
CLPs and ACLs restrict access to your objects. CLP (Class Level Permissions) are used to restrict entire tables. They have a cool thing called Pointer Permissions, so if an object has pointers to a user, you can set it to the user set on that field can access their objects. You can restrict public access so you can only get an object with the id, but not find it in a query. You can completely restrict read access, and you should restrict write access on most classes. Business logic goes on the server, you can verify a session token to make sure a user should be accessing an object and then use your master key to actually do necessary updates.
Parse-Server has all of the security implementation you need to protect your user's data. You just have to implement it properly. If you don't use CLPs and ACLs, anyone can decompile your app and get your entire database.
Also, Parse wasn't created by Facebook. It was acquired, then shut down and open sourced about a year or so later.
The Application ID is not a security mechanism and you must not ever use the master key in public applications as it allows you to bypass all of your app’s security mechanisms. It's a big mistake to store master key in the app.
Security must be provided to Parse Server by Class Level Permissions and ACLs (and all connections should be made with HTTPS and SSL).
In my experience, Class Level Permissions should rarely grant Public access (default behavior when creating a Class in Parse Dashboard). I only use Master key for testing purposes and to do some queries/savings in afterSave triggers and cloud functions.
I recommend reading the Parse's Security Guide to understand a bit better how to build a secure Parse API. Here is an important fragment that backups my answer:
The master key, on the other hand, is definitely a security mechanism. Using the master key allows you to bypass all of your app’s security mechanisms, such as class-level permissions and ACLs. Having the master key is like having root access to your app’s servers, and you should guard your master key with the same zeal with which you would guard your production machines’ root password.
You can store your API keys, Secret keys or any other important key information in .C file.
For that you have to use NDK.
You can follow this link for how to use the NDK to secure your file. You can also find GitHub demo app link at the bottom of the page.
Note: If you are using NDK it will increase your APK size.
I want to use Microsoft Azure Storage Android API to upload images made by phone camera.
Here's like to it:
https://github.com/azure/azure-storage-android
Here's my question: Account name and key are stored in string inside app, so anyone could decompile it, get these credentials and then, for example, upload lots of data which would cost me money.
So is it safe to use this on android app?
What are my other options?
You should not store the keys in your application. You're right that somebody could decompile your app and get the keys. Furthermore, if you ever have to change your account key for whatever reasons your users would need to download your application again.
What you should do is make use of Shared Access Signature (SAS) when somebody needs to upload the images. You could use Azure Mobile Service or write your own web service to get SAS (with write permission) on demand and use that in your application to upload images in your storage account.
You are right. If you are shipping the credentials to your Azure storage account in your app, then well, anyone has the credentials and can do anything with it.
Typically you would create an intermediate web service (e.g. hosted on Azure websites) which accesses Azure storage and limit the amount of data each user may upload. The app communicates only with your web service and hence does not need to know about the credentials to the storage account.
Obviously you will need some kind of user management built into your web service, e.g. custom accounts, Google login (most Android users will have a Google account), OpenID, OAuth, ...
Adding the AWS access key and secret key directly in app code is definitely not a good approach, primarily because the app resides on the users device (unlike server side code), and can be reverse engineered to get the credentials, which can then be misused.
Though I find this information everywhere, but am unable to find a definitive solution to this problem. What are my options? I read about the token vending machine architecture for temporary credentials, but I am not convinced that it is any better. If I can reverse engineer the secret key, then I can reverse engineer the code which requests for temporary credentials. And once I have a set of temporary credentials to access S3, I am as good as if I had the key. I can request the temporary credentials again and again, even if they expire pretty quickly. To summarize, if an app can do something, I can do the same as a malicious user. If anything, the TVM can be a bit better at management (rotating credentials, and changing key in case of breach, etc.). Please note we can put the same access restrictions on the secret key, as we plan to do in case of TVM temporary credentials.
Additionally, if Amazon doesn't want people to use the secret key directly in the App, why don't they block it in their SDK, and enforce TVM or the correct solution. If you will leave a path, people are going to use it. I read several articles like these, and wonder why?: http://blog.rajbala.com/post/81038397871/amazon-is-downloading-apps-from-google-play-and
I am primarily from web background, so my understanding of this may be a bit flawed. Please help me understand if this is better, and whether there is a perfect (or may be good) solution available to this problem.
PS: Is there a rails implementation of TVM?
Embedding S3 keys in App code is very risky. Anyone can easily get that key from your app code (no reverse engineering or high skill set required), even if that is stored encrypted it is still compromised just that someone need to try harder (depending on how do you encrypt).
I hope that you understand the advantages of using temporary credentials to access Amazon (S3 etc) resources (mainly security + some others like no app update etc). I think you are more confused about the process to get the temporary credentials from TVM and how that is safer than embedding keys in code.
Every client using TVM first need to register with the TVM server implementation hosted by you. The communication between App (using TVM client) and TVM server is over SSL.
First the app register with TVM by providing UUID and a secret key. Please note that the secret key is not embedded in App code (which I think is main reason for your confusion) but generated randomly (using SecRandomCopyBytes which generates an array of cryptographically secure random bytes) at the time of registration (and hex encoded).
Once the device is registered successfully with TVM, the client TVM store the generated UDID and secret key in a storage called Keychain in iOS and Shared Preferences in Android. The keychain in iOS is the shared storage provided by iOS to securely (encrypted) store information (mainly keys, password etc).
After registration and UDID/Secret Key storage, App can get the token from TVM by sending the UDID, cryptographic signature, and a timestamp. The cryptographic signature is an HMAC hash generated from the timestamp using the secret key. The TVM can use the UDID to lookup the secret key and uses it to verify the signature. The TVM then responds by sending back temporary credentials, which are encrypted using the secret key (uses AES). The application decrypts the temporary credentials using the key and can then use them to access any AWS services for which the temporary credentials are authorized. Eventually, the expiration time of these temporary credentials will be reached, at which point the application can get the fresh temporary credentials, if required.
I am not sure how signed URLs relate to TVM, because I don't understand the concepts 100% but signed URLs really solved the problem for me. I needed a mechanism that would feed web app and mobile app data without allowing for misuse of the credentials. Putting the key in the code is indeed a very bad idea as it may generate a huge bill for the company.
After 3 days of extensive research, I found a simple and, what seems to be, a reliable and relatively safe solution: signed URLs. The idea is, that a very light-weight back-end can generate a temporary URL that will grant the user access to the specific resource for a limited time. So the idea is simple:
the user asks our back-end with a Rest call that he wants a specific resource
the back-end is already authorized with AWS S3
the back-end generates a temporary URL for the user and sends it in the Rest response
the user uses the URL to fetch the data directly from the AWS
A plug-and-play Python implementation can be found here and with a slight modification that I had to use: here.
Of course one more thing to figure out would be how do we authorize the user before we know that we can grant it the URL but that's another pair of shoes.
You should ideally use Cognito Identity for achieving this along with appropriate policies. It should be used with S3TransferUtility and S3TransferManager in iOS and Android SDKs. That would allow for background uploads and downloads as well. Cognito vends temporary credentials for access to AWS resources and is free. Also, you could federate it using UserPools or providers like Google, Facebook if you want secure access.
Thanks,
Rohan
I have been using AWS (Amazon Web services) and in particular simpleDB for a couple of smartphone apps using their iOS/android client libraries.
So far, the data was very benign so I didn't worry too much about data protection.
My next app project will require a "users" table/domain containing usernames and passwords.
What I'm worried about is that someone reverse-engineer the Android java version of the app, then it will be easy to get all the simpleDB data, including all the passwords.
the basic TVM thing (Token Vending Machine, where a temporary token replaces the AWS credentials which are not in the code) doesn't seem to protect against that scenario so it would be great to hear what people think is the recommended approach to do the login part of the app using AWS without being completely unsafe.
Having the passwords table stored somewhere else/accessed in a different way?
Any comment appreciated, Many Thanks.
I can suggest you two approaches to keep your app protected -
1st Approach :
You can keep your AWS secret key into a file with in your app that will be encrypted using private key. On start-up, your code will read that file using public key and can only get your AWS secret key. Please remember following points in this approach -
Your code must be obfuscated.
Your secret key must be in encrypted form into the file so you will get double protection.
Your file must be digitally signed.
2nd Approach :
You can also create your own web site that will manage your user authentications and if user is successfully authenticated it will send AWS Secret key after encrypted it with private key, in his response to the app and your app will use that AWS Secret key after decrypting it with public key. Please remember following points in this approach -
1. Your response must be returned in encrypted form.
2. You site must be secure and must run on HTTPS.
3. Your code must be obfuscated.