OAuth and other security changes coming to 3.6.5

jpgoldberg

We normally don't talk about things until they are fully available to people, but I just wanted everyone to know that 1Password (Pro, for iPhone, and for iPad) was submitted to Apple at the beginning of the week, and it is just awaiting approval by Apple.



3.6.5 contains bug fixes and security improvements. I'll talk in more detail about the security improvements once it is released, but one of them is to move Dropbox OAuth tokens from the .plist to the iOS keychain.



1Password has always been very good about [url="http://blog.agilebits.com/2011/02/11/lost-iphone-safe-passwords/"]storing your Dropbox username and password securely[/url], but like many other apps (including Facebook and Dropbox itself) we were not as careful as we should have been with OAuth tokens. In 3.6.5, these too will be stored in the iOS keychain.



I don't yet know for certain what an attacker would need to be able to get your Dropbox authentication tokens yet, and need to study this a bit more. Note that even after you can move to 1Password 3.6.5, you may have other apps installed that using Dropbox syncing.



The reason that I mention this now while it is under review instead of after it is approved is that the particular OAuth problem that we fix in 3.6.5 has become news with respect to the Facebook and Dropbox apps for iOS. See



[url="http://www.macrumors.com/2012/04/06/facebook-and-dropbox-apps-for-ios-vulnerable-to-credential-theft/"]http://www.macrumors...edential-theft/[/url]



for a discussion of those.



It would have been really cool for us to have had 3.6.5 approved before this issue became news so we could say "already fixed in current version". Instead I have to say "already fixed in version submitted to Apple". Still we got this wrong the first time around. Ideally we should have had this right from the beginning.



The other big security change in 3.6.5 is using PBKDF2 with 10000 iterations. Watch our [url="http://blog.agilebits.com/"]blog[/url] and [url="http://twitter.com/#!/1password"]follow us on Twitter[/url] for more news about that when it comes comes out.



Cheers,





-j



–-

Jeffrey Goldberg

Chief Defender Against the Dark Arts @ AgileBits

[url="http://agilebits.com"]http://agilebits.com[/url]

jpgoldberg

Dropbox statement as quoted by http://thenextweb.com/mobile/2012/04/06/security-hole-in-facebook-ios-app-doesnt-require-jailbreak-or-theft-and-dropbox-has-it-too/



[quote]Dropbox’s Android app is not impacted because it stores access tokens in a protected location. We are currently updating our iOS app to do the same. We note that the attack in question requires a malicious actor to have physical access to a user’s device. In a situation like that, a user is susceptible to all sorts of threats, so we strongly advise safeguarding devices.[/quote]



Cheers,



-j

So it looks like they will be submitting a fix soon.

jpgoldberg

A blog post with more information about this is now up:



[url="http://blog.agilebits.com/2012/04/06/oauth-dropbox-and-your-1password-data/"]http://blog.agilebits.com/2012/04/06/oauth-dropbox-and-your-1password-data/[/url]



Cheers,





-j



–-

Jeffrey Goldberg

Chief Defender Against the Dark Arts @ AgileBits

http://agilebits.com

Blu Zebra

I'm a iOS dev, too, and when I had written an app almost 2 years ago that also had to store a similar type of token, it was pretty clear to me that it needs to be stored in a protected place. I chose the Keychain for that.



The app was made a for a major insurance company, and them - of course - being secury-aware, they also hired an external security company for auditing. And they, too, asked about the way our app stored the token, and we agreed that it needs to be encrypted, and the keychain was a good place for that.



