My iPad 1 stayed in its Apple supplied case until I sold it just before the new iPad came out, and it was well worth keeping in the case.

Instead of browsing around for iPad 3 cases,the simplicity and functionality of my original Apple case doubling up as a stand led me to buy the Apple iPad Smart cover.

Big mistake, the cover “attaches” magnetically and comes off just as easily and offers no protection for the back of the iPad.

I’ve been trying out the Tabletwear Cover for iPad 3 from GearZap.com

Like Apples Smart Covers the TabletWare case has magnets positioned in both corners of the cover which conveniently turns off the iPad screen and locks the device.

The case is a faux leather, and unlike other iPad covers can be stood at three viewing angles (see below).

This allows a degree of flexibility when viewing movies, using Facetime or to allow typing whilst on the web.

The case can also be folded flat so you can play games etc without having to remove the pad from the case, whilst the cutouts allow access to the volume buttons, audio and dock jack.

There’s also a hole in the back to allow you to take photos with the inbuilt camera.

That latter point is the only issue I’ve really had with the case.

Whilst the cutouts do allow access to the dock and volume rocker switch, they are recessed a fair bit which means the corner of the case is being lifted every time I wedge my fingers in there to alter the volume or toggle the mute.

Now I may have packed on a “bit” of beer weight but I don’t exactly have fat fingers, unfortunate then that the corner of the internal part of the case has started to warp slightly outwards.

Despite this, I’m still really attached to the case. Leather or not, the material used for the cover allows a good grip and saved my device from an unfortunate Costa related incident.

Setup on it’s slightest angle the case allows for fairly comfortable typing, but I wouldn’t do any extended work in this position as it’s still a little steep if I rest my wrists.

In summary, a fantastic case. My iPad now goes in by bag or on the car seat with an assortment of other kit without worry of scratches, knocks spills or sliding off the seat the next time someone decides to cut me up!

Just missing a keyboard

Rating: 7/10

Both social apps exposed plain text OAuth Tokens which enable a large amount of personal information to be snaffled from accounts, and in the case of Facebook, access any website or application you’ve authorised via Facebook.

What makes 1 and 1′s plist snafu much worse, is that the application stores the password you use to manage your account and your account number in plain text.

In the image below my contract number and password are plainly visible (obfuscated here for obvious reasons)

The application in question is “1 and 1 Domain Ordering”. For those of you reading who use this application and use the same password in multiple places, take a break and go and change them all now.

Where taking advantage of copied plists required moving them to another device, this particular oversight requires no such thing.

Lifting the plain text details straight from my plist Scoopz was able to login to my account at 1and1.co.uk with no issues.

Now luckily, I don’t have any hosting or servers with 1 and 1, but If I did the management of those would appear top left under domains and webspace.

From here you could easily cause complete havoc.

Like many others I have payment info linked to my account, ordering anything from a domain to a dedicated server is a few simple clicks away, and if like me you get a whole lot of email its easy to miss a charge.

At worst you have the same password on your email and well…it’s game over.

Even if that’s not the case, a quick visit to the domain control panel and you can find your MX records changed (they tell email servers where to send your email) and have that swiftly followed by full domain hijacks or even transfers.

I’ve made numerous attempts to contact 1and1 about the issue but thus far I’ve yet to receive anything back from them.

I’ve even tried to approach them through Mikko Hypponen Chief Research Officer at F-Secure, but still nothing back at time of publishing.

1and1 provide a number of smartphone applications,  as I don’t have any of their other services I can’t test those applications properly.

That said it stands to reason that they are developed by the same people and thus suffer from the same issue.

I encourage users of this app to leave a review on the app store and ask 1and1 to make the required changes to sure up the security of your online property.

Hope this helps out!

Remember for maximum protection you want to prevent migration of keychain data for your app. Sure your customer will have to login again on another device, but that’s not exactly a hardship!

Encrypted Backups

When you connect an iOS device (iPhone, iPod touch, iPad) to a computer to sync with an iTunes library a backup of the data on the device is also made. The backup includes application settings and data but excludes things like the tmp and Caches folder (see this Apple support article for the full list of what is included). The backup also includes the keychain so that account passwords, WiFi passwords or any other data you choose to save in the keychain is stored. iTunes allows you to specify that the backup should be encrypted in which case a password is required to restore the backup to a device.

Keychain Migration

You may decide that it is not worth the effort of encrypting the backup data especially since it is questionable how secure the backup really is. However even if you are not worried about the security of the backup there is a really good reason why you might want to encrypt the backup.

