在Android上防止多个用户帐户（实际用户流）

Question

So I have a unique security issue. (Well i think so anyways, but I may just not know what i am doing?)

So the overall idea. I want to make an app that sends a data stream to my server. I don't care at all about keeping that stream secure, it contains nothing important. So don't think encryption.

Whats important to me is ensuring the validty of each stream. By validaty I mean, validating that each stream is actually coming from a unique hardware device running my app.

I have been looking around online about how to prevent users from creating multiple user accounts, everything from verification emails to verification texts. Those are all stopgap measures that take processing time and resources to impliment and only help limit the issue. (Its super easy to make multiple email accounts, and only slightly harder to get access to multiple phone number, and if you figure out the phone number thing its no harde to get a text forwarded to your own phone.)

One thought I have for this particular case is to involve a third party who has a definitive list that matches hardware ids to phone numbers, AKA the providers who actually service cell phones.

So what would be awesome would be an API to allow the following action. 1. Person starts my app. 2. App sends initial contact to my server. (This will include user phone number) 3. My server receives this and queries the provider servers asking the provider server to query that particular phone number, ensuring it has a valid hardware ID to be on there network and that, that particular phone is running an instance of my app.

I think a system like that would solve my issues, and be pretty foolproof. Even if someone ripps off my app and installs an app with the same name on the phone to trick the system, i don't care, because that phone can still only send 1 data stream. And i think it would be almost impossible to create a hardware device to spoof an another phone on there network. (Well maybe you could do it, but they would track ya down pretty fast.)

1. way to get around this would be to write a virus that infects other phones causeing them to respond incorrectly to the service provider request. While this is a possible hole, i feel safer knowning google and other companies will fight hard against such viruses to keep there systems reputation.

Thoughts? Suggests? Keep in mind, all that matters is verifying that any incoming stream comes from a unique peice of hardware that is running my app.

(can you guess what my app is?)

Answer 1

There was a post on the Android developer blog about this just last week.

In short: ANDROID_ID is a good enough start, although it doesn't work reliably on all phones (especially older ones). If you want to support older phones, you could combine that with the IMEI as suggested above (but keep in mind that not all devices have an IMEI. WiFi-only ones, for example).

Answer 2

Please read, not just trying to be a negative ninny. I have a lot of experience with piracy I can tell you your efforts are futile. Heres the deal, time spent on complicated piracy prevention is time wasted. If you sell it through the android market honest users will stay honest. Who cares if I give it to my friend If it's a good app he will want updates and have to buy it cause I'm not got just keep copying the new version and emailing dropboxing etc...

Pirates are just gonna download the free copy so you are NEVER GOING TO GET THEIR MONEY LET IT GO!!! It's like the girl who's attractive enough to have sex with but you don't like her as a person. you're not going to go out of your way to make her your girlfriend. Pirates look at your software the same way: "I want it if it's free but otherwise... meh..."

You put all this work in to some half baked scheme wasting time you should be using to update your app and support paying users. All this effort to not be "stole" from. You know what I'm gonna do to crack that program (not literally me, just an example) I'm going to hex edit it or reverse engineer the code and remove your calls for authentication completely. I might create an on phone service to authenticate and just hack your app to authenticate on a 127.0.0.0/8 loopback.

No matter how good the protection if it is meant to run in a multi user environment it's gonna be broken look at HD-DVD and Blu-ray. I was present at the on set of cracking those protections and they were very impressive and complicated but ultimately simple to break.

THE IRONY OF IT IS DRM RESTRICTIONS ARE WHAT KEEP ME FROM BUYING MOVIES, GAMES & PROGRAMS. SHARING IS CARING!!!! more importantly it's FREE ADVERTISING!!!!!!!!!!!

I can't tell you the number of CD's Movie's Game's umm... Pr0nsites >,> whistles I've bought/spent money on as a result of piracy. If you make a great program and keep it updated people will buy it. If you try and keep it locked to a platform or specific device HAHAHAHA good luck with that ask swype how they are doing keeping their keyboard only released through OEMs. Even with device manufacturer support, hardware emulation and debugging to crack it.

I pirated an OS when I was 13 or 14 and had no money, same with a disc burning software. When I was 18 and built a new rig I bought both. I pirate some android apps and guess what I bought the ones I liked and the ones where the dev did updates.

Your best anti piracy scheme is being a good dev and being responsive to your community. HERE'S YOUR BEST PROTECTION SCHEME!!! Google now accepts in app payments sooo... make your app free with a donate for pro/purchase button in the app (More donations through the menu button). Make sure you disclose it the description that it's in app purchase to avoid pissing people off and getting bad reviews.

Here is how it would work. The app is installed, they make an in app purchase the app uses the MAC address on bluetooth wifi or both to generate a device ID. Once the purchase is made a key string is generated stored encrypted in the device storage. On app restart it decrypts the string key checks it against the mac addresses to ensure it's on the same device. It should check with the server on any new install and see if the device is already registered and send the allow the device to generate the key string again.

Email at purchase a key code to re-register, it should be a license key different than the string key so they can not use the string key to break the encryption and crack the scheme.

the key should just reference the device ID server side and allow replacement of that device with a new one for say the sake of an insurance replacement (or new device).

You should just use the google app store drm though because if one of your customers moves to a new device they will be annoyed.

To make sure the app always works you should have a commitment to release a drm free product if development ever ceases.

Drm is just a pain and a hassle and the pirates remove the restrictions completely so when you look at being a paid customer with restrictions or free and easy what would you pick?

If this was not completely clear sorry I typed it with three people talking loudly one of which was a three year old throwing toys at my face.

THE END

PS

https://market.android.com/details?id=com.noshufou.android.su.elite&feature=search_result This app does NOTHING at the moment it have INSTALLS: 10,000 - 50,000 purchases just to support the dev of other programs

Answer 3

If I really wanted to lock an app to a specific piece of hardware, I would use the IMEI (GSM) or MEID (CDMA) from the phone and assign them a unique cookie. You can use the permission Read Phone State to retrieve those numbers from the phone and send them to your server. For the protection of your clients, I would send those only once and return a random cookie for them to use on further requests. You can record the IMEI/MEID in a database as well as the associated cookie to ensure the same device always gets the same cookie. I would also use SSL for this initial transaction for the privacy of clients, but the cookie can then be sent in the clear if you want. This will link their account to their phone. I don't know if Android MP3 players, tablets, etc. have a similar serial number. GSM phone also have a number called IMSI in addition to IMEI which is specific to the SIM card instead of the phone. CDMA phones have no SIM card and only have the MEID. Lastly, this cookie I speak of does not have to be a regular HTTP Cookie, it can just be part of the URL such as ?cookie=abcd123 or some string sent in-band what ever network protocol you decide to use.

Answer 4

为什么不使用像IMEI这样的独特硬件ID？