I want to know how safe it is to pack the database with the application in android. Can the database be easily accessed by the users? As the database that I have will have data which I dont want to be hacked by users for misuse, what is the best way to protect the database in mobile apps?
Also my application would use web service(contacting my own website) e.g. http:\www.mysite.com/services/xxx
My site will in turn return some data to the mobile app. If someone decompiles the java code(in apk), he will easily get access to the URL i am using for web service. How can i protect my data on website to be attacked by malicious users. If anyone gets to know the URL, he can simply type that URL in browser and get all data in json format which i dont want as that data can be quite sensitive. Even if I keep it encoded, then the user can get to know the encoding from the java code(which he gets after decompiling apk).
How to keep my DB safe from being misused?
If my application is to show the local places like restaurants, bars etc on mobile should i always fetch them from the website using web service or provide a local database with these details so that information can be fetched quickly. In this case , I can provide a UPDATE web servcie which will update the local database. But security of local DB is of great concern to me.
Can anyone please suggest where to keep the DB and how to safeguard it?
Rgds,
Sapan
Local databases and your apk file can be read by any rooted device easily. This tool can even decompile your resources as explained in this youtube tutorial (I never tried that myself actually).
So you would have to store your data encrypted in your database and decrypt it form your application code to be sure that noone can access it by simply getting the database form the data directory of his device.
You shouldn't put your sensitive data (like passwords etc) in the resource folder, because it can be decompiled, put it in your code.
Now some words to your JSON API. Hiding the URL is not enough, since the user can track your requests easily by a sniffer and get that anyway. You should provide a authentication mechanism to protect unauthorized access and also protect your communication by SSL. (E.g. using HTTP authentication - makes only sense when your server provides SSL.)
This are the things you should think about and decide yourself how sensitive your data actually is.
As far as I understand you're going to:
Pack initial DB in your APK file (say with res/asset folder)
During first run explode DB file from res/asset to application data folder
Then from to time fetch data into DB from website/webservice
In this case there are basically 2 vulnerabilities (stored data I mean):
Initial DB image, since it's packed with APK (which is in real life just ZIP archive), so anyone can unpack and see what's packed in your DB
DB file stored in application data folder (usually /data/data/MY_APPLICATION_PACKAGE/databases). This folder is accessible on rooted device, so again your data can easily be screened
The only option to be secured is to encrypt your database content. Easiest way to do it to store sensitive data in BLOBs (in form of XML of JSON) and encrypt/decrypt those BLOBs after/before actual usage of certain records.
Myself personally did it in my app - and it works well.
check this links for protecting your apk file for decompile
How to make apk Secure. Protecting from Decompile
Protecting Android apk to prevent decompilation, network sniffing etc
decompiling DEX into Java sourcecode
Related
I have a problem. I am using xyz.db file and which is stored in asset folder. I am copying all data from xyz.db to application db which is stored in data/data/com.xyz/abc.sqlite in storage folder. Now I want to secure asset's xyz.db file. Because It can be easily extract from apk by reverse engineering. Please help me to secure my asset folder's database file.
You can perform the following to make it relatively difficult to access data in DB.
Password protected zip file to contain db which at runtime should be extracted.
Encrypt the file with symmetric key and again at runtime decrypt it.
Utilize sqlcipher that performs encryption for Data at Rest.
In both the above cases you will need to worry about storing the password or key. There is no sure shot way to protect the file but the above would require more effort and should be added as basic protection.
There's no final solution to your problem.
Any technique you'll use can be beaten by a determined skilled attacker.
You have to accept that if you want to store database xyz.sql in your apk file and you later want your app to use it, then it will be also possible for someone that reverse your app to retrieve it. Basically just because the plain text information at a certain moment will be available on the phone.
Hope i've been clean enough
Keep security in mind
As usual in Android the access rights of the database file determine who can use your database. If you follow the standard way presented in the following posts of this series, your database file will be located within the private directory of your app. This means that your app owns the database file and no one else can access it. Even using the other less common ways to create the database you can only grant access to the file. Thus others can access all of your database or nothing. There is no middle ground.
Still: You should never rely on data being safe from prying eyes in the database. Any sensitive data should be encrypted. Very sensitive data should not be stored on the device at all. Keep in mind that if the device gets lost, any misbehaving finder of the device can gain access to the database file as well as to your app. On a rooted device all files can be read. Apps like SQLite Editor make it easy to read even sensitive data – if they are not encrypted:
In cases where data privacy is of utmost importance, you have to revert to secured services or force the user to enter a secret every time before encrypting and storing the data or reading and decrypting them respectively.
source
I want to write an android application that uses ready information I use Sqlite manager extension from Firefox and put it in asset folder but if someone just change the extension and make apk file a zip file he can easily have my database what is the best solution in this case?
The comments you are getting are all completely correct. There is no way to guarantee that no-one can get at the contents of that database.
You could make it harder by encrypting the database and hiding the key somewhere in the code. Doing that would make it so that an attacker would need to de-compile the code to find the key, so that they could de-crypt the DB.
Better yet, you could put the key on a network server, somewhere. If you do that, your user has to be on-line to use the app... and the attacker has to spoof your app and request the key to decrypt the database. ... but they can still do it.
This is the DRM problem. It is pretty much impossible to give attackers the encrypted content and the keys and still protect the content.
We have an Android application which stores its data in a local SQLite database; primarily for performance, but also to allow for working off-line (as we are often in areas with low signal).
At the moment, the data is stored in encrypted format (passed down from our web servers), but this in itself causes a performance issue, where for example, if we want to search records for a particular "surname", we need to decrypt ALL of the data, rather than using a straight SQL query, to include where surname='Smith'
We cannot (as it currently stands) store the data in a more friendly 'open-format', as it's possible to 'root' the device, take a copy of the MySQL database, open it and read the data.
Is there the means (perhaps someone can provide an example) to either password protect the local SQLite database or somehow apply encryption, so that we can (from an application perspective) have the database available in open format, but so that if any would-be hacker got hold of the device and rooted it ... they would have a hard time reading our data?
I have searched for a suitable solution and cannot find any options for the SQLite database, any 3rd party software or any examples of code that do this.
SqlCipher, this will might work in your case
Remote Storage:
Your data is sensitive and needs to be accessed by the user on the go from different devices. If your app is a good one then the above line will hold true.
Security + Remote access from any device says you maintain your dB on a remote server.
Your flow can be :
User login --> Token --> Auth Token in every call --> Process request and get/put data in/from dB
Local Storage:
Let's say that you only want to store data locally and don't want to store it on the server. For this you can use public-key cryptography
You can use a public Key in your app to encrypt the data and store it. Now, you want to access the data. Request the private key from the server and decrypt it.
Again, to get access to private key you should use some form of authorization (or anyone can access your key).
Without the private key, even if a hacker roots the phone and gets his/her hands on the dB, the data would be useless.
I have to develop an app both for iOS and Android. This app uses a small sqlite database with sensitive data, and depending on the user's input, it makes some process with this data. After this process is made, the database is no longer accessed unless the user has to enter a new input (it's not probable that this happens).
Since the database has sensitive data I have to protect it. I know is impossible to get a complete protection but I would like to make life harder for a possible attacker.
And since I don't know too much about security I'm not sure what would be the best alternative taking into account "difficulty / security".
I've thought in two alternatives:
1) Include the database in the apps and encrypt or obfuscate it.
But I guess it wouldn't be very difficult to get the database with a rooted Android.
2) Have the database stored in a server, each time the user enters the input the app downloads the database, the process is made and after that I remove the database from the app.
But the process takes 5-10 minutes and maybe this time is enough to get the database from the app, so I would have to add the same protection as in 1) plus a protection in the server.
Which would be the best option (difficult / security)? There would be any other options?
I've tried several Google searches but I'm confuse with all that information and I would like to try with the huge acknowledge of this community.
UPDATED:
Well, reading your answers I'm inclined to have a backend and not download the database to the app. It's not the preferred solution of the client, but it seem is the best by far so I'll try to convince it.
Anyway, due to the type of process the app has to do I'm not sure if it's possible with a backend.
Since it's a complete different question I would like to ask it in other thread: https://stackoverflow.com/questions/29942688/remote-sqlite-queries-from-app
NEW UPDATE:
I keep thinking in this and I don't find a good solution because the process is too complex. I've thought in something I would like to know if it's possible or if it has no sense (sorry but I don't know too much about backend development).
SERVER -> my sqlite database & PHP web services
DEVICE -> a txt file with user inputs (20MB)
Device: In the device the txt file is compressed (10MB)
Device: The app send the txt file to the server via POST web service.
Server: This txt file is stored in the server.
Server: This txt file is decompressed.
Server: This txt file is loaded into a new table InputTable inside my sqlite database.
Server: A new table UserFinalDataTable (almost 10000 rows) is created making lots of queries using InputTable and the rest of my database.
Server: UserFinalDataTable is converted into JSON and sended back to the device as the response to the web service called in step 2.
Device: The app receive this JSON and converts it to something useful for the app.
Is this possible or any (if not all) of the steps is impossible to achieve?
The most secure and reliable way is to store the database on your server encrypted with a symmetric encryption algorithm. Better yet if you also use an asymmetric encryption algorithm on top of that, if possible with some sort of forward secrecy, in case your server gets hacked. It all depends on what degree of security you want to achieve.
Another way would be to store the database on the device with the server's encryption key, when needed send the database to your server for decryption and return the decrypted output. Although this doesn't make sense in most situations, especially yours.
Neither. The most secure way is to keep the database on the server and access it only by webservice, with proper account authentication. If you send any data at all to a client, a sufficiently motivated attacker will get it. In the case of a whole database file, it would be trivial to root the device and read it. And if you encrpyt it, SQLite won't be able to read it (not to mention the decryption key would be local so easily reverse engineered).
The most secure strategy you say....backend server with a db and web service.
Use SQLCipher to encrypt your db.
It works either on iOS and Android
I'm making a simple GPA android app. The user can input their grades and class names for each semester. How would I then store each of these semesters so that they can always be pulled up in the app? I might also need to store random variables that are alone.
I've briefly looked at options such as Shared Preferences, Internal Storage, and others. What option is the best for my needs? Please explain why. Thanks!
Here is Explanation...
Shared preferences are good for storing ... an application's preferences, and other small bits of data. It's a just really simple persistent string key store for a few data types: boolean, float, int, long and string. So for instance if my app had a login, I might consider storing the session key as string within SharedPreferences.
Internal storage is good for storing application data that the user doesn't need access to, because the user cannot easily access internal storage. Possibly good for caching, logs, other things. Anything that only the app intends to Create Read Update or Delete.
External storage. Great for the opposite of what I just said. The dropbox app probably uses external storage to store the user's dropbox folder, so that the user has easy access to these files outside the dropbox application, for instance, using the file manager.
SQLite databases are great whenever you a lot of structured data and a relatively rigid schema for managing it. Put in layman's terms, SQLite is like MySQL or PostgreSQL except instead of the database acting as a server daemon which then takes queries from the CGI scripts like php, it is simply stored in a .db file, and accessed and queried through a simple library within the application. While SQLite cannot scale nearly as big as the dedicated databases, it is very quick and convenient for smaller applications, like Android apps. I would use an SQLite db if I were making an app for aggregating and downloading recipes, since that kind of data is relatively structured and a database would allow for it to scale well. Databases are nice because writing all of your data to a file, then parsing it back in your own proprietary format it no fun. Then again, storing data in XML or JSON wouldn't be so bad.
Network connection refers to storing data on the cloud. HTTP or FTP file and content transfers through the java.net.* packages makes this happen.
Considering this i suggest you to use Sqlite especially in your case.
Best luck
it depends on your need, some times you use all options in the same app,
for example : the best way to store grades and classes is using database, in android SqlLite database.
and for storing some variables values like username and password you just need to use shared preferences.... at least this is my policy in my apps.
SQLite will be the best for your scenario.
As you can create well formatted Tables with desired columns. Either you can use pre-developed database or you can create tables on the go.