 |
| Perhaps the best Dilbert/Mordac ever...? |
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...
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:
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.
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.
 |
| 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
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.
"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."
ReplyDeleteYou are getting this wrong.
They specify that your password-/PIN-rule should produce at least 1 000 000 equally probable passwords/PINs. That has nothing to do with stating that your passwords or PINs are completely random.
Quite the contrary, assume your password-rule allows 10 000 000 different passwords, but the success rate for hitting a correct password happens to be 1/100000 (for instance, because users are known to follow particular password-patterns). Then the produced passwords are clearly not uniformly picked (not random) from the space of possible passwords, but they still conform with the specifications.
Hey Per, first of all I'd like to make a huge disclaimer that I've never been involved in submitting anything for FIPS 140-2 certification, so please take everything I say with a big grain of salt.
ReplyDeleteAs you can imagine, the actual details of these certifications can get really wonky very quickly. For example, with FIPS 140-2 it matters if the password is used for authenticating an operator (that's ok), used to create derived keys for storage applications (that's ok), or establishing authentication in FIPS mode (No, no, abort!).
I highly recommend checking out the "Implementation Guidance" for FIPS140-2 certification since that gets into more details on what's expected when submitting a device to be certified.
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf
The part talking about complying with SP800-132 might shed some light on your questions:
"NIST SP 800-132 does not impose any strictly defined requirements on the strength of a password. It says that “passwords should be strong enough so that it is infeasible for attackers to get access by guessing a password.” Therefore, the vendor shall document in the module’s Security Policy the length of a password/passphrase used in key derivation and establish an upper bound for the probability of having this parameter guessed at random. This probability shall take into account not only the length of the password/passphrase, but also the difficulty of guessing it. The decision on the minimum length of a password used for key derivation is the vendor’s, but the vendor shall at a minimum informally justify the decision"
The important thing is that the estimated strength of a password policy is left up to the vendor. Combined with the requirements for password based authentication in the main FIPS 140-2 documentation this *normally* means they need to construct an informal proof that says the chance of an attacker guessing someone's password given one guess is 1/1,000,000.
Now, the easiest way to do this is to loosely base your policy on the "entropy" guidance provided in NIST SP800-63. If you can say your policy provides at least 20 bits of entropy, and you only allow a maximum of 10 guesses per minute, you can make a good case that you are compliant. From a direct reading of Appendix A, a 6 character minimum length with a composition rule that requires "both upper case and non-alphabetic characters" provides that 20 bits of entropy.
Now, I'm not going to get into how realistic that entropy number is, (I may have some opinions on that subject...). What I'd like to focus on instead is that the 6 character complex password requirement is *not* the only solution that's acceptable. It's just the *easiest* and *safest* one for the people writing the FIPS 140-2 submission to justify.
Matt;
ReplyDeleteTHANK YOU.
That is a nice piece of clarifications, as I myself struggled to fully understand the FIPS 140-2 documentation compared to the stuff I found lying around in various forums etc. And, as documented with my SGS2 and iPad, there are different interpretations of the same policy settings in Activesync.
I'm tempted to find somebody with a Windows phone as well as some BlackBerry users to run the same tests as I did, just for the comparisons. I will not surprised if we see another 2 intepretations on how the requirements are actually implemented. Volunteers? :-)
I'm still not a fan of using entropy calculations alone as a measurement for the quality of passwords, especially for short passwords where we have a rather small keyspace and where our knowledge of common passwords will be very efficient.
As Richard Stiennon (@stiennon @cyberwar) tweeted, he's still interested in biometrics for mobile devices.
That is a reminder for me to do a new blog post about biometrics, it's been a long time since my last one: http://securitynirvana.blogspot.com/2011/02/about-biometrics.html
Hi Per,
DeleteThank you for a great blog and article.
I did some similar tests earlier this week using Office 365 Exchange Online and made a policy for my test-user. I only required use of simple-passwords and required use of encryption.
The test was done using my Samsung Galaxy Note, Samsung Galaxy Tab 10.1, hTC ONE X and HTC Titan. Both the Samsung Galaxy Note and the Samsung Galaxy Tab 10,1 required me to change my password from(4-digits) to a stronger alphanumeric password(minimum 4 digits + 2 letters). After setting my new passord (4.digits + aa)I was able to start the cryptation of both devices. When doing this same test on the hTC ONE X I did not have to change my password (4-digits). The other differens betwin the Samsung and the hTC is that hTC ONE X requires that the memory is formated (deleted) before it can be cryptated. So importend that all data is backed up before doing the encrytion of the device. The end user is well informed of the process in the wizard. So important that users also are informed and understand how to safely backing up their data before you turn on this requiement in the Exchange policy.
When testing the hTC Titan that is the only Windows Phone tested I saw as expected that the device no longer was able to sync against the Exchange server. This is because Windows Phone OS 7.5 does not support encryption and reports back to Exchange that it can't fullfill the requirements of encryption its memory.
Br Marius Fjeld
Thank you for your article. You mentioned in the article that Apple is expected to obtain 140-2 certification around August of 2012. How certain is this and is there a source online for this?
ReplyDeleteI have been trying to determine this information for some time and I know they have been in the IUT phase for well over a year (I think they moved on and were bumped back a couple of times). Also, do you happen to know if their FIPS certification will include any SSL or TLS modules inside of Safari for iOS?
Luke;
ReplyDeleteRight now I have no idea. I've seen other people talking about this stuff, saying that the entire process has stopped for Apple etc etc.
What I have been able to figure out by myself is that creating a single Activesync policy that gives iPhone/Android/WinPhone/Nokia(?) users the same security level is *impossible*. This is due to the different ways of understanding & implementing Microsofts Activesync requirements.
If you're looking for FIPS 140-2 and Exchange ActiveSync, have you considered this solution -
ReplyDeletehttp://www.thursby.com/PKard_Mail.html
This is Government / Military CAC / PIV strong two factor authentication. It can work in regular enterprise (finance, healthcare, energy etc.) using .NET (dot net) cards also.