On my android application I use the dropbox API. I hardcode the app key and secret. But to authenticate I need to log in using the dropbox account.
But whats the point of using a app key and secret if you have to enter a username and password.
Also what if you would like other people to be able to upload to your dropbox without using the accounts username and password. Can they use the app key and secret to just upload to the account without entering the accounts username/password?
You are a bit confused with what are app key/secret used to do. In briefly, a pair of app key/secret is used to identify an app. Is it a valid app? Is it authorized by user? And is it out of API call limit/throttling? Therefore, only with key/secret, app has no right to access an unauthorized user's private data. I'm sorry but I have to say allowing people upload data to your own cloud is not a good idea. At least, dropbox is not for that purpose. Instead, why not try some other cloud storage service, like Amazon S3?
Related
I have an android app which communicates with Google cloud api services like speech to text, translation, NLP etc. The application is using a service account to do this and the private key file is stored in the application itself. I understand that is a bad practice as anyone can see it using dissembler but I am not sure where else to store it for an android device.
The following post suggests to store this file on a build server:
https://brightinventions.pl/blog/securing-your-google-service-account-key-in-builds/
However, I think that it does not fix the issue as the service credential file is getting included in the publish package.
Please let me know if you can think of a solution.
Do not embed service account credentials in applications. Service Account credentials have a permanent lifetime which means you will be breached. You can delete service account credentials, but then you will have to re-release your application.
You have several options:
Implement Google OAuth so that your users authenticate with Google Accounts. When authenticating use the correct Google OAuth Scopes to provide temporary permissions.
Implement temporary access tokens. Your users will connect to your website, authenticate and your code will give them a temporary access token created from service account credentials. This access token will expire. The default is 3600 seconds but you can control this.
You users will make all requests thru your website API's. You control authentication of the users. Your website code then makes the API requests on behalf of the users. This is not an ideal solution as all traffic goes thru your website (Compute Engine, App Engine, etc.) and you will pay for that bandwidth.
First thing first, the question is not regarding how to use the Fingerprint scan API recently introduced in Android M. My question is what kind of a design approach should a developer follow to integrate the API on top of already existing security measures (password based/ federated etc.).
So I have an App in production which has an API which takes a username and password (over HTTPS) and generates an access token for the user. The access token is long lived and used to generate a much short lived Session token. User has to authenticate himself using this API and subsequent access to back-end services is authenticated with the session token generated.
Now with the advent of Fingerprint scan API, how do i handle user authentication. Remember I need to generate the session token at some point.
So What kind of use case design do i follow ?
Should it be like user has to login at least once after app installation with the username/password approach.on successful authentication the username and password is retained in persistence in an encrypted manner which in turn is protected by the Fingerprint authentication (this is like 2 level authentication if you consider it that way).
Any better suggestion from anyone who has come across similar use case in their app ?
Related question - Read somewhere, that the keystore stores the keys out of any specific app process. Is it possible for another app to read a key value if it somehow gets hold of the key alias i have used to save the key on the store ?
For an experiment I'd like to make it as convenient for the users as possible to submit their data. I figured a good way of doing this would be to create a dedicated dropbox account which is hardcoded into the app and allows the user to submit data without any account required for himself.
My question: Is there a way to obtain an access token from the dropbox API with just having username + password at hand (which would be hard coded into the app)?
What you are looking for is "service account" or two-legged Oauth. Unfortunately according to Dropbox they do not have it: https://www.dropboxforum.com/hc/en-us/community/posts/201943685-OAuth-2-0-Server-to-server-authentication
In this tutorial: http://aws.amazon.com/articles/3002109349624271 secret key is used during file upload.
I can't use secret key since my app users don't have amazon account and I can't share my amazon secret key to my app users.
I want to let users upload their avatars directly to S3 without passing through own proxy that has secret key.
I know that this is somehow possible for HTML 5 apps, but haven't find a documentated way for native SDK.
You can deploy a Token Vending Machine to generate temporary session keys for your users. Here's an example for an anonymous TVM.
Alternatively, you can use a framework like Filepicker.io which takes care of the authentication details for you.
I am trying to use the google oauth2.0 api in an android and wp7 phone app. My question is whether the "client secret" given by google while registering the app be hard-coded in the code(source code will be obfuscated)? (or) should I create a webpage that will have the client secret and authorize accordingly?
You can keep the key in the XAP, but you should be aware that anyone who really wants it, will get it. Even if it is stored on a server and obtained later through a request, it can still be intercepted. That being said, most of the applications in the Marketplace keep their app keys hard-coded.