Insecure Data Storage on Android Mobile Phones

October 15, 2015 | Views: 2582

Begin Learning Cyber Security for FREE Now!

FREE REGISTRATIONAlready a Member Login Here


Insecure Data Storage on Android Mobile Phones

What Does this Mean?

Today, cellular networks are becoming a vital element for exchanging the electronic data in low income countries. A problem arises: insecure data storage on mobile phones. This leads to theft of all important data from victims’ phones. I’m here to give a Solution for insecure data storage and transmission between the client and server in android. MDCS (Mobile Data Collection System) it’s a system to collect the data from the android mobiles and other mobile phones. When a user authenticated to access the certain application, the data and cookies and auto filling forms are stored inside the internal memory. When a hacker successfully hijack the victim mobile he can able to read the data stored inside the mobile and also he login with that data. This affects almost 99% of mobile in the world. This issue become a big problem for the industries dev.’s and bank apps dev.’s.

What’s My Opinion on Solving This Issue?

We can implement an encryption mechanism here. But already the solution applied to this problem, still it’s in risk. What’s that?  The developer think that the application data stored in the client phone is safe because of implemented encryption. So they decided that the data can’t able to read unless he connects to the server and login with his password and Id.  But the hacker cracked this encryption mechanism by rooting or jail breaking his phone, he can able to read the data in respected form. The automated software’s use the brute force and hash decryption method to break the encryption. But my idea is why we can apply the latest encryption technology like SHA (Secure Hash Algorithm) and MD5 encryption. What’s the problem with this? The android supports only the JAVA ME. By  the high encryption leads to unsupported apk for older version mobile. In order to achieve this we have to prepare an intermediate authentication by the application.


IEEE Conference Proposed Solution and Its Complexity

OPEN x DATA. This the solution given at the IEEE conference. This stores the application data and transmitted to the server .This application stores the data with encrypted format and hence it can be accessed by only the authorized person know the password. When a successful key is transmitted the application connects to the server. The problem with this auto form filling method and also every time opening the application, we have to enter the password. This take efforts for all apps in the mobile phone. A solution given by IEEE, that’s is EK-encrypted key to login to the application (i.e. this key for opening the encryption and if fails showing error message), when successful key is accepted by the openxdata application it opens the server and connects the client. This take time complexity and seems to be not user-friendly to the users. But the solution is strong to transmit the data in encrypted format and also very efficient way. But openxdata stated that it will accept the all API level, but in some case it won’t support for outdated version of android.


My Final Simple Solution for Kinds of Data Storage and Transmissions

Instead of storing the app data in the mobile internal memory, better store in the application supplicant database. Only the user needs the user id and password, with this method the data stored in the  server side storage. When the successful authentication is done, then only the application features must enabled there. If there is a necessary to store the data in user memory then implement the third factor authentication in case there is a detection of brute force methods handling then set a session out time and if fails in three attempts, warn them and make a time delay there. When hacker successfully copy the application data, set MAC authentication and if fails keep a fake self-destroying message and email a message to the authorized user. All this implementation is in the programmer’s hand. If effective program is handled then this method won’t need any costly and high API level configuration phones. When an application data stored in the internal memory of the phone, the EK( encrypted key should be authenticated by connecting the application to the server with the with correct user name and password ) else the application data should encrypted with high hash algorithms. The server connects the application data handler with https transmission medium only.


Your suggestions are welcome at:

Share with Friends
Use Cybytes and
Tip the Author!
Share with Friends
Ready to share your knowledge and expertise?
  1. Actually disagree…

    Cookies are to do with session management to keep a session alive across multiple webpages (either tabs or when changing pages. An application can handle this differently depending on API used. However MAC authentication is actually fairly easy to spoof, and if its an offline hack, there are not connections available to send the mail, assuming that the hack is even on the correct device.

    And as for data…

    “Instead of storing the app data in the mobile internal memory, [its] better store in the application supplicant database”… “with this method the data stored in the server side storage”

    Depending on the attacker, and the application, this is a poor option…
    To make things easy, lets assume that the data is mobile only (can’t be read on the web site)

    Problem 1). Writs, layers and lawful access.
    If all the data is at the server, the server can be seized or served. Depending on the jurisdiction or the location of the company owning the server (cough Microsoft being sued by the DOJ over data held on an EU server cough) the the data is accessible. If this data is sensitive, it may not be something that the creator of the data (owner is a legal issue at this point) does not want off their phone.
    If the data is safe and encrypted on a disposable medium (there goes the SD card, there goes the phone, the shredder accepts all gifts) should there be a copy of the data online?
    The OpenX Data solution – the key is not on the server… so it can’t hand over decrypted data (if I’m reading it correctly that is)

    Problem 2) All the users eggs in one basket.
    Blackhats exist, and probably read this. Sites and databases get hacked.
    Hello Ashley Madison database dump.
    The OpenX Data version… the data stolen is encrypted.

    For the above issues, the data may be required at the server anyway, so all of this is moot. Lets also assume the data is encrypted on the server, with the only key being generated stored on the device.

    If the key is not on the device, then its stored on the server (with the same problems as above). If the key is generated from the username AND password, changing the password should trigger an decryption and re-encryption.

    With all of that out of the way, what you seem to outline is something fairly close to a streaming of encrypted data model used for DRM. The catch with DRMed material is that the data has to be available in a part of memory in the clear for *something* to read it. Even if there is a third factor used for getting access to decrypt the data, the device where the data can be read is the same device which is being monitored. (i.e. You need to show the movie to the viewer on the same device that is not trusted).

    This works great for data not being manipulated in some way, streaming plays and deletes a chunk of the data, but I’m not sure about data to be retained (e.g. profile information).

Comment on This

You must be logged in to post a comment.

Our Revolution

We believe Cyber Security training should be free, for everyone, FOREVER. Everyone, everywhere, deserves the OPPORTUNITY to learn, begin and grow a career in this fascinating field. Therefore, Cybrary is a free community where people, companies and training come together to give everyone the ability to collaborate in an open source way that is revolutionizing the cyber security educational experience.

Support Cybrary

Donate Here to Get This Month's Donor Badge


We recommend always using caution when following any link

Are you sure you want to continue?