An unencrypted backup can only be restored the original device that it was taken from. This means that if you buy a new device you will have to enter keychain data such as account settings and passwords manually. An encrypted backup can be restored to a different device avoiding a whole load of pain. The only requirement is that you remember the password as you will be asked for it when you attempt the restore.

This ability to migrate keychain data between devices was introduced in iOS 4 but I think has been overlooked somewhat both by users and application developers. In fact the keychain services allow the application developer a fine degree of control on how data is handled when it is backed up.

Data Protection

As well as providing a means to migrate keychain data iOS 4 also introduced a more sophisticated level of data protection for data stored on the device itself. The iPhone 3GS introduced hardware based encryption of data on the device but it seems that is what not too difficult to circumvent. Things have hopefully been improved with iOS 4:

• The user entered passcode is now used to protect the hardware encryption keys providing an additional layer of protection.
• The application developer can specify when encrypted data should be available (e.g. only when the device is unlocked).
• Keychain data can be set as migratable or non-migratable preventing it from being restored to a new device if required.
• Separate encryption keys are used to encrypt the keychain data and the device filesystem

To enable data protection you need to set a passcode for the device (Settings > General > Passcode) once you do that you should see a confirmation that data protection is enabled at the bottom of the Passcode Lock settings screen:

As it would happen there have been some reports that the iOS hardware encryption has been cracked though this looks like it involves a brute force attack on the user passcode. By default the passcode is a simple 4 digit pin code giving only 10,000 combinations which it is claimed can be broken in under 40 minutes on an iPhone 4. To defeat this attack you can set a stronger passcode by turing off the Simple Passcode option in the settings screen. You can then enter a longer and stronger alphanumeric passcode. You can also set the device to erase all data after 10 failed passcode attempts to be extra sure.

Data Protection Classes

The keychain services provide API access to add, update, search and delete items from the keychain. Refer back to the Use Your Loaf article on simple keychain access for the full details and example code. What I want to cover here are the additional data protection classes that can be used to control the availability of the data stored in the keychain. Basically you can choose between three classes of availability for keychain data:

• Unlocked: data can only be accessed when the device is unlocked (which of course may require the user to enter the passcode).
• After first unlock: data can be accessed when the device is locked provided it has been unlocked at least once since the device was started.
• Always: the data is accessible always even when the device is locked

For backward compatibility the default is “always” though Apple recommends that you use the most protective class possible. This is generally “unlocked” unless you have an application that needs to access keychain data when running in the background (the user might lock the device whilst your app is running cutting off its access to the keychain). In the situation where you might need to access the keychain of a locked device you should use the “after first unlock” class.

If you are hanging onto data that you have retrieved from the keychain then you also need to ensure you purge this data when the user locks the device. Apple provides application delegate methods and notifications to make it easy for you to do this. Your application has about 10 seconds to clean up before the keychain service is locked. Attempting to access it after that point will generate an error until the device is unlocked again.

As well as being able to set the availability of the keychain data you can also control how it is handled when the keychain is migrated to a new device. Remember if the user has an encrypted backup they can restore the keychain contents to a different device. By default all data added to the keychain is set as migratable. If you want the data to only be available on the current device you must set it to be non-migratable.

Apple actually defines six data protection classes consisting of migratable and non-migratable versions of the three data availability classes. If you do nothing the keychain defaults to the most open option so data will be available always and migratable.

Keychain Item Accessibility

In this post I want to be able to experiment with the various keychain migration and data protection options. To make this easier I am using a simple wrapper class (UYLPasswordManager) to hide some of the complexity of the keychain services. I will dig into the implementation of that class in a later post – it is largely a reworking of some previous code that Use Your Loaf used in a much earlier post on simple keychain access. So to get started I should introduce the basic methods for storing and searching for items in the keychain:

Accessing the shared instance

A shared instance of the UYLPasswordManager class is used to allow some caching of the previous keychain access. This makes repeat searches fast. To access the shared instance use the class method sharedInstance:

UYLPasswordManager *manager = [UYLPasswordManager sharedInstance];

Registering a Username and Password in the Keychain

To store a username (identifier) and password (key) in the keychain use the instance method: registerKey:forIdentifier:

[registerKey:@"password" forIdentifier:@"username"];

Searching the Keychain

To search the keychain for an existing username and password use the instance method validKey:forIdentifier:

BOOL result = [manager validKey:@"password" forIdentifier:@"username"];

The result is YES if a matching username and password is found, otherwise NO is returned.

The Example App

