Please I have the following scenario:
the app uses a password to access to some remote webservice over HTTPS;
to do so, the app asks the user the password, does NOT store it on the device (and use it in a safe manner to access the webservice).
My concern is the following: it's theroetically possible to access the memory to read the data it contains and eventually retrieve the password.
Please how do I prevent this from happening?
Thanks
Please how do I prevent this from happening?
I wear tin-foil hats on a professional basis (besides, I think they look spiffy...), and this is beyond what I normally worry about. I'd worry about making your HTTPS code won't be the victim of a Martian-in-the-middle (MITM) attack, as that's a lot easier for an attacker to execute.
That being said, as samgak alludes to in a comment, String is immutable. Once the password is in a String, you are at risk for the attack that you describe.
If you use an EditText to collect the password, do not call getText().toString() to get what the user typed in. getText() will return an Editable, which allows you to get at characters, not a String. Then, if your HTTP client API allows you to fill in the password using a char[], once the HTTP request is done, you can clear out the contents of the char[], clear() the Editable, and then pray that EditText and kin aren't holding onto a String anywhere that represents what the user typed in. This may vary somewhat by device, as device manufacturers have had a long history of screwing around with EditText behavior, and so what may be clean in terms of AOSP code may be less clean on the hardware from some certain manufacturers.
If you are getting the password by some other means (e.g., your own set of PIN entry buttons), just avoid a String representation of the result, and wipe out the char[] when you're done with it.
Yes, theoretically it is possible, when having physical access to the device. At least it possible to debug the application and to catch a value in any point when encoded/decoded, i.e. it is open.
But much more simple way it is to catch user input itself, when he enters a password. So, you not need to worry about memory sploits.
Related
I have an Android application that allows users to post information to a database, via a java web server that I have code on.
Users are allowed to up/down vote said post. How do I prevent the same user from voting a plethora of times on the same post?
A few ideas I had:
Disabling locally via adding a local storage "key" for the post ID Unique Key. For instance, when the user votes up or down. It writes a key with the information of the type of vote and the Unique Identifier of the post on the user's local storage. Is this feasible with a lot of votes? Would it cause any sort of hard drive consumption/lag?
Storing a uniquely-generated key on the user's phone generated at application install. This key would be submitted to a new table in the database that associates posts with votes and the "user-key".
If you're expecting lots of information, a database is probably the way to go. Obviously this will use storage space, but not much. Writing to the db tends to be very fast in my experience.
The unique key would work fine too. That way would be more secure (depending on how you do it) since it would be harder to spoof it from the client. If you generate the key based on the user's Google account, or the device ID, you're in good shape. If you do it by some pseudorandom method then the user could still cast multiple votes by just clearing the app data and getting a new key.
If it's really important to prevent multiple votes, do it on the server. If it's not particularly important, do whichever method seems easier to you. You can also consider doing both, for the best of both worlds: immediate feedback to the user on a duplicate vote attempt (or just altering the UI to make it impossible), plus a backup validation on the server in case the user tries to get around the client check.
The app that I'm developing allows the user to enter in a zip code, then the app displays my local businesses that are closest to them. So if someone entered in a New York zip code, all of my franchises located in NY would show up.
It would be ideal if I could see what zip codes are most popular with the usage of this app, and which states receive the most traffic.
Is there a way to record/analyze the entered in zip codes of my users, and have that data sent back to me? Will this become a privacy issue if I gather this data?
Thanks
EDIT
The zip code the user will enter is simply in an EditText.
What you want to do is certainly possible. Since you're posing this question at all, I'm guessing you're app has the available franchises stored locally as opposed to retrieving them from a server.
Where is the data supposed to be sent to? If you have a server, you can use an HttpsURLConnection and POST the requested zipcode to your server when the user presses calculate or however else calculation is kicked off in your app. You will need the internet permission for this to work.
As a word of caution, you should be very up front about that you're doing this to the user, and also give them an option to turn it off, or even have it turned off per default. Personally, this would be the kind of thing that would bother me a great deal if I were to use your app. (Actually, if I couldn't turn it off, I probably wouldn't use it.)
EDIT
I'm not an expert on U.S. privacy laws but I imagine you probably need a formal privacy statement, as well. You certainly do if your app is also available in the European Union (regardless of whether it's useful there or not - whether or not it's available is enough.)
Yes you can easily collect this data and return it to a server. This will require an additional permission for your application 'android.permission.INTERNET' (If not already included.)
Not a lawyer and didn't stay in a Holiday Inn... but I don't see a privacy concern if you're using anonymous data... if you're packaging up user information (Name, Phone #, etc.) and sending it back I would think you'd want to include a "privacy policy" in your app's terms of service.
I just noticed this article about a mobile app that is storing user information in plaintext. I've paid attention to the idea of storing the user's password on the server (using a SHA-512 hash function), but I'm not clear on the best methods for storage of personal information at the device itself.
Let me be clear I am essentially only talking about user names and passwords. The data that my app interacts with is not at all sensitive, and I know that I can implement some sort of symmetric encryption/decryption on that data.
For user convenience purposes, I'd like to offer the user an option to store their user name and password locally so that they aren't required to enter it each time they use the app. But I know that user's tend to reuse the same password for many different purposes, which means that I need to take precautions to keep my user's passwords secure. Classic tension between convenience and security.
Is it just simply a terrible idea to ever store this information locally? Or are there relatively simple means to securely encrypt this? Do the iOS and Android O/S provide any help with this?
Not necessarily looking for exhaustive answers, but I'd really appreciate some topics to research, article links, books, etc. Thank you very much. If this is a redundant question, please direct me to any posts that give answers that are still considered current.
Thank you very much!
All data on the device is automatically encrypted by the device to some degree, using the device id as the key. This prevents data from easily being read by anything other than the device itself, or someone with the device id anyway.
There's another level of encryption that you can pile on that utilizes the passcode, called Data Protection, which prevents the data being read unless the passcode is entered.
You can manually enable data protection in your app by using NSFileManager to access files and setting the NSFileProtectionKey attribute to NSFileProtectionComplete. See: Implementing and Testing iOS data protection.
Note that the user must set their device to require a passcode, and the stronger the passcode, the more secure the data will be.
You may be able to easily enable data protection through the provisioning profile for your app, even if you don't use the NSFileManager class with NSFileProtectionComplete. See: Data Protection / NSFileProtectionComplete - successfully supported through entitlements.plist?
I still wouldn't store the password. Store a randomly generated session key that is created when they log in. At least you can expire those and it's not the plain text password.
Just a follow up to this post from a year ago. What I decided to do was to generate a random session key (similar to #Marcus Adams suggestion) but use that value as a salt. I then concatenate that session key with the user's chosen plaintext password and store this value on the device (if the user elects to store their password). i.e, the device stores this value:
device_hash = sha256(device_salt || plaintext)
That hashed value then becomes the string that I pass over HTTP to the server for validation. On the server side, I have a different salt value stored over there. When the server receives the device hash value, it has its own salt value which it concatenates to that string, and then performs its own hash. That final hash is the password that is stored in the server database. i.e., the server stores this string:
server_hash = sha256(server_salt || device_hash))
I think that this is a viable balance between security and convenience, particularly since I am only trying to protect the password, and not trying to encrypt the actual data that gets exchanged in the normal course of the app. If the user's device is compromised, no attacker can use a rainbow table or anything like that to reverse engineer the password since it is salted. SHA256 along with the long length of the password should eliminate a brute force attack if someone were truly motivated.
Curious if anyone has any criticisms of this approach.
In my Android application, the user can submit content to the database which can then be seen by all the other users as well.
This new content is sent to the server via GET request:
http://www.example.org/API.php?newContent=helloWorld
The problem is: If a user finds out what this URL looks like, he could easily sent malicious requests in his browser and circumvent the Android application. Maybe one could decompile the app and find out about the URL.
How can I protect access to this URL and prevent users from accessing this API directly?
Is it a good solution to generate a hash in the application and compare it with a hash generated in the API.php file on the server?
Couldn't one find out how the hash is generated when decompiling the application?
Thank you very much in advance!
So the only way to truly protect that URL is by requiring all requests to it be authenticated.
One way to do this is change your request to a POST request and send along some sort of auth token (a simple hash will do) with the request. If the auth token isn't present, simply don't respond to the request. The hash would be something you'd hardcode into both the client and server.
Now the question is how to hide your auth token. As long as you're not open sourcing your code, the only way for someone to get at it would be to decompile your program as you mentioned. To guard against this you might want to look into using proguard (http://developer.android.com/guide/developing/tools/proguard.html).
Something to keep in mind is that this method contains a single point of failure. If your auth token is ever exposed, you're done for (e.g. the HD DVD AACS cryptographic key debacle).
One other way to authenticate is on a per-user basis. As long as a valid user is making a request, you shouldn't really care whether or not the request is coming from the web browser or android app. I think this is a much better way of doing things. By doing this, you can throttle requests on a per-user basis. This however requires you to manage user profiles and the whole can of worm that comes along with it.
All that said, at the end of the day though you shouldn't really care if somebody knows the url to a portion of your API. I don't know your particular use case, but there's got to be a way to design your API so that you don't care how you're getting your requests. Also, if your doing a true GET, then you shouldn't be changing anything on the server. This means that all the 'malicious person' can do is get data off of it. This severely limits the damage they can do. In fact, unless you have sensitive data that you don't want certain people to look at, you don't really have a problem at all. If you do, then you should really think about my per-user authentication solution.
Don't trust the client for validation. This is true if its javascript in a web-browser or even some locked down platform like the Iphone.
If the app can make the API calls, then clearly everything needed to make those calls is on the phone ( secret, hash function, API key, whatever), then someone can always dump the phones storage and get all that data. They can then make whatever request they want.
What you want to do is authenticate the user and then validate the input on the server side.
Use SSL (HTTPS) for your data transfers. The exchange is encrypted before any data is sent, so anyone listening in won't be able to see either the URL or data that is sent to the server. To verify this for yourself, install Wireshark on your dev system and load the URL into a browser. You'll not see any data in the clear (either the URL or the data that is sent via either GET or POST).
You could use a somewhat confusing java method to obfuscate every letter of the URL. So kind of creating your own dictionary in a way which could make the URL possibly appear as 123.3*15*13 or something like that if someone did decompile the APK, they would have no idea. And on that note, you would ideally use Proguard to obfuscate it, so your obfuscation would make no sense to someone trying to reverse engineer.
You could make a short java method like this:
public String confuseString() {
Stringbuilder sb = new StringBuilder();
//your real URL would be abc.com, but in the app you have myURL = 123.3*15*13
//With what I'm saying the * would precede a 2 digit number that represents 1 letter
for (int i = 0; i < stringLength; i++){
String letter = myURL.charAt(i);
if (letter.equals("1"){
letter = a;
sb.append(letter);
} // you would go one to code each character into a letter
}
}
There would be several more if statements of course, but it would allow you to obfuscate your url without making any server side changes. And if you use Proguard, then that entire method that you create would make absolutely no sense to someone trying to reverse engineer.
You could of course make your obfuscation much more complicated than what I suggested, but it's an idea anyway.
Basically you'd be encrypting the URL in a very confusing fashion.
Here is an answer which may be a better method of encryption or at least give additional encryption:
Java - encrypt / decrypt user name and password from a configuration file
I'm using the Dropbox API. In the sample app, it includes these lines:
// Replace this with your consumer key and secret assigned by Dropbox.
// Note that this is a really insecure way to do this, and you shouldn't
// ship code which contains your key & secret in such an obvious way.
// Obfuscation is good.
final static private String CONSUMER_KEY = "PUT_YOUR_CONSUMER_KEY_HERE";
final static private String CONSUMER_SECRET = "PUT_YOUR_CONSUMER_SECRET_HERE";
I'm well aware of the mantra 'Secrecy is not Security', and obfuscation really only slightly increases the amount of effort required to extract the keys. I disagree with their statement 'Obfustication is good'. What should I do to protect the keys then? Is obfustication good enough, or should I consider something more elaborate?
You can't help it. If the user (attacker) has the protected data and the code that does the unprotection, the user can eventually get access to the data. It's as simple as that. A debugger and a breakpoint at just the right time is all they need. That, and lots of free time and determination.
Whether or not secrecy is good enough for your purposes is up to your business specifics. But generally in the mobile world, if the customer is that worried about their data being stolen, they implement high-level theft and loss controls. Things like remote wipe, mandatory screen lock, etc. I don't think it's up to the application programmer to duplicate all that stuff.
Security can never be perfect, so it's up to you to decide how much work you want to do. You can break the consumer secret into multiple Strings for a simple change that offers a minimal amount of additional security or you can create an algorithm to represent the secret in another way (anything from inserting characters that aren't used every X spaces in the string to modifying each character, perhaps based on the numeric representation).
You have to consider the work vs. benefit. If this is an app that you and a few friends are going to use, then it probably doesn't matter much. If this is going to be an app used by 10 million people, security is obviously more of a concern.