Sunday, February 12, 2012

Activesync and FIPS 140-2 part 1

Perhaps the best Dilbert/Mordac ever...?
I am not Mordac. I can admit being a bit similar to Mordac once upon time, but that is a looong time ago. I'll bet I can get somebody to confirm it, at least if I get to "talk" to them a little bit before you do. ;-)

Seriously, I've been doing some testing with Microsoft Activesync in order to find some common ground across iOS & Android for setting a "good practice" password policy level. After spending some time on this, I think Mordacs work at Apple & Google. I also think that Mordac was involved in the creation of FIPS 140-2, at least when somebody thought it would be a good idea for mobile devices.

I'll explain that later on, but first 2 simple things to remember here:
1. A default policy, no matter which product, should never be considered "secure" or "good enough".
2. I say Good Practice. "Best practice" cannot be proven legally, period. There is a legal difference here.

FIPS 140-2, and why you should know about it before it hits you where it hurts - on your iPhone or iPad. You can click the images for full size versions.

On Jan. 11, 2012, Samsung announced that they had been granted FIPS 140-2 certification for 3 of their Galaxy line of phones and tables (SGSII, SGSII-LTE and Galaxy Tab 10.1 specifically, with minimum certain minimum versions of Android running). Blackberry already has FIPS 140-2, while Apple is expected to reach certification for iOS in August 2012.

Although I haven't been able to google my way into documentation that proves this next claim, several forum discussions are saying that with FIPS 140-2 certification and crypto enabled, passwords must be a minimum of length 6 alphanumeric. That is non case-sensitive alphanumeric. However, this PDF on FIPS 140-2 has these requirements (page 18):

Forgive me, but I am no friend of math and statistics...

This is the work of Mordacs. In this case, Engineers/cryptographers who believe that people will never use anything but completely random pins and passwords. Yeah, right. (I could put a thousand+ links here, but you get my point with this one.)

I am having problems seeing the complete relevance and logic between the requirements in the PDF documentation and the rumor of length 6 alphanumeric, but maybe its just me.

Lets take a look at the password policy settings in Activesync 2007, and their implications on some devices.

Click images for full size...

Activesync 2007 Default Password policy
Activesync 2007 my initial default for testing

Picture left is the Activesync 2007 password policy default.

I'm interested in protecting the information stored on my device from:
1) random attempts at my PIN/password (colleagues, friends, family, or theft)
2) attempts to actually access my data on the device or stored on an optional memory card

I have tested using my iPad 2 (iOS 5.0.1), my Samsung Galaxy S II (Android 2.3.5) and the Samsung Galaxy Nexus (Android 4.0.1).

If your mobile device supports the use of data encryption, use it. It really shouldn't make things harder than without, but it will for sure make it much harder for unauthorized individuals to access your data. Unfortunately, in this case at least, Apple, Samsung and FIPS 140-2 seems to be all Mordac.

With my starting settings (above right), requiring the use of encryption on the device and any storage card, here are some observations from my testing. Please note that I have turned off the parameter Allow Non-provisionable devices on the General tab, so that devices that doesn't support all set parameters will fail at syncing with the server.

Ipad 2
With the Allow simple password turned on and minimum length = 4, I am allowed to use 1234 as my pin. However, even though the Enforce password history is set to 0 (That's the digit zero Apple!), I am not allowed to reuse 1234, I must choose something else. Effectively, Apples interpretation of the policy is a value of 1 (one) for password history, so changing to 2345 and then back to 1234 will do. After 6 failed attempts, I got this message on screen:

Good! Password Rate limiting! I like that! Testing pins with no errors at a rate of 1 attempt per second, then waiting 60 seconds for 6 more attempts, I will need a a lot of time for testing all possible combinations. Unfortunately the default policy will wipe my iPad after 8 attempts. To some the ability of tracking their device could be of higher priority than wiping its contents, requiring default Activesync options to be changed.

I cannot set any rate limiting parameter anywhere in my Activesync policy, neither is there any options inside the iPad settings for it either. Oh well, if you are into Apple products, there are some things you need to accept, period.

Device encryption is "instant". No waiting at all, either when configuring a new Activesync account, or when removing it. VERY user/admin friendly!

Samsung Galaxy S II

Because my SGSII  is now FIPS 140-2 certified, I am not allowed to use less than 6 characters in my password. Notice the use of password here. According to rumors in several Samsung/Android forums, FIPS 140-2 require alphanumeric passwords to be used, digits only are not allowed. I haven't found any official documentation proving this claim. Please help! :-)

It gets better: due to a bug in Android 2.3.5 (latest available to me in Norway on Feb. 12, 2012), the device interpretation of the Activesync policy becomes minimum length 6 alphanumericspecial. I know people who would probably quit their jobs if they had to comply with such requirements. More on FIPS 140-2 below, but lets pick a password first:

Only password option is available
Small screen, big keyboard, but still...

I chose 1234a.

I can change my password immediately, and I receive no complaints from my SGSII when I enter the exact same password over and over again. That is in compliance with the policy. :-)

Now for the rate limiting - does it exist on my SGSII as well? Yes.

30 second Countdown 
5 attempts, wait 30 seconds

5 attempts, wait 30 seconds before you get 5 new attempts.

So, both Android (Google) and Samsung have decided to implement different understandings of the (missing) Activesync policy. Perhaps this is better aligned with FIPS 140-2?

The only thing better than having a standard is having several standards I guess? :-D

As soon as you configure an Activesync account on your SGSII with encryption required in the policy, the phone has to reboot and spend 1-2 hours (or more) encrypting the device as well as any memory card inserted into the phone.

The same process in reverse when removing an Activesync account: It takes time, and requires a pretty full battery or or being connected to a charger.

This is a mess. Just a couple of parameters tested across 2 different devices and no third-party soluons, and things are not looking user-friendly. It doesn't get better when leaving default values for something more "sustainable", which I will cover in my next part about Activesync and FIPS 140-2.