With just those three simple methods we can create a simple example app to store and retrieve an item from the keychain. Once we have that working we can examine the effects of changing some of the data protection options. The simplest example app that I could come up with prompts the user for a username and password and then reports whether it is found in the keychain. The user interface is shown below:

The view controller interface is very simple consisting of some text fields and labels. The view controller also implements the UITextFieldDelegate protocol. I will not show it here but the delegate of the password text field is set in Interface Builder so that we get informed when the user hits return in the password field. The interface definition is as follows:

@interface PasswordManagerViewController : UIViewController <UITextFieldDelegate> {
}
@property (nonatomic, retain) IBOutlet UILabel *pmLabel;
@property (nonatomic, retain) IBOutlet UITextField *username;
@end

In the view controller implementation we use the viewDidLoad method to store a hard-coded username and password in the keychain using the registerkey:forIdentifier: method:

- (void)viewDidLoad {
[[UYLPasswordManager sharedInstance] registerKey:@"secret" forIdentifier:@"manager"];
}

The text field delegate method (textFieldShouldReturn:) is called when the user hits return so we perform a search of the keychain at that point and display the result:

- (BOOL)textFieldShouldReturn:(UITextField *)textField {
self.pmLabel.hidden = NO;
[textField resignFirstResponder];

NSString *identifier = self.username.text;

NSString *key = textField.text;

if (identifier) {

UYLPasswordManager *manager = [UYLPasswordManager sharedInstance];

if ([manager validKey:key forIdentifier:identifier]) {

self.pmLabel.text = @"Success";

} else {
self.pmLabel.text = @"Failed!";
}
}
return YES;
}

Migration and Data Protection Options

So with the basics up and running we can start to experiment with the data protection options. Again to keep things easy the UYLPasswordManager has two properties to make it easy to specify migration and data accessibility of any items added to the keychain:

@property (nonatomic,assign) BOOL migrate;

@property (nonatomic,assign) UYLPMAccessMode accessMode;

The migrate property is a boolean which controls whether items added or updated to the keychain are migratable. As I explained in the previous post the keychain provides the option to specify whether an item can be migrated to a new device. If a user restores an encrypted backup to a new device the keychain items which are set to migratable will be restored to that device. This allows a user to migrate to a new device without having to manually enter password data. By default items are migratable.

The accessMode property is a little more complicated as it is an enumerated type taking thee possible values as follows:

• UYLPMAccessibleWhenUnlocked - data can only be access when the device is unlocked.
• UYLPMAccessibleAfterFirstUnlock - data can be accessed when the device is locked provided it has been unlocked at least once since the device was started.
• UYLPMAccessibleAlways - data is accessible always even when the device is locked.

The default is the most secure option, UYLPMAccessibleWhenUnlocked, which means that a keychain item cannot be retrieved when the device is locked. Note that these attributes apply to each item that is added to the keychain. When we dig into the implementation we will see that these two properties actually combine into a single attribute that is set on a keychain item (which can therefore have 6 possible values).

It is difficult to demonstrate the impact of setting the migrate option to NO since it requires a device restore. Also most of the time you probably want to leave keychain items set to be migratable. The only time you might want to change this is if you have keychain data that is only relevant to a specific device.

It is easier to play with the data protection option since the keychain services provide an application delegate method, applicationProtectedDataWillBecomeAvailable: and a notification, UIApplicationProtectedDataWillBecomeUnavailable, to allow us to detect when the device is about to be locked. Apple recommends that you use these to cleanup any user sensitive data when the device is being locked.

Since the UYLPasswordManager shared instance caches the previous keychain search it needs to have its data purged when the device is locked. A purge method makes that easy:

[[UYLPasswordManager sharedInstance] purge];

The application delegate method is useful if you can perform all of the data cleanup in the application delegate which is true in this simple application. In real life you may find it more useful to have individual view controllers listen for the notification so that they can perform their own cleanup.

Detecting when the device will lock

To illustrate the technique we can add an observer for the notification as follows:

[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(deviceWillLock)
name:UIApplicationProtectedDataWillBecomeUnavailable
object:nil];

The deviceWillLock is called when the user has decided to the lock the device at which point you have about 10 seconds before the keychain protected data becomes unavailable. To test this out I created a method as follows to purge the UYLPasswordManager cache and then check the keychain after 10 seconds:

- (void)deviceWillLock {
NSLog(@"device is about to be locked");
[[UYLPasswordManager sharedInstance] purge];
[self performSelector:@selector(checkKey) withObject:nil afterDelay:10];
}

