Embedding a private key being distributed all over is a big NO-NO. In the consumer space identifying a user without any authentication is next to impossible (without TPM like capability with universal identity etc). In the enterprise space we can use digital certs that are uniquely provisioned to each device, but scalability of such a solution is consumer space is a issue.
On Sat, Oct 6, 2012 at 9:14 AM, Jakob Bohm <[email protected]> wrote: > > > On Friday, October 5, 2012 8:59:10 PM UTC+2, Lucas Palma wrote: >> >> Hi everybody, >> >> There's some way to identify that the user is using a mobile device, not >> a desktop? >> Like, I have an application, which communicates with a web service, but >> anyone could access it through a desktop, and simulates that is using a >> mobile device. >> >> I don't think that "user-agents", "css" and things like that will help, >> since they can be forged. >> Someone know one or more ways to do the trick? >> There's some way to do it without changing the application? >> >> Thanks in advance! >> >> You could check the users IP address against a database indicating which > IP addresses are used by mobile networks for connections from their users. > Users will have little ability to directly fake this, but there are some > factors that can give seriously wrong results: > > 1. Most modern smartphones can use ordinary Wi-Fi connections where > available (like at home, work, restaurants...) this will look like a > "desktop" in the IP address check, because it is using the same connection > as any desktop machines on that Wi-Fi net. > > 2. Many people use mobile connections for their PCs and laptops, (these > include "mobile modems", "mobile routers", "mobile phone tethering" and > built in mobile modems in some laptops). These will look like a "mobile > phone" in the IP address check, because it is using the Internet connection > from an actual mobile phone subscription (and sometimes even an actual > mobile phone). > > 3. Keeping track of which IPs are assigned to mobile phone networks and > which are assigned to landlines owned by the same telco corporation is > hampered by the fact that this is an internal decision by the secretive > telco backroom staff, and is subject to change without notice. > > ***** > > A more realistic approach is to supply development clients of your web > service (that phrase implies a programming interface, not a human interface > like a web page in a browser) with an interface wrapping library that they > need to link into their code. The versions of the library that you provide > as mobile phone native or Dalvik code can include a hidden private key > which it uses to sign a message to your service that the user is running > the mobile phone versions of your client code. > > If you are not really talking about a web service, but about a browser web > page or a mashable web page component (like Google AdWords or Google Maps > for web sites), then you will need to find security methods that hamper or > discourage cheating without actually checking device capabilities. For > instance the less secure interface could be rate limited (fewer login > attempts per account per hour etc.), could provide only "phone quality" > images etc. > You could also provide users with more security the more security they > provide you, for instance if they use the encrypted login, they get their > stored data encrypted too. > > You will need to look at each interface you provide and make it hard > enough to attack to keep you safe without making it to hard to use as > intended. > > -- > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/android-security-discuss/-/b9Q_8jT4h_4J. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/android-security-discuss?hl=en. > -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
