I am working on an applikation for Android platform. The application uses heavy amounts of HTTP calls to my webserver. This works out verry well but im in need of assistance in securing my calls and webserver.
I know that i can use SSL through Https to encrypt my connection both clientside and serverside, this is not a problem and will ofcourse be done when launching the application. But what would the most secure way be to have a session for the logged in device?
Ive thought about making a mysql based session system containing the following rows
id - sessKey - sessCont - sessUid - sessTime
sessKey will be a random generated 32 bit key. sessCont a JSON array of the stored informations and sessUid will be the user id of the user signed on. sessTime would contain a timestamp.
This session will be set on login and the phone would then recive the sessKey + sessId. When making calls the key will be changed and returned to the phone again. If a call is 10 minutes later than the latest call the session will close down and a new one will have to be made.
Yet i keep seing ways of compromising this approach, as well as i can with all other approches im able to think off.
How would i manage to make the best possible security and session control from my phone to my serverside script?
Thanks in advance.
Jonas
Alright numbered list time...
If you're using an SSL connection a good portion of security is already on your side. You can cross sniffing off your list of vulnerabilities.
Most of the leftover vulnerability will be on the user end, can hackers monitor the hardware on the user end and grab a session information after it's been transferred to the user's hardware, which in this case is an android phone. App data is protected from other apps so unless you, the developer, or your user is doing something insanely reckless it should be secure.
Which leads me to #3, all the rest of the security really lands in your lap as the developer. If you have cross-site scripting (XSS), the session IDs can be guessed easily, or you are vulnerable to session fixation, or your session ID storage is weak (SQL injection?) then you've effectively undone all the good work you did with every other measure of security.
In the end there are always ways to hack a system, but if you follow those three steps you've done everything you can do in order to prevent hackers. The rest unfortunately lies in the parts we can't touch; Android operating system, cell phone networks, user's common sense.
P.S. The most secure method would probably be to trash the session idea. Store the user id (a number that could mean anything), and a md5 encrypted version of their password. Be sure to add something funky so hackers can't just look up the reverse of common passwords. (IE. theirPassword+userid+HACKTHISSUCKERS) and even if someone goes to an md5 reverser they won't be able to undo your hash. And then every time you make a request to your server, do it over SSL and when the authentication checks out, send the info. Secure SSL connection, secure md5 passhash, no security leaks.
Even if a hacker somehow found what your app was sending to your server; a number and a undecipherable hash. The only way they could find out what your app was sending was if your user was being negligent and allowed their phone to be connected to the hacker's hardware that was actually capable of intercepting POST data before it was sent over the SSL connection.
Related
I'd like to develop a simple Android application that authorizes access to a server in the following way:
The app stores a local counter t_count of access tokens which initializes at t_count = X;
Whenever the user wants to access the server, the app signs a proof that it consumed one token and sends it to the server via a local connection;
Once the machine acknowledges the proof, the app securely decrements the token counter;
If t_count = 0, the app should prevent the user from sending consumption proofs.
The most important here is that the app can only decrement the counter, and only with an associated a signed proof of consumption. No other modifications should be allowed, even if the user has root access. Ideally, this counter should be stored in a TEE-protected environment.
While doing some research I discovered Android supports a TEE-backed key storage that prevents attackers from extracting private keys. However, it is unclear to me whether I can use this functionality to store an arbitrary counter or, if not, what would be the best way to protect it. I don't know how I can securely update and verify the counter either (or even if this is possible). I don't have any background in Android development.
Thanks in advance.
EDIT: I cannot place the counter in the server because in my use case the user can access many servers which are offline. Hence, the easiest way to keep track of the accesses is to manage the counter inside the user's device (if it can be done securely).
What you are trying to do is not possible.
You should never trust a client. From the Server's point of view, it is impossible to tell if it is interacting with software that you developed v.s. software that an attacker developed. Relying on a client to not send "consumption proofs" based purely on a counter that the client has control over is not secure. As an aside, if there exists a way for a client to send "consumption proofs" without actually consuming anything, then it is not a proof of consumption.
If you want to limit accesses to a server, it must be enforced on the server side.
I want to prevent someone from simply rooting the device and copying the app to redistribute. How do I make a downloaded device "account locked"?
My idea is to implement an encryption algorithm (one-way) that hashes the user's phone number and the execution of the code will perform a hash check every time (so it would fail if you use someone else's app on your phone).
However, since the app is downloaded the same way, if I implement the phone number hashing at first launch, the attacker could simply never launch the app and rip off the base version of the downloaded package.
So my question is that is there a way in the Google Play Store to provide the app with one of its variables changed? Or a clever way to ensure an installed application would not work anywhere else to prevent a direct copy package rip off? Maybe force a first launch so it configures itself immediately after download?
There's a short computer science answer, and a longer more helpful answer. The short answer is "If your app relies on a server to run, then it is easy. If your app runs entirely on the device it is theoretically impossible."
If your app relies on a server it's a simple process:
Use Google Play License Verification Library (LVL) to get a response cryptographically signed by Google to say this account bought this app. Do this in client side code on the app.
Send that response to your server, and check the signature. If it doesn't match, don't send the needed information to your app.
Because the user can't interfere with Google servers or your servers, and your app requires the server response to function, this is unbreakable.
However, if you check the response on the client side, or your app can work without the server response this can't be done (theoretically). An attacker can always remove the call to Google Play, the verification code, or fake your server response.
In this case you are in arms race with attackers. Most attackers are pretty lazy. If you use Google Play License Verification Library (LVL) to check your app was bought from Play, use ProGuard or another optimizer, and do a little bit of obfuscation to hide your code, some attackers can attack, but most won't bother, unless your app/game is super popular. Another useful technology is the SafetyNet attestation API which tells you if your app has been tampered with. But again, if you don't check the results server side it can be beaten, so client side is just an obfuscation arms race.
Beware, relying on something like phone number is a really bad idea:
what about Tablets which don't have a SIM card?
what about users with Dual SIMs?
what about users who change phone numbers or networks?
what about users who own more than one phone, who only need to buy your app once?
I'm building a simple Android application for my self. It is a simple password manager where I can store all my accounts. I just want to know if is it possible to hack or extract the data of Android app even if it's offline?
Thank you
Are the password hashes stored server or client-side? If the passwords are stored client-side, then yes, it is indeed possible. If the passwords are stored in plaintext, all the better for the attacker who has local access to the device.
My hope would be that you used symmetric-key encryption on the passwords which can only be decrypted with your master password utilized as the key and that you minimize plaintext exposure even within memory.
No one can transfer data to a remote server when the device is offline, but there are other possible ways considering your problem like,
Create a program to collect data from your database and send it through SMS (Considering passwords are textual data and small in size)
Create a program to collect data and stay in low profile and send them to a server when the device became online
Technically possible, But don't worry, chances for someone doing something like this is very low,
Go with your idea and encrypt data if you can to avoid easy stealing.
Happy coding :)
I would always assume yes with these kind of things. I would recommend looking into encryption of the data, a simple splash screen for an app password would work. I would make sure that the private encryption key something that can only be generated by that password entered at the lock/splash screen. Other than that, on stock roms you should be alright but obviously dont leave fishy apps on your device. If I was building this I might even look into 2 factor auth via nfc as well.
Yes, It may be possible!
Internet is not only thing which connect port or sharing of port,
There are many options like bluetooth or Hostpot...
Through which we can connect two device jz we have to write program which access these tools and gives command to victims phone....
For online
We have msfvenom payload to hack any android...
Its quite easy process in this process we forword victims phone port to attacker os....
Its so easy
For offline services we can hack device using BT remote control or same as with wifi...
I'm writing a ringtone gallery app which ringtones reside on a server and they can be downloaded by user.
What I want is to check and verify if the connection is really from my app not other apps or a HTTP request generator. for example I don't like someone write an app that uses my back end and show his ads in the app. It's like image leaching in web site which is prevented by checking the referrer.
It's not possible to insert a key in the app as android apps can be decompiled so easily. I thought of gaining the app signature and send it's hash as a key, but it's like any app can access other apps signature hash.
what about writing part of app which do the communication in native code? is it decompilable as easy as java code?
I really can't think of any other way and I don't like others use my resources for their benefit.
There are a couple of things you can do.
Create your own Certificate Authority, ship a certificate with your app and use two-way TLS authentication. This does not protect against decompilation and reverse-engineering but protects traffic en route.
Use the advice in this slide deck to detect modifications and debuggers.
Use Jelly Bean's hardware-backed secure storage.
At the end of the day, though, DRM is a lost battle. If the user has root access, all bets are off, with or without obfuscation (which native libraries are). The only question is how important is your data. For 90% of applications, running it through ProGuard makes it nearly impossible to untangle (especially if you use data flow obfuscation). Along with the certificate approach, that should suffice for most things.
Alternatively, try to change your model, so that you're authenticating the user and not the app - that's far simpler!
I came across a few tutorials online explaining how to connect to MySQL from an Android app, but they are a bit surface.
If I just write SQL and send/receive it in a POST, it seems problematic for a few reasons:
1) Hardcoding SQL with obvious issues there
2) Security concerns about sending sql - is that safe to send that request? or should it only be done via SSL?
3) To connect to the db, in order to insert things, I need to have the db connection info inside the app - is that safe? Can the code be read by someone hacking the device and the apps?
What is the best way to go about connecting and using a remote db from an Android app?
Thanks!!
Wrap everything in an API and manage authentication either with encryption with public/private keys or with a token-based system. You should never, ever, ever accept raw SQL in any way, shape or form from any device or site. Most often if you need live, remote data to run you should reconsider your application workflow and work off slightly stale data or provide the information in the background due to the possible spotty connections. Hitting even an API can be a costly endeavor so it shouldn't be something that has to occur frequently.
To incorporate some of the ideas above you could a couple things. For the public/private key read up on http://en.wikipedia.org/wiki/Public-key_cryptography. The basic concept is you store the public key on the device then negotiate a private key after the installation of the application that is also stored on the device (although not coded into the application). This key is the one you have to protect so it should be negotiated on installation and stored with the lifecycle of the application. You could contact an API with a unique hash of the device (say the device ID) and a password that the user could set. In that way if the data is wiped, since the password is stored on the server you can validate that a request to generate a new key is valid for that device ID and also protect against attackers trying to disrupt everyone's keys.
Obviously this is still susceptible to someone intercepting the initial request but if you are using HTTPS (which you should) then it should mitigate most of these issues.
You have to make sure an attacker just cant send in random device ID requests to generate new keys as it would disrupt the actual user's device of that hash, which is why the password set is important. Of course they could also do this against device IDs not currently registered but you could easily implement throttling and blacklisting against the initial API.
There are many things you can do but depending on your sensitive data it may be overkill. You'll have to make that judgement call and figure out who you are trying to protect your data from.
Use a webservice through which to communicate with the database. End User clients generally do not communicate with the database over the internet. Multitier_architecture