The checkKey method attempts to search the keychain and outputs the result:

- (void)checkKey {
NSLog(@"checkKey");
UYLPasswordManager *manager = [UYLPasswordManager sharedInstance];
if ([manager validKey:@"secret" forIdentifier:@"manager"]) {
NSLog(@"Password valid");
}
}

If we try this with the app running on a real device (this will not work with the simulator) we get the following:

2011-06-01 21:59:01.515 PasswordManager[20599:707] device is about to be locked

2011-06-01 21:59:11.527 PasswordManager[20599:707] checkKey

2011-06-01 21:59:11.542 PasswordManager[20599:707] searchKeychain for identifier: manager - Interaction with the Security Server is not allowed

The final message is logged by the UYLPasswordManager class and is the error returned by the keychain services when we tried to access our item with the device locked. To make the item accessible when locked we can set the accessMode before register the key as follows:

UYLPasswordManager *manager = [UYLPasswordManager sharedInstance];
manager.accessMode = UYLPMAccessibleAlways;
[manager registerKey:@”secret” forIdentifier:@”manager”];

Now when we run the same test we are able to access the data with the device locked:

2011-06-01 22:04:43.897 PasswordManager[20631:707] device is about to be locked

2011-06-01 22:04:53.923 PasswordManager[20631:707] checkKey

2011-06-01 22:04:53.980 PasswordManager[20631:707] Password valid

Handling the background

There is a small issue with relying on the application delegate or notification to allow us to perform some cleanup when the device is locked. If our app is suspended in the background when the user locks the device we do not get a chance to react. So unless you need to access keychain data when you are running in the background it is a good idea to clean up as the app moves to the background. That is easy enough to do if we implement the correct application delegate:

- (void)applicationDidEnterBackground:(UIApplication *)application {
[[UYLPasswordManager sharedInstance] purge];
}

To sum up if you are storing sensitive user data in the keychain you should think about setting the appropriate data protection class for that data. I have found that wrapping the keychain code into a separate class keeps my application code simple. I will cover the details of the UYLPasswordManager class in a future post but if you want a sneak peak you can find the full code for the Use Your Loaf's example app here.

The UYLPasswordManager class

I have tried to keep the interface to the UYLPasswordManager class as simple as possible. Ideally I want the most common use cases to be baked into the class by default with a minimum of properties and methods to store and retrieve passwords to the keychain. The actual interface definition is show below and I will step through each of these methods to show the detailed implementation. For an example of how to use this class refer back to part 2 of this series of posts.

@interface UYLPasswordManager : NSObject;

@property (nonatomic,assign) BOOL migrate;

@property (nonatomic,assign) UYLPMAccessMode accessMode;

 

+ (UYLPasswordManager *)sharedInstance;

+ (void)dropShared;

- (void)purge;

- (void)registerKey:(NSString *)key forIdentifier:(NSString *)identifier inGroup:(NSString *)group;

- (void)deleteKeyForIdentifier:(NSString *)identifier inGroup:(NSString *)group;

- (BOOL)validKey:(NSString *)key forIdentifier:(NSString *)identifier inGroup:(NSString *)group;

- (void)registerKey:(NSString *)key forIdentifier:(NSString *)identifier;

- (void)deleteKeyForIdentifier:(NSString *)identifier;

- (BOOL)validKey:(NSString *)key forIdentifier:(NSString *)identifier;

@end

The only prerequisites to using the class are that you link with the security framework (“Security.framework”) and include the class header file. It requires a minimum of iOS 4.0.

Creating the shared instance

I use a shared instance of the UYLPasswordManager to allow the results of a keychain operation to be cached. The shared instance is created the first time it is accessed with subsequent accesses returning a reference to the instance. This is not quite the same as a singleton instance as I take no steps to prevent other instances of UYLPasswordManager objects from being created by direct calls to alloc and init. However I find for iOS apps the simpler approach of a shared instance is sufficient. The code to create and drop the shared instance are shown below:

static UYLPasswordManager *_sharedInstance = nil;

+ (UYLPasswordManager *)sharedInstance {

if (_sharedInstance == nil) {
 _sharedInstance = [[self alloc] init];
}
return _sharedInstance;
}
+ (void)dropShared {

if (_sharedInstance) {
[_sharedInstance release];
_sharedInstance = nil;
}
}

Hopefully this is fairly self explanatory, the sharedInstance method checks to see if we already have an object allocated in which case it is returned otherwise we allocate and init a new object. The dropShared method provides a way to release the shared instance though in practise this should not be necessary since the idea of the shared instance is that once created it lives for the life of the application.

