Storage of Master Password on iOS Devices

The user and all related content has been deleted.
«1

Comments

  • khadkhad Social Choreographer

    Team Member
    Welcome to the forums, rapidaux! This is a great question. Please read our recent blog post related to iOS password crackers and let me know if you have any additional questions!

    http://blog.agilebits.com/2012/03/30/the-abcs-of-xry-not-so-simple-passcodes/
  • edited May 2012
    The user and all related content has been deleted.
  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member
    edited May 2012
    Great question, rapidaux!

    If automatic syncing is enabled, your 1Password master password is stored in the iOS keychain. However, it is stored using the most restrictive data protection class possible. To get at things in the keychain stored with this protection class, the attacker would require (1 ) the device passcode, (2) a jailbreak of a particular sort, and (3) physical access to the device (the attack could not be run against an iTunes backup).

    Furthermore, although it shouldn't come to that, we provide an additional layer of obfuscation. That is, it is an obfuscated version that is stored. Of course "security through obscurity" is never a principle defense, but in this case we felt that it was a good thing to add.

    I'm sorry for any confusion in the posts and the documentation. I'll go back and look at that post to see if I could have expressed things better. I didn't properly address the issue of what's in the keychain in the portion that you quoted.

    This is why I do very strongly recommend that people use good passcodes for their devices, particularly if they do (as I do) store credentials used for automatic syncing.

    Cheers,


    -j

    –-
    Jeffrey Goldberg
    Chief Defender Against the Dark Arts @ AgileBits
    http://agilebits.com
  • edited May 2012
    The user and all related content has been deleted.
  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member
    rapidaux wrote:

    The AgileBits website is full of misinformation like this, assurances that no matter what happens passwords stored in 1Password are safe but in this case that is not true!


    Seeing this through your eyes, I fully agree that what I wrote will definitely leave people with an incorrect impression of security. I certainly didn't want to create the false impression. After all, I was trying to persuade people that they should use strong device passcodes. Although technically what I said may have been correct (the attacker does need to get a hold of your master password), its implicature is not correct. I need to fix this. The last thing we want is to install a false sense of security. I want people to behave in more secure manners, not less secure ones.

    In conclusion, permanently storing the 1Password master password is a bad practice and I hope my highlighting of the issue will prompt a rethink. At the very least AgileBits need to inform their customers of the security implications of enabling automatic Dropbox syncing.

    I can't promise anything at this point, but I wonder if we can actually detect whether a device has a passcode set before storing syncing credentials in the iOS keychain. That is, me might be able to require that people have at least some sort of device passcode before storing these things. Again, no promises. I'm just musing about this.

    I can promise to improve our documentation (though give me some time on that).

    The third thing would be to put a big fat explanation of the security implications on the screen where people do save their syncing credentials. I'm not sure whether we want to do that, and again make no promises.

    One thing that has made me worry a bit more about this is the behavior of iTunes. Once a device has been connected to iTunes and unlocked once on a computer the device can be unlocked without a passcode by any other users (including a Guest user) on the same machine. Allowing this way around a passcode means that we do have to exercise greater caution about what gets put in the iOS keychain. I really hope Apple will change this, but we have to look at the threats as they are, not as as we wish they were.

    Please keep an eye for anything more like this that we need to correct or rethink. Although I can't say I'm happy to have to go back and correct all of that documentation, I would much prefer that these things get corrected sooner than later. And in particular, I want to help people make good security choices.

    Cheers,


    -j

    –-
    Jeffrey Goldberg
    Chief Defender Against the Dark Arts @ AgileBits
    http://agilebits.com
  • The user and all related content has been deleted.
  • The user and all related content has been deleted.
  • khadkhad Social Choreographer

    Team Member
    I'll leave this in Jeff's capable hands, but I wanted to make sure you knew that we saw your post. He just wrapped up his day, but he wanted me to tell you that he will reply as soon as possible. :)
  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member
    edited May 2012
    Those are outstanding suggestions!

    Every single one of them is something that we have been actively considering. We never (well, hardly ever) talk about features until they are released. But I can say that we have certainly been thinking about things along those lines.

    We have publicly said that the 4-digit unlock code cannot continue in its current form. Yes, there are ways to use it securely, but it turns out that there are many ways to use insecurely, and confusion about it has led many people to use it poorly. There is discussion of that over in this support thread.

    The question of requiring the same 1 Password on different platforms is a bit more tricky. From a development point of view, that would be the easiest. From a security point of view, considering the following two assumptions.
    1. It is more likely for 1Password data to be stolen from the sync service or from desktop systems then from iOS devices.
    2. People will use weaker master passwords if they have to use them on iOS.


    I think that if a device is passcode locked, the vast majority of thieve will just wipe a stolen device. Yes I know that people can get around the iOS protections, but those protections still provide a practical barrier that isn't there on desktop systems.

    Although, I consider the likelihood of theft from a syncing service to be much much lower than someone stealing a desktop computer (or stealing 1Password data off of a desktop computer), a single (low probability) breach could lead to the collection of data from an enormous number of users at one time. So even though it is a low probability event, it is one that we have worry about.

    Because of this, I want people to have the strongest possible master passwords for the data that is stored on their desktops and in the cloud. I don't want to limit that master password by what people will realistically use on phones. As people move to more powerful devices we can increase the number of PBKDF2 iterations, but the gains from that offer diminish returns. (For example, having 1000 iterations as in the first versions of the .agilekeychain format added effectively 10 bits of strength to the Master Password. Increasing that from 1000 to 10000 only adds an additional 3 bits.

    This is an illustration of a point that I've tried to make in the past. Often trade-offs are not, as commonly believed, to be between security and convenience; but they are trade-offs between security in one respect and security in another.

    I am not saying "no" to your suggestion, but I'm letting you know that if we don't go down that road, there are reasons for it. And I certainly want to let you know that what you have suggested is under very active consideration.

    Again, thanks for this discussion and your extremely insightful observations.

    Cheers,

    -j
  • edited May 2012
    The user and all related content has been deleted.
  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member
    rapidaux wrote:

    I think your looking at this the wrong way. Digital information is vulnerable no matter where it's stored. It's impossible to say an iOS device is safer than a sync service because only chance is stopping ones data from falling into the wrong hands. In other words, you can't trust anyone.


    I think we may have hit a philosophical difference here. Of course I can't be certain that I think that one threat is more likely then another, but none-the-less we have to make those sorts of judgements all of the time even without any certainty. Just because we can't rule out certain threats doesn't mean that we have to treat them all as equally probable. For example, there is the threat that someone is using Van Eck phreaking to capture the contents of your computer screen. But we judge that the chances of that are so remote that we don't really worry about it. Instead we defend against more likely threats.

    Now you may very well think that I'm wrong it my judgement of where the bigger threats are. That's a different matter. But I hope we agree that making judgements about the likelihood of different threats, even with limited information, is something that we have to do.


    To paraphrase, people don't want to type a strong master password on iOS devices because it's inconvenient, so allow them to use a weak master password because some security is better than no security. The danger with this approach is that people are lulled into thinking that using weak passwords is acceptable, which in turn encourages them to use weak passwords for everything. As you pointed out this is what happened with the 4-digit unlock code.


    That is a fair paraphrase. And you point out a very real danger. And it exemplifies the point that our trade-offs are often between security in one area versus security in another. Of course I don't want to encourage weak master passwords anywhere. But I want people to use the strongest master passwords they can manage without it discouraging use of the system. It's just that "strongest they can manage" differs substantially from an iPhone to a desktop.

    Let's look at another example of exactly this sort of trade-off. We let people pick their own master passwords, including how annoying they are to enter. People differ in their typing skills and in what they can reliably remember. We also let people choose the time-out for autolocking behavior. Imagine Alice and Bob with similar preferences about typing in master passwords. That is they are equally poor at typing and so on. Alice may set a master password that is stronger, but at the same time she sets the auto locking timeout to be longer, so that she has to enter her master password less frequently. Bob goes the other route. He uses a weaker master password but sets a shorter time out, so he has to type it more.

    It is impossible to say whether Alice or Bob is more secure. It depends greatly on their situations and the relative threats.

    Whilst I still believe (and I practice what I preach) that the right approach is to use a single strong master password across all platforms,


    Noted. And I do understand your reasons for this. And it is something that is very much under consideration.

    here is a potential solution: [...]


    I'm going to skip your discussion of the specific proposal. I think there are ways to improve upon the scheme that outlined, but don't want to get bogged down in the details of too many hypothetical designs.


    You should also consider educating users how to create a strong master password that is also easy to type within the 1Password application. iPad apps have become really good at this, take them though the process step by step with cute graphics and animation.

    I'm actually not a big fan of the Haystack approach, and I've advocated a different approach in "Toward Better Master Passwords" and in a follow-up to that in a geek/xkcd edition.

    Good security is inconvenient but can be made easy to use, 1Password for example <img class=" />

    We fully agree. That is what I was trying to say, though I may have done a poor job of it.

    Thanks, just trying to help improve my favourite password manager!

    Please continue. I love this conversation and conversations like it!

    -j
  • The user and all related content has been deleted.
  • sddawsonsddawson Member
    Coming late to this, but I find this post extremely interesting, and not a little worrying. I don't think many people are aware of what's being stored in the keychain when automatic Dropbox syncing is enabled (although if you think about it, all those passwords have to be stored somewhere). But it does boil down to what rapidaux says - the security of your 1P passwords on an iPhone is down to the security of the phone's passcode. If someone gets around your passcode (or lack of one), all bets are off. One would have to assume that a thief with sufficient interest and knowledge can get hold of all your 1P passwords. Going one step further, it then seems as if having a strong master password on the iPhone is almost a waste of time. Might as well make it easy and have a single letter as the password! Of course, this is a little extreme, but I'm just illustrating the point.

    I see the iPhone Dropbox syncing methodology as 1P's single biggest failure from a security perspective, and hope that it can be improved some time soon. But I really appreciate the frank and open conversations that everyone at 1P engage in.
  • sddawsonsddawson Member
    To add to this...

    [font=helvetica, arial, sans-serif]I noticed something while setting up Dropbox syncing on an iPhone. Just to see what would happen, I didn't ask 1P to remember my iPhone master password when setting up sync. The first sync went through. Now, if I go into Sync prefs again, it says, as expected, that automatic sync is disabled. Pressing Sync Now prompts for my phone's master password. So far, so good. But if I don't do that and instead tap on my dropbox account name, I'm taken to a screen that has my 1P master password for the file on Dropbox (covered by dots). If I tap on that and tap on Go without changing anything, a sync starts without ever having typed in my phone's master password. This would indicate to me that the phone's password has been saved in the keychain without me asking it to be. And the master password for the dropbox data file seems to always be stored. Is this right? I thought that the various passwords were only saved in the keychain if automatic Dropbox syncing were enabled.[/font]
  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member
    I'm not sure that I completely understand the argument.

    We are using PBKDF2 with the master password on iOS, so it is not as if these are easier to crack than a device passcode. It is true that "low security" items have no substantial protection from 1Password on iOS, but things that are actually protected by the master password are, indeed, protected.

    So a decent Master Password for your data on iOS will be enough to protect you against all but the most intensive attacks.

    I do accept that I should do more to encourage people to use stronger master passwords on iOS. I use three diceware words. This has the advantage of being reasonable to type on an iOS keyboard. I will take all of this into account and try to do a proper write up of iOS master password suggestions. I've focused a lot of attention on the desktop version, as it is the version that also lives in the cloud, but a stronger focus on iOS is due.

    Cheers,

    -j
  • sddawsonsddawson Member
    Hi Jeff. I'm only re-iterating Rapidaux's arguments here, which you do seem to have broadly agreed with. It's not a question of cracking the master password at all. It's a question of the phone's master password, the dropbox master password and the password for Dropbox itself being stored in the keychain. If someone manages to get around the phone's passcode (or if there is no passcode), one has to assume that the 1P data file is accessible, and then also the master passwords from the keychain. I was taking this to the extreme and saying that it's then almost a waste of time having a strong phone master password at all. The security of 1P, as Rapidaux has said, is ultimately down to the security of the phone's passcode, a fact that I'd bet not many are aware of (although I know you've posted about the need for good passcodes on the blog - but I wonder what percentage of your customers read the blog posts).

    I then, in my second post, asked a question about why master passwords seem to be remembered when I didn't ask for them to be.

    Hope this has made it a bit clearer.
  • edited August 2012
    The user and all related content has been deleted.
  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member
    Thank you all for this.

    1Password certainly should not be storing the device master password if automatic Dropbox sync is turned off. If it is retaining the device master password as it seems to in your case then we have a bug.

    Again, I want to do some more thorough testing to make sure that I understand what is going on.

    Cheers,


    -j

    –-
    Jeffrey Goldberg
    Chief Defender Against the Dark Arts @ AgileBits
    http://agilebits.com
  • sddawsonsddawson Member
    Thanks, Jeff. I believe it also stores the master password for the Dropbox keychain in these circumstances, which doesn't seem right either.
  • h00liganh00ligan Junior Member
    This is a portion of the issue I have, thanks for putting it so well.
  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member
    I think I have figured out what is going on with the iOS Master Password. It took some more testing and judicious use of airplane mode, but remember that there are two stages to the sync. Transferring the data between your phone and Dropbox, and performing the translation from the desktop/Dropbox format to the iOS format.

    For the transfer all 1Password needs is the ability to log into your Dropbox account. It's with the translation that the master passwords are needed. I will need to check with the developers on this, but I believe that what you are seeing with the Dropbox sync is just the transfer. That is Dropbox syncing is greedy. It will grab files when it can even if it can't "translate" them.

    Changes in the other direction work similarly. 1Password will "prepare" an item for transfer when it can (that is when it has both master passwords) and then send the change to Dropbox when it has that opportunity.

    This gets tricky to test, but 1Password does has a "make hay while the sun shines" approach to syncing. It will do what it can when it can, so that when there is a connect that it can sync over, everything will be ready.

    Cheers,

    -j
  • edited August 2012
    The problem is that when a user performs this magic sync, it still has to input the iPhone master password to view an entry to see the newly synced password.
    For a user, there is no way to tell if was it already there encrypted with the iPhone master password (which should not be possible), or if 1Password quickly uses the iPhone master password to get the Desktop master password decrypted and use that to decrypt the previously synced data files.

    I think I may have a way to test between the two scenarios: but it relies on one major assumption and I do not know if that's correct:

    Assumption: Any "low security (4-digit pin-protected)" password created on the desktop client, is stored in the desktop client keychain encrypted only with the desktop master password and not recoverable without it. Only when decrypted with the master password and synced to an iPhone it is stored on the iPhone encrypted with the 4-digit pin.

    After all, how would the Desktop client know what pin to use encrypt it with? There could even be multiple different pins for multiple iPhones.

    If that's true, then the following test I performed proves that either the iPhone master password, the desktop master password, or both, are indeed stored in the iOS keychain when they should not be, creating a huge security loophole.

    On the iPhone:
    1. Create a new keychain on 1Password for iPhone.
    2. Set a new 4-digit pin and a new iPhone master password.
    3. Sync it with an existing Dropbox keychain, do not allow storage of iPhone master password.
    4. Make sure the iPhone master password auto-lock is set to "lock when inactive".
    5. Lock the iPhone 1Password keychain.
    6. Quit the app.

    On the desktop:
    7. Create a new login entry set to "low security".
    8. Let it sync to Dropbox.

    On the iPhone:
    9. Open the app.
    10. Enter the 4-digit pin.
    11. In settings, go to Dropbox Sync, tap the account field, tap the password field, hit Go.
    12. Wait for Dropbox sync to finish.
    13. Find your new login entry
    14. Copy and paste the password somewhere to confirm it transferred correctly.

    This works for me, so if my assumption is true there can be only one conclusion:
    1Password on iPhone has access to my desktop master password when only supplied with my 4-digit pin.

    If I'm wrong, please explain why.
  • sddawsonsddawson Member
    Jeff,

    I really don't think what you are saying about the "make hay while the sun shines" approach is really what's going on here. Please just follow Rapidaux's step-by-step description to the letter. It has nothing to do with airplane mode or anything like that. You will find that you can perform a sync even though you specifically told 1P to NOT remember your device password. You only need to enter the 4 digit 1P passcode.

    In the long run, I'm looking for a way to have 1P not remember either master password. I'm ok with it remembering the Dropbox password. I'd like it to then automatically ask me whether I'd like to perform a sync, and give me the opportunity to enter the required passwords. Taking this further, I'd personally be happy with only one master password across all devices, which would make things simpler, although I know your objections to this approach. This would work well on the iPad too, where the Dropbox data file master password is always held in the keychain too. With only one master password, 1P wouldn't have to do this. It prompts for the one and only master password at startup, and that's it.
  • h00liganh00ligan Junior Member
    So assuming this is true and the master password is being stored in the ios keychain. AFAIK this is the safest place to store it - providing simple password is disabled and running ios 5 on iphone 4s or ipad 2 or >

    This would also assume that apple icloud backup was not enabled, and encrypted backup was set with a complex password.

    Wasn't the lack of utilization of the hardware based aes one of the largest dings against 1p?

    Obviously this would be a big issue for those not using any pin protection or weak pin protection... which goes back to the point about auto detection right?


    So I guess my question is - is this a concern for clients with weak security outside of 1p - or in general.

    I've found the thread very interesting and would like to thank everyone for their time involved.
  • sddawsonsddawson Member
    h00ligan,

    I see this as all a matter of choice. Yes, the keychain is the safest place to store the passwords. At the end of the day, it is protected by your iPhone's passcode. So the safety of your master passwords (and everything in the keychain) is down to the strength of your iPhone passcode. And this kind of even negates the need to have a strong device master password at all (although that's taking the argument to an extreme). And how many 1P users know this? I'd guess maybe 1% - those who frequent this forum.

    There are those who don't want this exposure - they'd like to sync using Dropbox for the convenience (too hard to remember to sync using wifi). But only do so by entering the master password(s) at time of sync. Seems like a simple request, but I know there are many complications.
  • jhollingtonjhollington Junior Member
    One of the features that I absolutely despised about the Android version of 1Password (in its current form) was the requirement to enter the actual master password almost every time I opened the app. Had I been primarily an Android user, rather than merely testing the platform, this alone would have had me drop 1Password in favour of another solution.

    I can see a valid point in an option to require the master password at every turn, but I would argue that this certainly shouldn't be the default behaviour, particularly for something that carries a relatively low risk of exposure. That said, I had also assumed that the master password stored on the device was further encrypted using the iPhone PIN code, which should provide at least another layer of protection. I'm not clear on that at this point from reading the above, but if this is not the case, I think it definitely should be as there's no reason I can think of why the master password would need to be stored "in the clear" outside of the 1Password app authentication, since background sync (when the app is closed) isn't really an option anyway.

    Personally, I'm not too worried about this considering that the entire keychain takes advantage of iOS Data Protection, eliminating the possibility of gaining access to that data store with anything except my actual device passcode. Further, the remote wipe option and the fact that the vast majority of thieves would likely not even bother trying to break into it but rather simply erase it and use/sell it as a "new" device really mitigates the risk in my opinion. Plus, I know one should never say never, but my iPhone is always on my person -- my computer has a higher chance of being stolen by virtue of being at my house when I'm not :)

    jpgoldberg wrote:
    One thing that has made me worry a bit more about this is the behavior of iTunes. Once a device has been connected to iTunes and unlocked once on a computer the device can be unlocked without a passcode by any other users (including a Guest user) on the same machine. Allowing this way around a passcode means that we do have to exercise greater caution about what gets put in the iOS keychain. I really hope Apple will change this, but we have to look at the threats as they are, not as as we wish they were.

    Actually, while this was the behaviour of iTunes with passcode locks on traditional iPods and I think the iPhone also with very early iOS versions (pre 2.x), it has actually not been the case in some time. iTunes cannot actually bypass passcode protection, even on the original computer that the iPhone was setup on -- all it does is reset a disabled password counter, allowing the user to try again without needing to wait for the requisite timer to expire. This could possibly be useful in attempting to brute force the password by allowing more attempts, but it doesn't otherwise circumvent.
  • sddawsonsddawson Member
    All valid points, jhollington, but to me, again, this is about choice. What you are comfortable with, others may not be. But I know it's always hard to cater to everyone's wishes. We're yet to hear anything definitive from Agilebits about the problem with the phone's master password being stored when you didn't ask it to be. The reason I came across this was that I was trying to find a way to sync "manually", by entering the passwords, because I'd be happy with this. Even happier if there were only one master password to enter. I don't know what the ultimate answer is, but I guess the more opinions are voiced, the better Agilebits can gauge requirements.
  • jhollingtonjhollington Junior Member
    sddawson wrote:
    All valid points, jhollington, but to me, again, this is about choice.

    I agree completely -- as I said I can definitely see a valid point for having this as an option, but just adding my own personal opinions to the mix in terms of why I feel it's not necessary for me and why I don't think it should be the default approach, as long as the "real" master password is otherwise reasonably protected (e.g. stored in the keychain with iOS Data Protection along with encryption using the iOS 1Password app's passcode).

    If the master password is required for the iOS app as a default choice, I do think there's a high risk that most users will simply revert to choosing a less secure master password in the name of convenience. This was the thing about the Android app that annoyed me so much -- I take security very seriously, so my 1Password master password is a forty-character, completely random string. As a fast touch-typist, I can punch that into the desktop 1Password app in about five seconds, but it would probably take a couple of minutes to peck it out on the iPhone keyboard :) In my case, I would ditch the software entirely before compromising the security of my password store, but most other people I know would simply reduce the complexity of their actual master password to make it easier to type, thus reducing the security of their entire password store -- not only on their iPhone but also on their Mac/PC and in their Dropbox account.

    Personally, with an immediate-lock passcode on my iPhone and remote wipe enabled both via iCloud and Exchange ActiveSync, I consider my iPhone to be the most secure device that I keep my 1Password data on, and hence the lower-security "master password" on the iPhone is a non-issue for me since it's living on a device that's always in my possession, never used by anybody else, incapable of being hacked/accessed remotely and already protected by another passcode. By comparison, my iMac can be stolen when I'm not there or compromised by somebody else who may be using it and my Dropbox account can be hacked remotely or compromised by malware on a computer that I happen to log into it on (although admittedly the new two-factor authentication on Dropbox is a nice step in the right direction).

    We're yet to hear anything definitive from Agilebits about the problem with the phone's master password being stored when you didn't ask it to be.

    I definitely agree that this is a problem -- if the master password is being stored when you don't want it to be, that's something that needs to be fixed, although I think the better solution is to re-write the 1Password app to include a "manual" sync option where not only is the password not stored, but the user is able to trigger a sync and supply the password on-demand.
  • sddawsonsddawson Member
    I think we are in almost complete agreement. Jeff is, like you, concerned that always requiring the master password to be entered on an iPhone will ultimately result on weaker passwords that are easier to enter. Personally, I use Diceware-generated passwords, and I find these pretty easy to enter even on an iPhone. And I'm not using to 1P on the iPhone that often anyway.

    [font=helvetica, arial, sans-serif]Personally, with an immediate-lock passcode on my iPhone and remote wipe enabled both via iCloud and Exchange ActiveSync, I consider my iPhone to be the most secure device that I keep my 1Password data on[/font]


    It could be argued, though, that because the iPhone is always with you it is more likely to be lost or stolen (probably especially lost). Too easy to leave it somewhere, have it drop between the cushions of a chair etc. I do agree that even then it would be very hard to jailbreak the phone and get at the keychain, and then to get at the passwords. But if that's a hole that can be plugged, I'd like it plugged!

    To reiterate something, we must be aware that if we want to minimise this risk with the current design, we must have strong device passcodes. No passcodes or 4-digit passcodes don't cut it. That makes it too easy to get at the keychain. Now, 1P aside, I might actually be happy to have an easy-to-enter passcode or none at all, if the only secure data on my iPhone is the 1P data. But at the moment I must put up with the not inconsiderable inconvenience of having to enter a strong passcode every single time I use my iPhone. I'd rather have the inconvenience of entering a strong 1P password on the few occasions I use 1P.
  • The user and all related content has been deleted.
This discussion has been closed.