Godfrey Nolan

The good news is getting JUnit4 testing up and running in Android is now really easy.
Thank you Google.

So there really is no excuse to not add unit tests to your code.

However I've been having lots of discussions recently about code coverage in Android.
To me there is so much boilerplate code when working with Android that asking for 95%
code coverage isn't realistic? Any recommendations on a good code coverage target
in Android?

I put some code up https://github.com/godfreynolan/Keyczar which hides an API key using KeyCzar. The API key is in the res/xml folder in the Android code, it's already encrypted in this case and is sent back the server so it can be decrypted using Keyczar. I'll put up a password example next.

The LiveLesson videos cover the OWASP Top 10 module by module, so it goes over the common as well as the less common attacks such as using android intents.

Memory leaks are more likely to be a security problem for the developer if you're using the Android NDK and writing your code in C++ than in Java. Most of the memory leak issues to date have been with the Android platform and have led to some of the exploits that allow you to root your phone, e.g. Gingerbreak.

It's not a good idea to hard code it, as someone will find it.

There are different encryption keys. What I was referring to is when someone stores a password or other info in shared preferences and rather than put it in cleartext, encrypts it using an encryption key which is hardcoded in their Java code. The code is then decompiled and the password can be recovered using the hardcoded key. I wasn't talking about SSL. That make sense?

Great question. Mobile apps are really a type of client-server app where the client moves around. A desktop app developer probably doesn't have to worry about about someone gaining access to the app who isn't already logged on the network. But with mobile apps that's not the case. The client may need to be secured and the network transmissions may also need to be secured depending on what the app does. And because Android is based on Java so like Java or C# or any other language that runs on a virtual machine it's possible to decompile it into close to the original code. So with android you have to worry about the static information (such as encryption keys) that you have hard coded in your app, as well as the dynamic information (such as usernames and passwords) that you store on the client / device as well as how you transmit the data back to the server so it can't be read or decrypted.

A beginner can take the course. It's aimed at security professionals (who won't have much if any android experience) or android developers.

Yeah, sorry of course you're right.

I'm a big fan of getting someone else to do the work. I've used OAuth on a number of projects but usually as an alternative rather than the only way login. But I don't see any reason why you couldn't use it as the only way to login.

There's synchronous and asynchronous encryption, synchronous encryption uses a single key. Like you point out that's not good as someone can decompile it and get the key and decrypt your data. But asynchronous which uses a public/private pair. It doesn't matter if someone gets the public key when they decomiple your file as all they can do is encrypt the data not decrypt it, only the private key can do that and that happens on the server not on the phone. I'll put something up on github tomorrow so you can play with it.

Thanks for the welcome. Already got some interesting questions to answer :-)

Thanks for the welcome. The training is based on the OWASP top 10 and is applicable to people working on internal projects as well as people working on external facing applications. Most of the training is for Native Android apps but there are some demos that are also for hybrid apps that you might find interesting.

Safest way is to store the API key or username/password encrypted using a public key on the device and then send it to a backend server to decrypt it using the private key via SSL.
I use Google's keyczar to create the public/private key. It's an extra lookup but it keeps the information from being compromised.
I've also seen people put it in the Account Manager but the public/private key in my opinion is safer.