Hacker News new | ask | show | jobs
by kurtsiegfried 5644 days ago
The main issue I have with this article is that it describes a very implausible circumstance in my opinion. If you have an application with such sensitive information on the phone to warrant this kind of testing, why would you not take advantage of the device administration policies to enforce a password policy and a password timeout policy?

http://developer.android.com/reference/android/app/admin/Dev...

There doesn't seem to be a policy in the current API docs to prevent a user from enabling USB debugging, but there is a rather large warning when that option is selected.

Without USB debugging and using a password policy, the author's strategy would not have worked. With the current strategy, this has nothing to do with Android, and everything to do with having poorly designed and poorly implemented security on the part of the application author.

1 comments

The software under test is designed to allow employees to use their personal phones for corporate use. Being a personal phone, corporate policies are irrelevant because we cannot apply or enforce them. The software is in use by some very large companies and being evaluated by others therefore it is far from implausible that some of those personal phones haven't got a device lock code set.

I agree it is not an Android issue though, it is the poor design of the app.

A more common policy in my experience is that any phone that has any company data on it must be company-managed. In other words, you pay for it but the company really owns it.
@Thomas, thanks for the clarification, I guess I'm just used to companies with more authoritarian policies. Something along the lines of: "If it connects to our infrastructure, it gets policies enforced" (similar to what WMF said).

Nice work on taking apart the app though.

Yes that is my experience as well and is the case where I work. This seems to be changing as more tech-savvy staff with highly capable devices push their companies to "get with the times". So I guess that is why we're there to point out the risks in doing so. Doing this was partly fun, and partly so we could backup any statements we made about the risks of doing it.

Anyway, glad people enjoyed it. It's good to get some discussion going too. Thanks =D