Properties

Before looking at the class initialiser we will do a quick tour of the public and private properties of the class along with their accessor methods. There are two public properties that the user of the class can use to control whether a keychain item is migratable and which data protection class it will use (always available, available after first unlock or only available when the device is unlocked). There is nothing special about these two properties which are declared in the public interface we saw earlier. The getter/setter methods are synthesized in the class implementation. The only piece I did not show is the definition of the enumerated type UYPMAccessMode which is used for the accessMode property. This is defined in the interface file as follows:

typedef enum _UYLPMAccessMode {

UYLPMAccessibleWhenUnlocked = 0,

UYLPMAccessibleAfterFirstUnlock = 1,

UYLPMAccessibleAlways = 2

} UYLPMAccessMode;

The class has three other properties which are defined as part of the private interface inside the class implementation file as follows:

@property (nonatomic,retain) NSString *keychainValue;

@property (nonatomic,copy) NSString *keychainAccessGroup;

@property (nonatomic,copy) NSString *keychainIdentifier;

The keychain value property is used to store the value of the item that is retrieved from a search of the keychain. The other two properties are used to copy the keychain access group and identifier that are parsed as arguments by the caller in many of the class instance methods as we will see shortly.The getter/setter methods of all of these methods are synthesized by the compiler with the exception of the setter for the last two where we specify our own implementation. Here is the setter for the keychainIdentifier property (the keychainAccessGroup setter is very similar so I will omit it):

- (void)setKeychainIdentifier:(NSString *)newValue {

 if (!_keychainIdentifier && !newValue)  {
 return;
}

 [_keychainIdentifier release];
_keychainIdentifier = nil;
self.keychainValue = nil;

if (newValue) {
 _keychainIdentifier = [newValue copy];
}
}

This is pretty much the same as a standard setter with the exception that when a new identifier is set we clear (and release) the previously cached keychainValue instance variable to force a new search of the keychain.

The Initialiser

The initialiser for a new instance of the class is not very exciting, after taking care of the standard stuff of calling the initialiser of its superclass it sets some defaults for the keychain attributes as follows:

- (id)init {
self = [super init];
  if (self) {
      _migrate = YES;
    _accessMode = UYLPMAccessibleWhenUnlocked;
}
 return self;
}

So by default all items added or updated to the keychain will be set to be migratable and will use the most protected data class which ensures they can only be accessed when the device is unlocked. Most of the time these defaults should be correct so it keeps things nice and simple for the user of the class.

The Public Methods

The public instance methods are fairly simple as the hard work of interacting with the keychain services is performed by a number of private helper methods. The methods to register, search for and delete a key are all available in two forms the only difference being that one set of methods omits the access group argument. I have previously discussed keychain group access to share keys between applications but since my guess is that most of the time it will not be used I opted to create a set of convenience methods without a group argument. Since these methods just call the fuller method with the group argument set to nil I will not show them here.

To get started we will take a look at the implementation of the method to register a new key with the keychain service. To store an item in the keychain you need to supply an identifier, most commonly a username or some other means of identifying the key, and the actual key which is the password or thing that you want to keep secret. The implementation is as follows:

- (void)registerKey:(NSString *)key forIdentifier:(NSString *)identifier inGroup:(NSString *)group {

 self.keychainAccessGroup = group;
   self.keychainIdentifier = identifier;
   [self searchKeychain];

  if (self.keychainValue == nil) {

     [self createKeychainValue:key];

   } else {

      [self updateKeychainValue:key];
  }

   [self searchKeychain];
 

}

This method starts by copying the access group and identifier into our instance variables for future reference. It then calls a helper method which we will see shortly to search the keychain to determine if we already have an entry for the specified identifier. Depending on the results of the search we then either call a method to create a new entry to store the key or update the existing entry. Finally we perform a keychain search to ensure our cached keychain value is valid.

The method to search the keychain accepts the usual arguments of an identifier and key and optionally an access group and returns a boolean to indicate if the search was a success or not.

- (BOOL)validKey:(NSString *)key forIdentifier:(NSString *)identifier inGroup:(NSString *)group {

   BOOL result = NO;

   if (identifier) {
        self.keychainAccessGroup = group;
     self.keychainIdentifier = identifier;
       [self searchKeychain];

      if (self.keychainValue != nil) {
            if (key != nil) {

if ([self.keychainValue isEqual:key]) {
result = YES;
}

} else {
result = YES; } } } return result;
}

