Since start working in mobile space I find out that many developers do mistake when it comes to secure data properly. Many people who have very good security awareness take mobile security lightly. Couple of days ago I read an article where author shows how a bank app storing user information as plain-text. Majority of the mobile users consider their phone as a personal item. Developing application for a mobile environment is bit more sensitive and critical compare to PC environment. If an application is not properly designed it will not only reveal very sensitive information of users but also create a situation where your users will be unable to use his phone. So many apps available on market lack basic security features.
Followings are few features form IT security perspective every mobile app developer should concern about. So many of them will not only reveal user information but also drain battery and eventually users will be unable to use their device. These points I think are very important especially when developers are concern about his users’ data safety and privacy.
Battery Exhaustion
Oh! I haven’t told you guys what I like right? I love news. Not that in so details but I prefer listen or read current headlines. For me, day without news is like day without coffee. Anyway, for this reason I downloaded one of news app. Thought, it will be very interesting to read news even before I get up from my bed in early morning. Well, I have a Motorola defy usually my charge stay almost a day. That means around 12 hours. But just after installing that news app, same day my phone battery died at 3 PM. So, I thought maybe I talked too much that day. But after that day it keep happening and it seems like somehow my phone battery life get shorter or some sort of Star Trek power hungry bug start feeding on my phone battery. So I spent couple of hours trying to figure out what this phone is doing so significant that it has to finish its entire power source and I figure out out only thing is different, is that apps. So when I uninstalled that app everything went back to normal.
So what was wrong? What forced me to uninstall that app, I was eager to install earlier. It is not only about me, but also about other users too. Users will not be able to use an app if that one has battery exhaustion issue. Face is very simple; nobody wants to charge their phones two three times a day. So, how to solve this issue? Personally I do not believe there is a single solution for this problem. Combined with multiple solution will give a good result. Main focus should be reduce network communications, CPU executions, and display usages. Following points are useful, for reducing battery consumption.
• Sync only when phone is connected to a charger or a high speed network or both.
• Cache already downloaded items ex images, text.
• Limit number of network thread.
• If you are planning to get a wake lock think twice.
• Careful about services, receivers or other programs designed to run in background and require extensive amount network, display or CPU.
• Write optimized java code. for some advance technique please follow this link
Insecure cryptographic storage
Some of us take software security very tightly. We secure user data with high bit encryption but when it comes to the point of securing cryptographic token we kind of get loose. Ok let’s go back one step, cryptographic storage means the place where we store our authentication token, crypto token or other security information for future communication. For example, after being verified by a web service (Twitter, Payment gateway etc) server will send a cryptographic token and we need that token for all subsequent communication. Based on request type this token can be for short period or for long period. Whatever the life period is we will try to store that token somewhere. This type of error usually happened when proper safeguard is not taken while program store those tokens. Problem here is that, as authentication system is based on that security token and access to that token simply means that access to all information and impersonating someone from another system will not be a big problem. So, how to secure an authenticated token? One good way to resolve this issue is encrypting security token before writing and decrypting them before reading. All communication from device should be encrypted using present days technology. There is nothing called 100% security in IT security but still we have to take proper measure for user safety, security and privacy.
Unsafe handling of user data
User data could be anything, his name, DOB, SSN or any other sensitive information what is important to user. Usually unsafe conditions occur over communication channel or on device.
Most on device unsafe cases are related to storage policy. This type of scenario can be avoided by choosing a safe way to store user data on device. For example on Android, Shard preference is designed to share information between multiple apps. That means those data are basically expose to others. For example getSharedPreferences(int mode) will give you a shared preference to work with. Please, careful about the mode, set the mode to appropriate level based on your requirement. And, again please do not use shared Preference or Content Provider for storing sensitive information. I know, I know they use SQLlite at the back-end. Things are pretty much same when we store information in SQL Lite database as plain text. And, please never ever store sensitive information as plain-text and for god’s sake do not try to decrypt/encrypt a movie file.
On communication, flaws occur over the communication channel. I will not discuss anything about network security coz there are already millions of books articles in market about it and Android issues are pretty much same as others.
Resolving all these entirely may not be possible but at least we can take some measures to make an attacker life bit interesting. If possible pick standard crypto algorithm to safeguard user data. Make sure that data stored as cipher text is not tempered later by a third party program. If you are not very good with encryption decryption system do some clever stuff to hide data. There are so many things you could do besides running a 1000 bit(!!!) encryption algorithm.
1. encoding/decoding
2. Hiding inside an image.
3. Shift characters. if shift value is five ‘A’ will be ‘E’ or ‘B’ will be ‘F’.
External vs. internal storages
External Storages, the one we commonly known is SD card. Is this wrong to store information on external storage? Absolutely not. Moreover, there are some good things about storing information on SD card. Like, if the data is large then there will be always some space to accommodate and if we take entire space it will not create problem for other application or OS. But there is couple of security issues we have to take care when we pick SD card.
On other hand internal storages are safe easy to handle. But.., it is basically a big “BUT” when we talked about internal storage. Internal storages are usually small in size and there are too many things it has to store. For example majority of the apps downloaded on internal storage, CPU uses internal storage for execution. Bad thing is that if apps required space more than few megabytes for data probably it is better to choose available external storage. I remember one case, where I have to deal with a huge database and I was constantly getting low memory warning after copying entire database on internal memory. So think like the scenario when our apps and other hundred apps are in the same space and then app start taking additional spaces. User will figure out something is very wrong and then he will uninstall our app or set the phone to factory settings.
If we want to share data with other third party apps or systems probably better to use internal space. But again everything is a design issue. Another important thing is that internal storage is safeguarded by Android platform and if somehow someone able to bypass this security feature it will be easy for an attacker to access user private data. For example, phone rooting. Lots of information is out there for how to root a phone and it is not so complicated task even.
From IT security perspective internal storage is a good choice. Coz you app will get at least the security features provided by framework. So I say try to pick internal space but again try to be on your own.
String literal
What’s bad with string constant? Think about the case where bank sent us an ATM card and PIN on same package. It is like encrypting something and later sending cipher text and password at the same package. Basically, it is very easy to retrieve original text, from binary by using a decompiler. There is lots of decompiler existing for android and they are getting better every single day.
Check out the following Android code later its decompilation output. I used apktool for this.
So when I use that decompiler I got the following output.
if we take a close look we will see all string literals basically easily readable after decompiling. This is not bad as long as we do not hard code our password on the source file. Consider like this, one dumb developer receive authentication token from a site and after being verified by server, he encrypted his token using 256 bit AES . So whenever he is writing that encrypted token, he is basically encrypting and decrypting using same password or I would say same string literal. Ok forget now about user’s token think of encrypting users’ sensitive information with a hard coded password.
Oh!, information is still retrievable by a decompiler if we put the string on an Android resource file (string). Code obfuscator is good way to handle it but not a guaranteed way.
At the end, it is also very important that where ever we store information we secure sensitive data. By the way Android has a crpto engine which supports so many different crypto algorithms and if we want more variety of crypto algorithms this link will come real handy.
Followings are few features form IT security perspective every mobile app developer should concern about. So many of them will not only reveal user information but also drain battery and eventually users will be unable to use their device. These points I think are very important especially when developers are concern about his users’ data safety and privacy.
Battery Exhaustion
Oh! I haven’t told you guys what I like right? I love news. Not that in so details but I prefer listen or read current headlines. For me, day without news is like day without coffee. Anyway, for this reason I downloaded one of news app. Thought, it will be very interesting to read news even before I get up from my bed in early morning. Well, I have a Motorola defy usually my charge stay almost a day. That means around 12 hours. But just after installing that news app, same day my phone battery died at 3 PM. So, I thought maybe I talked too much that day. But after that day it keep happening and it seems like somehow my phone battery life get shorter or some sort of Star Trek power hungry bug start feeding on my phone battery. So I spent couple of hours trying to figure out what this phone is doing so significant that it has to finish its entire power source and I figure out out only thing is different, is that apps. So when I uninstalled that app everything went back to normal.
So what was wrong? What forced me to uninstall that app, I was eager to install earlier. It is not only about me, but also about other users too. Users will not be able to use an app if that one has battery exhaustion issue. Face is very simple; nobody wants to charge their phones two three times a day. So, how to solve this issue? Personally I do not believe there is a single solution for this problem. Combined with multiple solution will give a good result. Main focus should be reduce network communications, CPU executions, and display usages. Following points are useful, for reducing battery consumption.
• Sync only when phone is connected to a charger or a high speed network or both.
• Cache already downloaded items ex images, text.
• Limit number of network thread.
• If you are planning to get a wake lock think twice.
• Careful about services, receivers or other programs designed to run in background and require extensive amount network, display or CPU.
• Write optimized java code. for some advance technique please follow this link
Insecure cryptographic storage
Some of us take software security very tightly. We secure user data with high bit encryption but when it comes to the point of securing cryptographic token we kind of get loose. Ok let’s go back one step, cryptographic storage means the place where we store our authentication token, crypto token or other security information for future communication. For example, after being verified by a web service (Twitter, Payment gateway etc) server will send a cryptographic token and we need that token for all subsequent communication. Based on request type this token can be for short period or for long period. Whatever the life period is we will try to store that token somewhere. This type of error usually happened when proper safeguard is not taken while program store those tokens. Problem here is that, as authentication system is based on that security token and access to that token simply means that access to all information and impersonating someone from another system will not be a big problem. So, how to secure an authenticated token? One good way to resolve this issue is encrypting security token before writing and decrypting them before reading. All communication from device should be encrypted using present days technology. There is nothing called 100% security in IT security but still we have to take proper measure for user safety, security and privacy.
Unsafe handling of user data
User data could be anything, his name, DOB, SSN or any other sensitive information what is important to user. Usually unsafe conditions occur over communication channel or on device.
Most on device unsafe cases are related to storage policy. This type of scenario can be avoided by choosing a safe way to store user data on device. For example on Android, Shard preference is designed to share information between multiple apps. That means those data are basically expose to others. For example getSharedPreferences(int mode) will give you a shared preference to work with. Please, careful about the mode, set the mode to appropriate level based on your requirement. And, again please do not use shared Preference or Content Provider for storing sensitive information. I know, I know they use SQLlite at the back-end. Things are pretty much same when we store information in SQL Lite database as plain text. And, please never ever store sensitive information as plain-text and for god’s sake do not try to decrypt/encrypt a movie file.
On communication, flaws occur over the communication channel. I will not discuss anything about network security coz there are already millions of books articles in market about it and Android issues are pretty much same as others.
Resolving all these entirely may not be possible but at least we can take some measures to make an attacker life bit interesting. If possible pick standard crypto algorithm to safeguard user data. Make sure that data stored as cipher text is not tempered later by a third party program. If you are not very good with encryption decryption system do some clever stuff to hide data. There are so many things you could do besides running a 1000 bit(!!!) encryption algorithm.
1. encoding/decoding
2. Hiding inside an image.
3. Shift characters. if shift value is five ‘A’ will be ‘E’ or ‘B’ will be ‘F’.
External vs. internal storages
External Storages, the one we commonly known is SD card. Is this wrong to store information on external storage? Absolutely not. Moreover, there are some good things about storing information on SD card. Like, if the data is large then there will be always some space to accommodate and if we take entire space it will not create problem for other application or OS. But there is couple of security issues we have to take care when we pick SD card.
- External storage is usually removable that means it can be plugged into a desktop or laptop. So an attacker will get more flexibility to analyze data.
- It is not protected by platform and so it is our responsibility to come up with our own protection plan. We need two different type of protection plant one we don’t want someone to read, so encryption, and we have to make sure stored data is not tempered after we wrote them, so a hash like algorithm.
- When app is removed/uninstalled data is not removed.
On other hand internal storages are safe easy to handle. But.., it is basically a big “BUT” when we talked about internal storage. Internal storages are usually small in size and there are too many things it has to store. For example majority of the apps downloaded on internal storage, CPU uses internal storage for execution. Bad thing is that if apps required space more than few megabytes for data probably it is better to choose available external storage. I remember one case, where I have to deal with a huge database and I was constantly getting low memory warning after copying entire database on internal memory. So think like the scenario when our apps and other hundred apps are in the same space and then app start taking additional spaces. User will figure out something is very wrong and then he will uninstall our app or set the phone to factory settings.
If we want to share data with other third party apps or systems probably better to use internal space. But again everything is a design issue. Another important thing is that internal storage is safeguarded by Android platform and if somehow someone able to bypass this security feature it will be easy for an attacker to access user private data. For example, phone rooting. Lots of information is out there for how to root a phone and it is not so complicated task even.
From IT security perspective internal storage is a good choice. Coz you app will get at least the security features provided by framework. So I say try to pick internal space but again try to be on your own.
String literal
What’s bad with string constant? Think about the case where bank sent us an ATM card and PIN on same package. It is like encrypting something and later sending cipher text and password at the same package. Basically, it is very easy to retrieve original text, from binary by using a decompiler. There is lots of decompiler existing for android and they are getting better every single day.
Check out the following Android code later its decompilation output. I used apktool for this.
public class hello extends Activity {
/** Called when the activity is first created. */
static final String str1="This is static final String";
final String str2="This is only final string";
String str3="This is only string";
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
String str3="This is internal string";
}
}
So when I use that decompiler I got the following output.
package com.test.blog; class hello {/*
.class public Lcom/test/blog/hello;
.super Landroid/app/Activity;
.source "hello.java"
# static fields
.field static final str1:Ljava/lang/String; = "This is static final String"
# instance fields
.field final str2:Ljava/lang/String;
.field str3:Ljava/lang/String;
# direct methods
.method public constructor ()V
.locals 1
.prologue
.line 6
invoke-direct {p0}, Landroid/app/Activity;->()V
.line 9
#p0=(Reference);
const-string v0, "This is only final string"
#v0=(Reference);
iput-object v0, p0, Lcom/test/blog/hello;->str2:Ljava/lang/String;
.line 10
const-string v0, "This is only string"
iput-object v0, p0, Lcom/test/blog/hello;->str3:Ljava/lang/String;
.line 6
return-void
.end method
# virtual methods
.method public onCreate(Landroid/os/Bundle;)V
.locals 2
.parameter "savedInstanceState"
.prologue
.line 13
invoke-super {p0, p1}, Landroid/app/Activity;->onCreate(Landroid/os/Bundle;)V
.line 14
const/high16 v1, 0x7f03
#v1=(Integer);
invoke-virtual {p0, v1}, Lcom/test/blog/hello;->setContentView(I)V
.line 15
const-string v0, "This is internal string"
.line 17
.local v0, str3:Ljava/lang/String;
#v0=(Reference);
return-void
.end method
*/}
if we take a close look we will see all string literals basically easily readable after decompiling. This is not bad as long as we do not hard code our password on the source file. Consider like this, one dumb developer receive authentication token from a site and after being verified by server, he encrypted his token using 256 bit AES . So whenever he is writing that encrypted token, he is basically encrypting and decrypting using same password or I would say same string literal. Ok forget now about user’s token think of encrypting users’ sensitive information with a hard coded password.
Oh!, information is still retrievable by a decompiler if we put the string on an Android resource file (string). Code obfuscator is good way to handle it but not a guaranteed way.
At the end, it is also very important that where ever we store information we secure sensitive data. By the way Android has a crpto engine which supports so many different crypto algorithms and if we want more variety of crypto algorithms this link will come real handy.
No comments:
Post a Comment