iPhone passcode bugs revealed

About the author: Jay Sartori, CISSP, Security+, CCSP, MCSE, is an IT security analyst with over 12 years of IT experience. He has a bachelor’s degree in computer engineering and a master’s in network security management.

As an IT security professional, I was tasked with evaluating the iPhone’s security features for the enterprise . 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.

iPhone security considerations

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 Apple’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.

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 Microsoft, 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.

The iPhone behaved differently. First, you need to understand two settings on the iPhone which pertain to passwords: “Auto-Lock” and “Passcode Lock.” “Auto-Lock” sets the amount of time in minutes before the screen locks. The purpose of this is to save battery life by dimming the screen and to prevent accidental pocket dialing. “Passcode Lock” determines the amount of time in minutes after the Auto-Lock sets in, before a password needs to be entered. This can be configured at 1 min., 5 min., 15 min., 1 hour, 4 hours or never.

Upon successfully connecting to EAS, I was required to set a password as expected. After I set up my password, I reviewed the settings on the iPhone and saw that Auto-Lock was set to 5 minutes and Passcode Lock was set to 15 minutes. This appeared to be correct as the total adds up to 20 minutes before requiring a password to be entered. Surprisingly, however, I was able to change the “Passcode Lock” on the iPhone up to a maximum time of 1 hour. I did notice that I could not set the Passcode Lock to 4 hours or never as those options were apparently removed after connecting to EAS. This allowed me to change the Passcode Lock up to a maximum of 1 hour for a total of 65 minutes (5 for the Auto-Lock and 1hr for the Passcode Lock) before requiring a password.

This means in a corporate environment, users are able to override inactivity timeout settings defined by administrators, as the iPhone does not respect the EAS policy. This gives a false sense of security to administrators and they need to be aware of this behavior. If Apple is going to advertise integration with EAS security policies, then they need to ensure the iPhone respects the settings and behaves accordingly.

Bug 2 – Passcode Prompt Reveals Too Much Information

I’m really not sure how this next bug made it by the quality assurance team, specifically security testing. For this example, let’s assume you set your password to “abc123” and your device gets locked. You are prompted to enter your password with the iPhone keyboard and, as you type, asterisks are displayed across the screen .

This is typical and expected behavior. Note that the input box does not give any indication as to the length of the password or the complexity of the password as you can enter numbers, letters and special characters.

But if you change your password to “1234” or any four-digit numeric password for that matter, from then on you lose the ability to enter any letters or special codes . This reveals two pieces of information about your password: 1) that it consists of only numbers, and 2) the password is only four digits long. From a brute-force perspective that is only 10,000 possible combinations, which would be trivial for any type of offline attack. Knowing this behavior of the iPhone, you may want to consider requiring passwords to require at a minimum both numbers and letters in your EAS policy.

Bug 3 – Changing your iPhone Passcode

This next bug has some similarities to Bug 2. Let’s assume that you realize that your four-digit numeric password is weak and reveals too much information. You decide to change your password from numbers to something alphanumeric. What I discovered is you cannot do this. Once your password is changed to four digits, when you go to change the password, you are only given the option to change it to another four-digit numeric password. On the other hand, if your password is already alphanumeric, you can change it to any length and any combination of numbers, letters and special characters. This is clearly a bug with the iPhone OS.

The workaround to this was to remove the Exchange account from the iPhone and add it back. Upon adding the Exchange account back, I was prompted to enter a new password which allowed me to enter a complex password.

Summary

The iPhone is a great device and is arguably the best mobile device from a usability perspective. Unfortunately, the security features are not quite ready for the enterprise and contain various bugs. In order to safeguard against such bugs, data encryption has to be considered for any type of data protection, but that is another article. Enterprises considering the iPhone for corporate use need to be aware of how the iPhone security features behave and the different ways that data can be breached in the event that the device is lost or stolen.

Source: iPhone Jailbraker