As before the access group and identifier arguments are copied into our instance variables and then the method to search the keychain is called which will result in the keychainValue being set if the identifier was found. If we do not get a keychainValue back we return NO to the caller.

In some cases I am using the keychain to register that the user has completed an action, for example that they have registered a product. In that situation I do not really have a password key to store but it is useful to register an identifier in the keychain with some arbitrary key (the application name for example). Since in those situations I really only want to check to see if the identifier exists in the keychain I allow the key argument to validKey:forIdentifier:inGroup to be nil and do not bother to check that the key value actually matches.

The method to delete a key is shown below and simply calls the deleteKeychainValue private method after storing the arguments as usual:

- (void)deleteKeyForIdentifier:(NSString *)identifier inGroup:(NSString *)group {

     self.keychainAccessGroup = group;
  self.keychainIdentifier = identifier;
  [self deleteKeychainValue];
}

The final public method is the purge method which is used to empty the cached keychainValue instance variable in situations where the device is about to be locked or the application is moving to the background. Refer to post 2 in this series for a more detailed discussion for how and why you may want to do this.

- (void)purge {
 self.keychainAccessGroup = nil;
self.keychainIdentifier = nil;
 self.keychainValue = nil;
}

Private Methods

The heavy lifting of interacting with the keychain services is performed by a number of private methods. These methods are similar to ones discussed in earlier posts on the keychain so I will keep some of the explanations brief. If you are wondering about the various keychain classes and attributes refer back to that post for the full details. All of the interactions with the keychain API take a dictionary of attributes that indicates the class of item you want to store. We will be storing a generic password in the keychain so we need to initialise a dictionary as follows:

- (NSMutableDictionary *)newSearchDictionary {

NSMutableDictionary *searchDictionary = nil;

if (self.keychainIdentifier) {
 NSData *encodedIdentifier = [self.keychainIdentifier dataUsingEncoding:NSUTF8StringEncoding];
  searchDictionary = [[NSMutableDictionary alloc] init];
   [searchDictionary setObject:(id)kSecClassGenericPassword forKey:(id)kSecClass];
  [searchDictionary setObject:encodedIdentifier forKey:(id)kSecAttrGeneric];
   [searchDictionary setObject:encodedIdentifier forKey:(id)kSecAttrAccount];
  [searchDictionary setObject:kKeychainService forKey:(id)kSecAttrService];
 if (self.keychainAccessGroup) {
   [searchDictionary setObject:self.keychainAccessGroup forKey:(id)kSecAttrAccessGroup];
  }
}

return searchDictionary;

}

The keychainIdentifier instance variable is encoded and used as the keychain account name. Note the use of a keychain service (kSecAttrService) and account name (kSecAttrAccount) attribute are required to uniquely identify a generic password item in the keychain (see this post on duplicate items for the details).

The methods to create, update and delete a keychain entry are then just variations of the same basic theme. First here is the method to search the keychain for the identifier stored in the private instance variable keychainIdentifier:

- (void)searchKeychain {

if (self.keychainValue == nil) {
NSMutableDictionary *searchDictionary = [self newSearchDictionary];
[searchDictionary setObject:(id)kSecMatchLimitOne forKey:(id)kSecMatchLimit];
 [searchDictionary setObject:(id)kCFBooleanTrue forKey:(id)kSecReturnData];
NSData *result = nil;
 OSStatus status = SecItemCopyMatching((CFDictionaryRef)searchDictionary, (CFTypeRef *)&result);
[searchDictionary release];
 if (result) {
self.keychainValue = [[NSString alloc] initWithData:result encoding:NSUTF8StringEncoding];
[result release];
 }
 }
}

The search method uses the Keychain function SecItemCopyMatching to perform the search with the attributes kSecMatchLimit and kSecReturnData to indicate we only want the first entry returned. If we find a value it is decoded and stored in the keychainValue instance variable.

The method to create keychain item uses the SecItemAdd function. The update method is very similar so I will omit it here for brevity but it makes use of the SecItemUpdate fucntion.

- (BOOL)createKeychainValue:(NSString *)password {

NSMutableDictionary *dictionary = [self newSearchDictionary];
NSData *passwordData = [password dataUsingEncoding:NSUTF8StringEncoding];
[dictionary setObject:passwordData forKey:(id)kSecValueData];
[dictionary setObject:(id)[self attributeAccess] forKey:(id)kSecAttrAccessible];
 OSStatus status = SecItemAdd((CFDictionaryRef)dictionary, NULL);
 [dictionary release];

if (status == errSecSuccess) {
return YES;
 }
 return NO;
}

