Android Question Vetted access to parts of my app?

[tsteward]

What approach would you suggest where I can put my app on play store and iOS store where 90% of my app is available via subscription but the remaining parts of my app are only available to authorised people.

I could do two subscriptions but due to the sensitive nature add the data I want to personally approve who can view it.

 

[MicroDrie]

Without any explanation of how to authorize someone's app (like on-line or off-line) you can't expect more than some generalities. I would say apply the principle of "Give some, get some". Let the app collect some data, encrypt it with Java RSA encryption. The challenge is to find something that is specifically bound to the tablet/phone so that the known encrypted information is only usable on the authorized person's device/tablet/phone.

 

[tsteward]

At this point I am thinking the secure data resides on my server to make it harder for someone to get at it.
Then the user would have to log in and if approved the restricted data would load as required.
Completely offline would be nice but I just don't know how other than trusting them with a password to access the info.

 

[MicroDrie]

If you let your app encrypt the same amount of personal data with a public RSA key, then it can be sent to your server, decrypted after receipt with your private key and determine who the sender is. What you could do is use a mechanism where you recalculate the message every time and take that as the starting position for the next calculation. If you approach this cleverly, a backup of the program of an authorized user cannot abuse the authorization because the order is no longer correct and the message can therefore not be decrypted. It is then very important to ensure that you can restart the authorization from a certain point in time if something goes wrong.

 

[emexes]

Is there any configuration information stored by your app that is (relatively) unique and fixed to your customer?

Eg workshop name or telephone number, used for printing hardcopy results or receipts for your customer's customers?

 

[tsteward]

This sounds exciting to me. I am a locksmith and immobiliser transponder works similarly.
Not sure I'm not smart enough to pull it off
Thanks for the idea though

 

[tsteward]

Is there any configuration information stored by your app that is (relatively) unique and fixed to your customer?

Eg workshop name or telephone number, used for printing hardcopy results or receipts for your customer's customers?

App is in early development so not yet but trying to sort this out now

 

[emexes]

Thanks for the idea though

Lol if it was my question that sparked the idea: using that sort of "registration" information to allow access to restricted information, has the advantages that:
(i) they're unlikely to share it with other users, and
(ii) other (business) users are unlikely to want wrong information appearing on their own reports, and
(iii) it doesn't change when your customer reinstalls or updates the app, so it avoids a whole heap of desperate after-hours calls from customers who've locked themselves out of the information that the need right there and then.

 

[emexes]

Telephone numbers including country codes tend to be unique. Also email addresses and business domain names. All of which is the type of information that would be printed on a receipt or report for your customer's customers, and thus unlikely to be dodgied-up by a (legitimate) business.

The software I worked on back in the '90s had an authorisation system that used the 32-bit disk id, the company name, and the terminal number (if it was running more than one terminal on a network), with flags to individually check or ignore those three items. The user would read to us a number off their screen that contained hash values of those three items, and we'd give them back an authorisation code that included those hash values and the flags of which ones to check or ignore, plus an expiry date for trial or lease situations. Worked great.

 

[emexes]

Close, but no cigar:

but also device id's have the disadvantage (or perhaps advantage) of requiring support when the user upgrades or replaces their device.

 

[MicroDrie]

Old school security wisdom assumes a layered approach based on the risks addressed and your "Have What" and your "Know What". As has become clear in previous posts, it is not that easy to achieve 7*24 support.

It stands to reason that you will store information in a database. Therefore, take into account that you secure it in the right way and use it in such a way that it cannot be abused. Do not forget to look and use the tips from Erel:

[B4X] Features that Erel recommends to avoid
[B4X] "Code Smells" - common mistakes and other tips

The best security is security by design. That means giving an authorized person access only to their authorized information. Follow Erel's advices and prevent abuse by using parameterized queries, and implement security updates for the software you use as soon as possible.

Also be aware that third party software use can use software versions that may have security bugs.

I am not a lawyer, but I make the user legally responsible for the security of his account data and used device. Let your app encrypt specific user information with the public RSA key at every login attempt and save the result. With your secret private key you can decrypt which authorized user account was used.

This way you can prove that the information was requested and provided by the account of the authorized user. The combination of user ID and user email together with the login time and the legal responsibility of the user to protect the user account and the used device together to only grant access to his authorized data is I think a good security starting point. Communicate with the user via his email address to establish that you are communicating with the intended user who has the responsibility to protect his email address. Let the user accept the risk that a user can consciously or unconsciously "give away" the software and account information to third parties and thus only have access to the data of the authorized user.