iPhone passcode bugs revealed

02. September 2009
As an IT security professional, I was tasked with evaluating the iPhone's security features for the enterprise (more iPhone management tests ). Over the past few weeks, I have been testing different aspects of the new iPhone 3GS, particularly the interaction with Exchange ActiveSync (EAS) and device password policies. During my testing, I discovered some strange behaviors with how the iPhone handles device password policies, as well as passwords altogether.

iPhoneiPhone security considerations, Part 1 | Part 2 Alles zu iPhone auf CIO.de

It has already been proven that the passcode on an iPhone can be removed. The purpose of this article is to point out the false sense of security delivered through AppleApple's marketing of iPhone features for the enterprise. My testing has revealed that the enterprise security features do not behave correctly and I will point out three flaws with how passwords are handled with the iPhone and EAS. Alles zu Apple auf CIO.de

The setup for my testing consisted of a 16GB iPhone 3GS running firmware 3.0.1. The iPhone was configured to use Exchange ActiveSync mail going through a proxy server. The proxy server was an F5 Firepass which provides similar functionality as an ISA server to proxy connections to EAS. The Exchange server was running Exchange 2003 SP2 with EAS enabled and configured with device password policies. I set up the device password policy on the Exchange server to enforce a password with a minimum of four characters and a 20 minute inactivity timeout. This means that any mobile device connected to Exchange that is idle for 20 minutes will automatically lock and require a password to access the device.

Bug 1 -- iPhone does not handle EAS Policies as expected

With Exchange ActiveSync, administrators can configure device password policies. According to MicrosoftMicrosoft, the "Inactivity Time" option determines how long the device needs to be inactive before the user is prompted for the password. I first tested my EAS settings against a Windows Mobile Device. The results were as expected, with the device requiring me to set a password and after 20 minutes of inactivity, requiring me to enter my password. Alles zu Microsoft auf CIO.de

Zur Startseite