The interesting thing to note here is the kSecAttrAccessible attribute which is used to set the data protection class of the keychain item. The Keychain Service data protection class is determined from a combination of the two public properties (migrate and accessMode) of the UYLPasswordManager class. The data protection class is calculated by the method attributeAccess as follows:

- (CFTypeRef)attributeAccess {

switch (self.accessMode) {
case UYLPMAccessibleWhenUnlocked:
return self.migrate ? kSecAttrAccessibleWhenUnlocked :
                          kSecAttrAccessibleWhenUnlockedThisDeviceOnly;
break;
 case UYLPMAccessibleAfterFirstUnlock:
return self.migrate ? kSecAttrAccessibleAfterFirstUnlock :
                          kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly;
break;
case UYLPMAccessibleAlways:
return self.migrate ? kSecAttrAccessibleAlways :
                          kSecAttrAccessibleAlwaysThisDeviceOnly;
break;
default:
return self.migrate ? kSecAttrAccessibleWhenUnlocked :
                          kSecAttrAccessibleWhenUnlockedThisDeviceOnly;
   break;
  }
}

So using the default settings of an item that is migratable and which can be accessed only when the device is unlocked we end up with a data protection class of kSecAttrAccessibleWhenUnlocked.

Finally the method to delete a keychain item which uses SecItemDelete:

- (void)deleteKeychainValue {

  NSMutableDictionary *searchDictionary = [self newSearchDictionary];
 if (searchDictionary) {
   OSStatus status = SecItemDelete((CFDictionaryRef)searchDictionary);
   [searchDictionary release];
  }
  self.keychainValue = nil;
}

Wrapping Up

Use Your Loaf's intention was to take all of the tricky keychain code and wrap it with an easy to understand and hopefully easy to use class, and they did an outstanding job!

If you want to see the code and try it yourself you can download it from here.

Not only is their blog post oozing with professionalism and good practice, but Jeff (the author of the post) goes onto explain exactly why the plain text OAuth details were an issue and what steps were taken to improve security.

App developers wondering how to approach securing their own apps, this is how it’s done.

As Jeff explains, “[...]we put the OAuth information into the iOS keychain using the “ThisDeviceOnly” data protection class that will not allow the OAuth token to be copied from the device unencrypted. There is a bit of terminological muddle in that “ThisDeviceOnly” and “ProtectionComplete” mean the same thing except that the former is used with keychain items and the latter used with files. I prefer the term “non-migratable” to cover both.

The application property lists files, plists, contain app preference settings, and this plists do not have the non-migratable restriction on them; they are fully accessible once the device has been unlocked. Note that data with the non-migratable restriction  cannot be restored from an iTunes or iCloud backup to a different device. So if you replace your iPhone or iPad, you will need to re-enter your Dropbox credentials to reestablish automatic syncing.”

Source: http://blog.agilebits.com/2012/04/06/oauth-dropbox-and-your-1password-data/

Still, they have fixed it, which is a heck of a lot more than Facebook has done!

Further testing on popular social apps has revealed that LinkedIn also suffers from the plist credentials vulnerability.

What makes this more confusing is that the LinkedIn plist contains the deviceID, so why does an unmodified copy of the plist allow @scoopz to login to my LinkedIn account?

It really isn’t difficult to store credentials in the keychain or salt auth keys with the device mac address to prevent this. As users become more aware of tools like IExplore hopefully developers will pay more attention to where they store sensitive information.

See the full details on scoopz blog

• Screen Protector with every case - Case also works with Smart Cover

Not an access token but full oAuth key and secret in plain text. Surely though, these are encrypted or salted with the device ID…unfortunetly not.
Worryingly the expiry in the plist is set to 1 Jan 4001!

Quick export and call to my good friend and local blogger Scoopz and I sent over my plist for him to try out.
After backing up his own plist and logging out of Facebook he copied mine over to his device and opened the Facebook app…
My jaw dropped as over the next few minutes I watched posts appear on my wall, private messages sent, webpages liked and applications added.
Scoopz then opened Draw Something on his iPad which logged him straight into my account where he sent some pictures back to my friends.
Even after restoring his own plist he still gets notifications for my games.
Having installed my Plist on 4 different devices with no warning I contacted Facebook.

In an email response dated 29 March 2012 20:41:11 GMT+01:00 a representative of the Facebook security team confirmed that the issue had already been reported and:

“We are working to fix it.

Thanks for contacting Facebook,