Overall, I am really surprised how you (and many others, apart from FB who's well known for not really caring in this regard *smirk*) could have missed this. Even if your programmers aren't all super geniuses, you should still at least be aware of such potential issues and be ready to hire a company that audits your app in this regard, don't you agree?

jpgoldberg

Hi Blu,



Those are all good points. I'm not making excuses. We should have known better. Although we did actually have this fixed and submitted before the recent discoveries, we really should have had this right the first time.



I share your surprise at how many people seemed to have gotten this wrong. I have guesses about what happened. But those are guesses at this point, and spelling them out would sound like making excuses. On the one hand we were being extremely careful about finding the appropriate data protection class for some of the authentication credentials we stored, while at the same time putting the OAuth tokens in the (readable) app's plist.



We have looked at bringing in external security auditors, and we've had some outsiders look at various aspects of our design. There are some pragmatic issues with having a complete review of all of our code. It is an enormous job that can't be done very frequently, and we would like it to include our forthcoming data format, but we need our code to settle down a bit first.



One thing to note is although initial reports were vague, it is becoming clear that the attacker must gain access to an [i]unlocked[/i] device (or else manage to unlock it themselves) in order to gain access to the plist files. Again, I'm not offering that as an excuse, but it does dramatically reduce the impact of this bug.



Cheers,





-j



–-

Jeffrey Goldberg

Chief Defender Against the Dark Arts @ AgileBits

http://agilebits.com

tehnoir

I hang my head in shame. I was wrong in my original response. Sorry :/

jpgoldberg

[quote name='tehnoir' timestamp='1333751330' post='59358']

A device does not need to be unlocked. If you have a pin set on the device and it is locked, an attacker is still able to easily access these plist files with a tool like iExplorer or PhoneView.

[/quote]



Nick, there has been a great deal of confusion about this point, and I hope that I am reducing it instead of adding to that confusion.



The first time you connect an iOS device to iTunes you will need to unlock the device. After that, iTunes will keep an "escrow key" that allows iTunes to automatically unlock the device when you plug it in later. Tools like iExplorer rely on iTunes unlocking the device first. This gives the appearance that these files can be accessed without a passcode.



Please give it a try yourself by connecting a locked device to a new instance of iTunes (say one belonging to a different user.)



Cheers,





-j



–-

Jeffrey Goldberg

Chief Defender Against the Dark Arts @ AgileBits

[url="http://agilebits.com"]http://agilebits.com[/url]

tehnoir

Thank you for taking the time to clarify, Jeff. Where my confusion came from was *thinking* that devices had not been plugged into my computer before. The devices I had done must have been plugged in before, and I also didn't realize that if you plugged in a device before setting the pin, that once you set the pin, it will still have that device "unlocked' via iTunes.

jpgoldberg

[quote name='tehnoir' timestamp='1333752299' post='59360']

Where my confusion came from was *thinking* that devices had not been plugged into my computer before. The devices I had done must have been plugged in before, and I also didn't realize that if you plugged in a device before setting the pin, that once you set the pin, it will still have that device "unlocked' via iTunes.

[/quote]



I'm actually getting confusing results with my testing. iTunes (and thus iExplorer) is letting me see more than I thought it would even with accounts that I don't believe I've had my devices connected to before.



I suspect that the story is even more complicated. And I'll need to find some combination of devices, computers, and accounts to test more thoroughly.

jpgoldberg

Here is what I learned with further testing about the requirement for a passcode.



[color=#000000][font=ProximaNova,]The first time a device is connected to a particular [/font][/color][i]computer[/i][color=#000000][font=ProximaNova,] for iTunes syncing or management a passcode is required. After that point iTunes will automatically unlock that device when it is connected to [/font][/color][i]any user account[/i][color=#000000][font=ProximaNova,] on that same computer. That includes guest accounts.[/font][/color]



[color=#000000]As a consequence an attacker need physical access to your device and to any account on computer that the device has sunc with. ("They sync", "they sanc", "they have sunc") This means a computer in an office or in a household with several members is very likely to enable this kind of attack. Note that this isn't just about OAuth credentials. This allows access to anything in the "After First Unlock" data protection class on the device.[/color]



[color=#000000][font=ProximaNova,]I consider this a design flaw by Apple, and will be reporting it.[/font][/color]



[color=#000000]Cheers,[/color]



[color=#000000]-j[/color]

RichieB

I just noticed 1Password Pro 3.6.5 being offered in the AppStore. Kudos for the security improvements. It is refreshing to see all the detailed info about the inner workings and security mechanisms out in the open (as it should be).



Can you confirm that after upgrading to 3.6.5 an existing database is upgraded to use PBKDF2 and the secure Dropbox OAuth keyChain storage?

jpgoldberg

Great questions, Ritchie!



And the answer to both is that all you need to do is upgrade and run 1Password 3.6.5. The OAuth tokens will be removed from the plist as soon as you launch 1Password 3.6.5, and the 10000 PBKDF2 iterations will be added the first time your 1Password data is unlocked.



If you have a first generation iPhone, you should be able to feel the difference in the unlock time, but otherwise is probably isn't noticeable.



Cheers,



-j

Gareth Wright

Congrats on being the first to update and ditch the plist bug.

By far the most professional response to the whole thing, though Dropbox have also held their hands up and just got on with it.

No suprise Facebook felt the need to try and brush the whole thing under the rug rather than just make a few simple changes.

Gareth Wright

I have to admit I was caught out by the whole passcode thing having never synced my passcoded IPad 3 to my Macbook Pro it still seemed to work. Though it dawned on me a day or so after my initial post I had previously used the IPad to copy over an iBooks draft from iBooks author and had therefore unlocked the iPad whilst connected over USB...My Bad

julezjulian

Is there a reason why the OAuth Token isn't stored in the 1Password Keychain itself?



As far as I know, the iOS Keychain is not really secure (-> jailbreak), so wouldn't it be a good solution to store the OAuth token in the 1Password Keychain?



After unlocking the Keychain the app could sync with Dropbox...



Another Question: If you decide to store my Master Password (in Order to sync automatically with Dropbox), where will this password be stored? In the 1Password Keychain, or in the iOS Keychain?

I didn't enable this option yet bacause if have an iPhone 4 which can be jailbroken at any time - if i loose it, and someone jailbreaks it he could be able to get the Dropbox OAuth token and my master Password if both are stored in the iOS Keychain.



Are my thought correct or am I getting something wrong?



Thanks in Advance!

RichieB

The iOS keyChain on the iPhone 4 is still protected by your iPhone unlock code, even when jailbroken. Because it can only be brute forced on the phone, there is a limit of about 6 tries per second. If you make your unlock code sufficiently long, the 1Password master key with 10000 PBKDF2 iterations will be broken sooner because it can be cracked offline on super fast parallel GPU hardware. I recommend using at least 8 characters for your iPhone unlock code.

khad

Welcome to the forums, julezjulian!



RichieB is correct. You might want to review a few of our blog posts which go into greater detail about iOS passcodes:



[b]The ABCs of XRY: Not so simple passcodes[/b]

http://blog.agilebits.com/2012/03/30/the-abcs-of-xry-not-so-simple-passcodes/



[b]Lost iPhone? Safe passwords![/b]

http://blog.agilebits.com/2011/02/11/lost-iphone-safe-passwords/



Please let me know if you have any further questions. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />



Cheers,