Android Question How to secure data in the event an employee phone get stolen or loss?

[aeric]

Assume I am developing an Android app for a client and the engineers are provided with the devices and app. In case an engineer lost the phone or the device get stolen, the company have concern that the data will be fall into wrong hands.
To convince the client, what I can do?

Here are what I can do:

1. The app requires login and token expires (become invalid) within certain period of time, let say 1 or 3 days? 30 minutes? Always logout when remove from recent app?
2. Encrypt certain columns in SQLite
3. Use SQLCipher
4. Self destroy database using firebase push notification
5. Self destroy certain tables in SQLite on app start if user no login for certain period eg 3 days

Any more practical ways?
Please comment and recommend ??

 

[JohnC]

It depends on how much effort you think the "finder" of the phone will do to gain access to the data.

If they will put in little effort, then you don't need to modify the app and just make sure the phone has auto-lock (after x mins) enabled so the entire phone's memory is encrypted until the proper owner unlocks it. (this assumes the database is not on an unencrypted SD card)

If they will put a lot of effort to break into the phone, then you have to assume the phone will be kept in airplane mode so they can take their time to break into the phone - so Push messages won't work due to lack of a radio signal, and they could also keep resetting the phone's date back, so "expired" codes wont work either.

So, the only solution I see is to encrypt the database (or just the important tables) and don't store the key in the app - the key could be downloaded from a server only after a proper user of the app logs in.

 

[AHilton]

Have you considered not storing the data on the device in the first place? A JIT (Just In Time) or JAN (Just As Needed) Data sort of situation.

 

[aeric]

Have you considered not storing the data on the device in the first place? A JIT (Just In Time) or JAN (Just As Needed) Data sort of situation.

Because the requirement to use the app in offline mode due to no mobile network inside factory area. I will consider to avoid storing any sensitive data.

 

[Alex_197]

you can encrypt a database with SQLCifer but where to store an encryption key?

 

[Alex_197]

Because the requirement to use the app in offline mode due to no mobile network inside factory area. I will consider to avoid storing any sensitive data.

That's exaclty my situation

 

[aeric]

you can encrypt a database with SQLCifer but where to store an encryption key?

SQLCipher does not need encryption key right?
Store in Process_Global

 

[Alex_197]

SQLCipher does not need encryption key right?

but it needs a password like a MS SQL database. Or you can encrypt a data inside a table - but where to store encryption key?

 

[JohnC]

You could make the key be based on the user's login password.

For example, lets say the user's password is "hAppy#3"

You could then create an algorithm that will generate a longer cryptic full key based on the users password.

Then encrypt the database using that full key.

Then you won't need to include the key in your code at all because it will be generated at run-time when the user logs in with their password.

It would be impossible for a hacker to figure out the key without knowing the password.

As a bonus, you can verify if a user's password is correct or not without having to put the correct password in your code or verify it using a remote service simply by seeing if you can properly read from the database after trying to unlock it (using the key generated from the user's password that was entered).

NOTE: This would require each user's database to be encrypted using a different key because each user has a different login password. But this shouldn't be a problem because if you ever need to sync the database with another database, you would simply perform the sync after the user logs into the app, so that the database will be properly unlocked.

 

[Sandman]

This might be relevant in the discussion.

 

[MicroDrie]

This might be relevant in the discussion.

View attachment 122766

Sandman this is indeed the diabolical dilemma. Therefore, you should start with the question, “What is the undeniable reason for storing that particular information?” It seems a simple question, but in practice it is very difficult to substantiate everything beyond a legal basis or a billing reason. Answering the question also leads to an efficiency boost, and what is not there cannot be stolen.

The second question to ask is what can a thief do with the irrefutably necessary information? If you establish the relationship between an order number and a customer outside the device, it will be difficult for a thief to trace customers from the stolen information.

 

[MicroDrie]

SQLCipher does not need encryption key right?
Store in Process_Global