Emrakul
Security
Facebook”
After contacting Facebook I took the liberty of knocking together a few proof of concepts.
1) A hidden application (malware) which runs on shared PC’s Any device plugged in to charge has the Plist copied
2) A recompile of an open source iphone explorer like program with the added code
3) A saved game editing tool with the added code
4) A credit card sized hardware solution that takes all of two seconds to copy the plist should you have physical access to an iDevice
5) A modified speaker dock
Over the course of a week over 1000 vulnerable plists were located and counted, though I hasten to add at no point was any data copied. (To clarify a 1000+ plists with open information re: facebook tokens or auth keys inc. 3rd party apps)
Facebook are aware and “working on” closing the hole, (why the haven’t used the keychain is anyones guess) but unless app developers follow suit and start encrypting the 60 day access token Facebook supplies, it’s only a matter of time before someone starts using the info for ill purpose…if they aren’t already.
Until Facebook plug the hole, I’ll be thinking twice about plugging my devices into a shared PC, public music docks or “charging stations”.

UPDATE

I’ve been told this also works on Android devices, though I’ve not had the opportunity to put that to the test yet.

Though given the programming oversight in the iOS app, it stands to reason the issue will translate to other platforms.

I feel I should reiterate, Facebook are playing this down and that’s fine, but saying it only effects stolen and jailbroken phones is not. 

The biggest risk is from malware and viruses designed to slurp data from devices plugged into PC’s, so despite what any other articles say; jailbroken or not you ARE vulnerable!

When tested this worked on locked passcoded unmodified iOS Devices (Passcoded devices exploitable if plugged into a computer a user has previously synced to OR if device is unlocked whilst still connected to a shared computer)

According to some articles Facebook say this isn’t really fixable, but they could at least add 2nd-tier authentication or at a minimum warn a user when another device has been used to access their account.

They do that for the web, why not mobile devices….

UPDATE:LinkedIn is also vulnerable

• for all Canon SLRs with maximum size of APS-C sensor
• This compact, great-value 10-24 mm f/3.5-4.5 DiII LD aspheric [IF] zoom lens from Tamron is a must-have accessory fortravelling photographers
• Featuring a focal length range with the 35mm equivalent of 16-37mm, the 10-24 mmf/3.5-4.5 Di II LD aspheric [IF] zoom lens is able to reproduce the grandnessof sweeping landscapes or the intimacy of tight spaces.  Spectacular views are enhanced as the 10
• These work togetherto considerably reduce distortion and have earned the 10-24 mmf/3.5-4.5 Di II lens its SuperPerformance (SP) rating
• 12 month UK warranty included

More Tamron Lenses Products

• Prevents scratches / finger marks on the screen
• Makes it so simple to type on your mobile phone
• Made from high quality material
• Prevents from, bumps, grease and finger prints on the screen
• Compact and light weight design

Makes it so simple to type on your phone

Made from high quality material

Prevents bumps, grease and finger prints on the screen

Compact and light weight design

Contents

1 x HQ Stylus Pen

Find More IPad Accessories Products

In doing so, I showed how you could modify configuration files to bypass these charges and play free.

Today I’m going to the same to scramble with friends.

Scrabble with friends is a boggle type game just with the added social interactions made popular the other games in the with friends series.

Each player starts out with ten Tokens. To get more kinds of tokens you need to click get tokens and use real-world money to buy tokens or you can wait hours to get an extra token.

That might not sound like a big deal, but each round costs a token to play, and each game has three rounds.

As you will now realise this is a very quick way for Zynga to make some money.

By now you’re probably all wondering where is the chase and how do we cut to it?
So no further ado, go ahead and open Ifile if you have it, or if you don’t have a jailbroken device you need to plugging your idevice into your PC or Mac and open IExplorer on your PC or Mac.

You need to navigate to the scramble directory under applications if you’re not sure how to do this look at the cheats for Dream Heights post on the blog.

Once in that directory go into the scramble with friends paid.app or free.app if you’re using the free version.

Next you need to edit GameConstants.Plist
This can be done directly in ifile or if using IExplorer copy game constants to your desktop edit it then drag-and-drop it back onto iExplorer.

In the game constants file you’re looking for two values. Nothing here says token, they’re referred to as energy. You need to edit maxenergy and minenergy.
If you set the maximum energy to 80 and the minimum energy to 80 it doesn’t matter how much energy something costs you’ll never lose any.

Your file should look something like this:

That’s it, just make sure to fully close scramble from the multitasking bar and reopen.

There was feeling a little more brave might want to take a look at the boosts Plist file