Is it possible to build app whit integrated dropbox acc, and use this account for all clients? I want to upload images to dropbox, and all client apps can download it, or upload to this acc from my app?
I have read all dropbox sdk tutorial from there site, but steal not sure if this is possible.
Not really. DropBox uses OAuth for authorization to allow users to login with their own accounts. Even assuming you figured out how to log in on their behalf with your own credentials you would be handing out your credentials to anyone who wants them, allowing someone to change the password on the account, etc.
Alternatively I suppose you could generate tokens and hand those out instead, however you'd have to setup some sort of web service for this, and you'd still have problems with people being able to do stuff to your account that no doubt you don't want them to do. E.g. I could create an app that just instantly deletes everything that anyone uploads, or I could create an app that fills up your quota with files filled with zeroes.
This is not what DropBox intends you to use the API for (and in fact it may be against the ToS, you should probably read to make sure if you're going down this route despite my discouragement). You should use a more appropriate storage method.
Related
If someone wanted to reverse engineer my android application by getting the apk file and then customising it to do other things that it shouldn't do. Keeping in mind that the apk file will have the google-services.json file that we download from firebase when we create the firebase project to link the android app.
The question is:
Even though there is security rules on the real time database or firebase storage that only allows authenticated users. Then the hacker can reverse engineer the app and makes his own application that has the same google-services.json file and then when compiling the hacker can create an account and login to the app (which makes him authenticated) and then maybe he can delete and write data to the real time database.
Can someone please explain how the security holds then?
In general, you should assume that any code that you ship to a customer could be compromised. You should assume that the device that they're running it on is under their full control, and that they could change the way your code executes on that device. The issue isn't so much that your app gets decompiled, it's that you simply can't control the execution environment in any way (unless of course you manufacture the device and have built in your own hardware security).
The data in google-services.json is not private data. You should assume that the moment you publish an app, everyone will know all the information in that file. Think of that data as unique identifiers that tell your app where to get data. There are no passwords or credentials in that file that allow an attacker to do anything that you have not authorized them to do.
It's up to you to use security rules in conjunction with Firebase Authentication in order to control who can do what to the data hosted in Firebase. It's impossible to stop people from creating random accounts in your app, but it's possible to restrict what they can do.
If you find that your app is subject to some form of abuse, you can shut down the abuser's account, and also contact Firebase support to report abusive behavior.
I asked myself the same situation couple of months back.
As I understand, the moment you generate your project ( Creating it from Firebase console or Android studio) it will ask for a SHA-1 key.
This SHA-1 key is unique and serves as the authorization from your project to connect to the services of Firebase, for example, if a user has your google-services.json it will be hard to them to even log in or authenticate without a SHA-1 key that allows them to use your project.
I was also inspecting the google-services.json and there is the SHA1-1 with the package names.
"android_info": {
"package_name": "com.packagename.debug",
"certificate_hash": "SHA1-KEY"
}
If you need to add a new SHA-1 you will also need to either authenticate using Gmail to go to the Firebase console and add it yourself (in which case is nearly impossible that a hacker can access to your Gmail account) or do the same thing from Android studio and sync the project.
As I said before, this is how I understand this situation, also, little research from securing API keys told that you need to be worried about client-side APIs than public APIS in your app.
The thing is that encrypting client side your APIS exposes the encryption code and can be decoded to, this is why sometimes it will be better to run some sort of a function from Firebase and send the sensible APIS to your project.
Telling it again, I'm answering with how I understand it works from having and inspecting the projects that I have, this is not an official answer so take it with tweezers.
Im developing an android application for the first time (no prior experience whit coding....). Mainly the app is going to be used at work as a tool for service technicians. The app is almost ready for field testing, but there is one thing i need the app to do before that. I need the app to force the user to log in every time its opened. This is because some of the info on the app is confidential, and only people that currently works for the company is allowed to have this info. Whit firebase i can then block the users that leave the company, or users that are not verified. Currently the users sign in whit google and they stay signed in until they clear the app data or delete it.
I have looked far and wide for the answer to this, but i have only come across different use of timers.
If anyone has a better solution to this "safety" issue, im open to anything.
If you are using Google Sign-In for authentication, there is no out of the box support for forcing your user to authenticate with Google every time they use your app.
This makes sense, because the user is still authed with Google on your phone. A login system only authenticates the user; it doesn't inherently protect data stored on the device. As long as Google has a valid access token, the user won't have to type a username and password again (and simply clicking "login with Google" again doesn't really provide extra protection here).
If your primary concern is blocking access to users who have left the company, you should be covered if you are using Google Apps for your company. If you disable the user's account, their access tokens should become invalid. Google Apps admins can also manually revoke access to specific apps for specific users.
If you don't use Google Apps (e.g. your users are using #gmail.com accounts or accounts from a domain outside fo your control), you might want to consider implementing a list of users allowed to access the application, and verify the current user has access by checking that list via an API call on launch.
If the goal is really protecting the confidential information in the application, you might want to take an approach similar to Android Pay in which you require your user to set and enter a PIN number to access the application. As an added benefit, you can then use that PIN to encrypt any confidential data you are storing locally.
I will suggest you take a look into shared preferences and every time when the user is back into the app you send them to the login activity.
I'm making a Cordova 4.0 Android app that will be sold in Google Play, and I would like to prevent illegal use of it (for example preventing someone to extract the APK from the system and re-distributing it).
One theoretical way of doing this would be by checking that when the app is launched by the user, he did actually download it from Google Play (versus being it sideloaded). I'm not even sure if this is possible or if there's an alternate way of doing something like this.
One way that works in other cases is to use require some sort of login when accessing the app, but in this case I can't do that. Any advice would be appreciated!
Google offers a way to implement validation / licensing:
http://developer.android.com/google/play/licensing/index.html
Take a look if this is what you need!
One suggestion would be for those apps which are get connected to a server to fetch some data.
App verification token
Generate an encoded 64-bit long token and store on both device & server as well. This will be a unique token per app
Whenever app tries to connect to server, it sends the device token details. Server needs to verify it before fulfilling its request.
On specific events, server can generate a new token for a device.
Same way, device token can be mapped to a user or an app on the server side.
Token could carry some app related information, for instance.
first 4 or 6 digits represent app size
second block of digits could represent user specific or device or some other details
Or another block could hold app contents modification date
In case of any change, server could verify the app size, last app contents modification dates, etc.
Generally it is recommended to uglify, obfuscate and minimize app resources before submission.
You can use the package manager class to determine the source of an app (only google or amazon currently detected)
You can similarly use google analytics which gives same information.
This is pretty neat since Android stores the source of every package, allowing apps to know where they came from, to prevent piracy and sideloading.
Great if you always publish to google or amazon. Useless if you sideload your app.
This past week I've inundated myself with links and led myself in too many circles to count, so I thought I'd pose the question here. I have an Android app that displays webviews pointing to urls which the user must be signed in with their Google account to see (the backend is built in Google App Engine). Since the end user is likely to be signed into their Google account on their Android anyway, I'd like the sign-in process to be automatic. Currently, on the first webview the user opens up they are presented with the Google sign-in form and a really ugly subsequent page asking "would you like to allow example.appspot.com to use your Google account?"
That process is dreadful for user experience. I've seen precious few resources here and there concerning auto-login, but I'm frankly lost in the sea of almost-what-I-want-but-not-quite to be able to discern the direction I ought to be going.
I read through Nick's tutorial on authenticating an app with App Engine, but just having the token doesn't get me the uniquely-assigned user ID associated with every Google account on the backend. On top of that, prior experience has taught me the hard way that an app's webview session is incongruous with the app's HTTPClient session. So even if I could log in with Nick's method it wouldn't help me sign into the webviews.
Then I came across this tutorial, which actually seems really promising, but so far I haven't been able to adapt his code to work with my own.
I also found this SO link which suggests that all I need to do is pass the auth token (which I could presumably obtain via Nick's method) into every webview I load as a cookie.
And that's about it. They are all rather different approaches, so I'm wondering if any of them are actually what I want. Or, if somewhere out there a reasonably simple approach actually exists. I'd really appreciate it if someone knows of a straightforward answer on this one. Thank you!
For security reasons WebViews do not have access to the phone's cache, cookie store etc, it is instead recommended you use the new Chrome Custom Tabs which can auto log in your users.
Concerning the "would you like to allow example.appspot.com to use your Google account?" screen; this is the standard OAuth process and requires that the User sign in and allow your app to access their account information.
In your 'example.appspot.com' App Engine app, if you are using an API that requires user information, like the Google Calendar API, it is required that you specifically request the User for their approval to access this information.
Once you have their approval, you can then save the access and refresh tokens to make future API calls on their behalf without the need for repeated user consent. You can see how the entire Oauth flow works in the OAuth 2.0 Playground.
Even if you automatically logged your user in, they will still see the approval page requesting for your app to have access to their information. To develop a hack to forcefully approve the access to a User's information on their behalf is a major security violation.
You can take a look at the new Firebase Authentication flow to easily manage your user's Oauth experience in your App Engine application.
I am planning to drop my app in Google Play(earlier Android Market) because of push notifications (whenever a new version) , security for apk and so on.And also since apk is secured with Google play(paid apks) i dropped of downloading the apk from my website (only authenticated people can download the apk)
Actually its a business app for particular users with username and login access. Everything was fine in the App with login and security mechanisms
I am thinking of a way to restrict the other users who are not from the list while installing itself.
My question is whether any kind of filter or authentication mechanism can we set while downloading the application from the Google play it should ask for a password or something like this to filter the unauthorized users to download the app..
My ultimate aim is i don't want the peoples to try it after downloading unnecessarily
Can anybody help who have tried all those in android market
Ok.. One thing after another..
Google propose their licensing mechanism. However app would need internet connection, which is disadvantage if otherwise it doesn't need it. If I got it right your does need to connect to server so this is not a problem for u.. It seems to me you are already familiar with this method.
Mechanism for password protecting downloading or visibility of apps on Google Play doesn't exist today..
You can identify users with IMEI (in case you don't consider using app on tablets, which doesn't have it), WLAN MAC, BT MAC address or some exotic combination of these methods, and you use this as authentication.
The best solution, from my point of view, is to allow people on market to download it. Your application is already using some mechanism of authentication (user/password) to server. So if 1st thing user need to do is login, and any functionality is disabled if that doesn't pass. If it pass, you already know who is your user and what privileges he has.
The thing is here that I am not so sure what are your concerns when user without login/pass download application if everything after that screen is disabled before authentication. User will download (if they find it..), they will install, try to use it, see that's not possible without credentials and uninstall it.
Hope it helped.. I will try to add few more links in a while..