I use SQLite-jdbc (download: https://github.com/Willena/sqlite-jdbc-crypt/releases) with which I create an encrypted database based on the requested database password. I store the password in a variable which makes decrypting the software of a stolen or lost device pointless. To avoid the chance of a corrupt database, I close the database after every read/write command.

With that password, I can view and modify the encrypted database with the database password in DB browser for SQLite. The disadvantage is the conflict that arises with the standard B4Xtable. I solved that by using https://www.b4x.com/android/forum/threads/b4x-xui-sd-flexgrid-table.100897/#content Excel solution.

 

[Intelemarketing]

Assume I am developing an Android app for a client and the engineers are provided with the devices and app. In case an engineer lost the phone or the device get stolen, the company have concern that the data will be fall into wrong hands.
To convince the client, what I can do?

Here are what I can do:

1. The app requires login and token expires (become invalid) within certain period of time, let say 1 or 3 days? 30 minutes? Always logout when remove from recent app?
2. Encrypt certain columns in SQLite
3. Use SQLCipher
4. Self destroy database using firebase push notification
5. Self destroy certain tables in SQLite on app start if user no login for certain period eg 3 days

Any more practical ways?
Please comment and recommend ??

Hi Aeric

Firstly, force a double verification of the user. When they log in ask for their password - Done. Then send a verification code to the user at their personal email address - which they retrieve (preferably on a different machine) and key into your app to unlock it. (Email will need some form of protection by way of password also). This step could be done just as the worker is about to enter the work area where there is no internet access. If you are able to set up a different machine, just for retrieving the verification code, this will guarantee that only valid workers can access your app, and they have to be at the correct place of work to do so.

Second, you automatically shut the app down if it is running outside of normal working hours - warning first - with ability to extend time only by sending a new unlock code to their personal email address. (If the app is used for different shifts then allocate shift hours according to User when they log in). Auto shutdown will force an operator to log in if they want to use the app again. (With Email verification).

Thirdly, and I am assuming that there is no Internet access inside the work area, if a worker decides to "steal" company secrets, and they leave the work area with the app running, it automatically shuts down. If Interent access is available outside the work area then the app could check for Internet access periodically (even as frequently as once every 10 seconds) to ensure that the worker is actually in the work area. eg, Check if you can access a paricular web site/ ftp site/ whatever. If you want to be more sophisticated, you could check the GPS location of the phone, knowing what is OK and what is not. (Considertion for toilet beaks apply).

Then you can choose to use your steps 1-5.

 

[aeric]

Hi Aeric

Firstly, force a double verification of the user. When they log in ask for their password - Done. Then send a verification code to the user at their personal email address - which they retrieve (preferably on a different machine) and key into your app to unlock it. (Email will need some form of protection by way of password also). This step could be done just as the worker is about to enter the work area where there is no internet access. If you are able to set up a different machine, just for retrieving the verification code, this will guarantee that only valid workers can access your app, and they have to be at the correct place of work to do so.

Second, you automatically shut the app down if it is running outside of normal working hours - warning first - with ability to extend time only by sending a new unlock code to their personal email address. (If the app is used for different shifts then allocate shift hours according to User when they log in). Auto shutdown will force an operator to log in if they want to use the app again. (With Email verification).

Thirdly, and I am assuming that there is no Internet access inside the work area, if a worker decides to "steal" company secrets, and they leave the work area with the app running, it automatically shuts down. If Interent access is available outside the work area then the app could check for Internet access periodically (even as frequently as once every 10 seconds) to ensure that the worker is actually in the work area. eg, Check if you can access a paricular web site/ ftp site/ whatever. If you want to be more sophisticated, you could check the GPS location of the phone, knowing what is OK and what is not. (Considertion for toilet beaks apply).

Then you can choose to use your steps 1-5.

The mobile users will be on-site at customer's premise for "preventive maintenance" (or PM for short). That is the time where offline data is required. It is not meaning the app only accessible in their own office network.

 

[aeric]

Hello,

A quick question, Would you like to secure the whole device or just the contents of the device?
Meaning would you like to format the device or showing a login page where nothing else is accessible unless a certain password is entered?

Both of the solutions above are done remotely via an admin panel

Thank you,
Saif

I am still considering any solution that could convince the client to use a mobile app instead of a web application.

 

[Intelemarketing]

The mobile users will be on-site at customer's premise for "preventive maintenance" (or PM for short). That is the time where offline data is required. It is not meaning the app only accessible in their own office network.

The PM Worker goes to a Job.
Before going into the location which cannot access the Internet and Phones don't work, he logs into the App with Password control.
This also sends a message to the Head Office telling them where he is (GPS) and what time he starts the Job. Head Office sends a confirmation back to the APP to confirm that running the APP is valid.
On completion of the Job he exits the Job Location, back into Internet and Phone availability.
He Logs out of the APP and the APP sends information to HO - Location (GPS) and Completion Time. AND the App shuts down automatically

If the PM Worker decides that he wants to show the App and the Data to a Competitive Company (ie, Steal the Data) then the App will always send Timer and Location back to HO. A reply back from Head Office can be interpreted by the APP to open the APP or Lock it up severly if the access is considered invalid.
The APP cannot be opened without a confirmation back from Head Office.

He now loses his phone when he goes to McDonalds - No problem - the App is Off and can't be accessed unless the correct password is used.
Alternatively, he loses the phone at the PM Location and doesn't send a Job Completion confirmation back to Head Office.
Head Office is therefore alerted to the fact and now needs to take necessary measures, one of which is to NOT allow the APP to run - no validation will be sent to this phone.

If the Data is Stored in the lost phone, then anyone with Android and Software skills can presumably get to any data in the phone.
Can the data be encrypted ?

 

[aeric]

We have faced this problem before with a local manufacturer so i will have to ask 2 more questions :
1- Your solution is regarding a Hand-held device so when the workers finish their day they will have to go back to main office (control office) to sync the hand-held devices with the main database? or are the hand-held devices always connected to the main database (always online) ?

2- Does your app contain any GPS tracking functions?

1 - Android smartphone would be provided by the client to their engineer
2 - Most Android smartphones nowadays are equipped with GPS but there is no requirement on GPS tracking at the moment

 

[aeric]

Thanks @Intelemarketing and @sfsameer for so advanced suggestions.
I am thinking more simpler solutions.
I think password login and encrypted database are sufficient.
Maybe a timer or service running on the background to clear the data after a period of time.

 

[Alex_197]

1 - Android smartphone would be provided by the client to their engineer
2 - Most Android smartphones nowadays are equipped with GPS but there is no requirement on GPS tracking at the moment

but there is no requirement on GPS tracking at the moment - you right. We thought that we can somehow to get the location info from the incoming phone call but this info is available only to 911.

 

[Alex_197]

Thanks @Intelemarketing and @sfsameer for so advanced suggestions.
I am thinking more simpler solutions.
I think password login and encrypted database are sufficient.
Maybe a timer or service running on the background to clear the data after a period of time.

what I would suggest is to add a token into the url that the app sends to the server to sync the data - in this case you will know that this request was sent from the app, also you can encrypt this token and decrypt it on the server and then compare with the info on the server, just in case, even with SSL we're in a danger of the middle man