Cross-App Resource Access (XARA)

idontno

sindarina you said "1P never stores your master password on a server anywhere ..". Other posts have said the same. Could I suggest you should delete "on a server" - the stronger statement is "1P never stores your master password ANYWHERE .."

Untrusting people like me read statements that have limitations like the above and wonder about things the statement doesn't exclude.

RichardPayne

the stronger statement is "1P never stores your master password ANYWHERE .."

Unfortunately the stronger statement isn't entirely true. 1Password on iOS (and likely Android when the new Touch API is released) stores your master password in the iOS keychain if you enable the TouchId unlock. Basically, your data is protected by your master password and your master password is then protected by your finger print.

AGAlumB

@RichardPayne: I think we might get stuck on semantics again, but I feel like I should add that in this case the iOS Keychain is storing it. Sorry, but I just had couldn't resist! :lol:

Basically, your data is protected by your master password and your master password is then protected by your finger print.

Perfect.

AGAlumB

1Password should have the ability to create One Time Passwords, Two-Factor- Authentication or support Hardware Tokens like Yubikey or similar. Or the ability to insert a device (e.g. Smartphone) to get an additional code to approve you are the owner.

@elias: The question is what would you be authenticating with? In the case of LastPass, your data is stored on their servers. Without this component, you're completely in control of your data; but the flipped is that there's nothing to authenticate you. That's where the encryption comes in. :)

idontno

Duh! sorry about that - my focus was the only two platforms I am using 1P on - Windows & OS X. My assumption there was that you didn't store it locally because you shouldn't have to. Please tell me this is true on Windows & OS X ?

RichardPayne

If I can be pedantic @sindarina, technically LastPass and 1Password are no different by your definition. They never store your master password outside of its non-reversible encrypted form either.

RichardPayne

To continue with the pedantry, I didn't claim that they were objectively the same. I claimed that they were the same by your previously stated definition, which they are. :tongue:

Their recovery system does not actually retrieve your master password. First it gives your hint. Granted, this is a generally a terrible idea because there is a significant number of people who simply stick their password (or a modified form of it) in the hint!
If that doesn't help then you can activate a OTP stored in the browser plugin. They don't state it, but I can only assume that this means that they are keeping your master password stored locally, encrypted with the OTP. This is equivalent to 1Password's Touch Id feature.

Both the hint and the OTP system are optional. If you want an all-in, non-recoverable account then you can.

AGAlumB

@RichardPayne, @sindarina: Yes! I think this discussion is a good place to be pedantic. Security matters. :) :+1:

And in that spirit, it's important to note that the 1Password vault itself does not contain the Master Password, so it cannot sync with your data; rather, encryptionkeys.js is encrypted using PBKDF2 from your Master Password; so this is what syncs with your data, which in turn allows you to unlock (and decrypt) the vault when you enter your Master Password.

I know you've pointed this out previously when I've glossed over some of this in less-technical discussions, RichardPayne. ;)

AGAlumB

I think that LastPass leans toward being able to help users get their data back, and many people appreciate that (as evinced by their popularity).

1Password, on the other hand, isn't meant to do that at all; rather, it's built on the notion that if we don't have it (your data, etc.), no one can do an endrun around you and go through AgileBits to get it.

But while we won't be able to help you get your 1Password data back, we try to have our customers' backs instead.

idontno

Me again.
I've read this thread and re-read elements of the security by design article. I need to be sure about this, so sorry if I'm labouring it but I need to know. I use drop box to replicate my 1P vault between Win & OS X.
My understanding:

• I enter my master password and it goes thru the PBKDF2 process which results in a well encrypted key based on my master password.
• The key that is the output of PBKDF2 is used to unlock individual entries on my keychain - so 1PW master password PBKDF2 output decrypts my bank keychain entry - which would reveal my userid/password for the bank - yes ?

Based on Sindarina's post
"That encrypted form might be stored on a server somewhere as part of the 1P keychain, if you choose to use one of the supported forms of cloud synchronisation, such as iCloud or Dropbox_"

Is my encrypted master password available to someone who hacks my dropbox account ? could they then apply that encrypted key to decrypt keychain entries held in dropbox?. It is not clear to me what the consequence of a dropbox hack could mean to me.

I thought my banking credentials were secure - but Sindarina's response has given me cause for concern.

idontno

Regarding my last post - maybe I should have been clearer -
a) someone steals my PC and therefore has the local copy of my 1P vault
b) Someone hacks dropbox and has my replicated 1P data
Would it be easier to get at credentials if b) happened versus a).

My position - if b) presents more risk I will use a USB stick to sync vaults rather than dropbox, but you guys at Agile bits need to be upfront about any risk introduced by replication - given I am prompted to use dropbox by 1P.

RichardPayne

@sindarina I have never disagreed with any of that.

RichardPayne

My understanding:

• I enter my master password and it goes thru the PBKDF2 process which results in a well encrypted key based on my master password.
  *The key that is the output of PBKDF2 is used to unlock individual entries on my keychain - so 1PW master password PBKDF2 output decrypts my bank keychain entry - which would reveal my userid/password for the bank - yes ?

Based on Sindarina's post
"That encrypted form might be stored on a server somewhere as part of the 1P keychain, if you choose to use one of the supported forms of cloud synchronisation, such as iCloud or Dropbox_"

@idontno
The basic principles are:

1) You enter your master password
2) Your MP is run through PBKDF2 to produce a the derived key.
3) The derived key is then used decrypt another key called the master key.
4) The master key is used to decrypt your data (it's actually a little complex than this but the principle is the same).

So you master password is never stored in the vault. It exists in memory briefly, for the time necessary to decrypt the master key.
The master key is stored in the vault as an encrypted data block. The master key exists in memory for the entire period that the app is unlocked. Locking the vault clears the master key from memory.

The encrypted master password can not be used to decrypt the data blocks. You must decrypt it first and for this you need the key derived from the master password.

Regarding my last post - maybe I should have been clearer -
a) someone steals my PC and therefore has the local copy of my 1P vault
b) Someone hacks dropbox and has my replicated 1P data
Would it be easier to get at credentials if b) happened versus a).

No. It would be identical. The only additional local risks relate to having a compromised OS. If someone can install a keylogger then they can obtain your master password. If someone remotely gain admin rights on your OS then they can potentially scan memory looking for the master key (1Password takes various steps to make this difficult).

If someone gains your master password or your vault's master key then it is game over. It is highly unlikely that they could obtain these from the vault stored in Dropbox (or on your PC's hard drive). They'd effectively have to crack the password and, assuming that it is reasonably strong, that would be prohibitively time expensive wise.

Basically, use a good strong master password, keep your OS and malware scanners up to date and don't do stupid things like open email attachments that look dodgy or entering confidentially information into insecure websites and you'll be fine. :chuffed:

There is one additional risk to be aware of when using cloud services that does not exist otherwise, but it only applies if you use 1PasswordAnywhere. This is a JavaScript based web app that lives in your vault and gives you readonly access. The code is necessarily unencrypted (else it would not run). If someone hacks your Dropbox account then they could potentially modify the 1Password Anywhere code to report your master password back to the hacker after you enter it. This vulnerability does NOT affect the normal 1Password applications so if you don't use 1PasswordAnywhere then you don't have to worry about it. If you do then I'll explain how I get around the problem.

idontno

Sindarina thanks for your reply. Got it.
Richard I appreciate the comprehensive explanation. Thanks for taking the time. It made things clear to me that I hadn't picked up from reading on the Agile bits site.

Thanks for the effort folks - much appreciated - paranoid times we live in :)

Megan

Hi @idontno,

I'm so glad to see that Richard Payne and Sindarina were able to answer your questions here! And I would argue that a certain amount of 'paranoia' (or at the very least suspicion) is healthy and necessary in these times that we live in. It's great that you kept asking questions and picked away at the details until you had a satisfying answer. :)

I can't say it any better than they already have, but if you have any other questions or concerns, we're happy to help!

gabrielwayte

Attacks. The security risks of intercepting the IPC communication through these vulnerable channels are realistic and serious. As an example, here we just elaborate our end-to-end attacks on three popular apps. We analyzed the 1Pass- word app for OS X, which is one of the most popular password management apps and ranked 3rd by the MAC App Store [1]. The app comes with a browser extension for each major browser that collects the passwords from the user’s web account and passes them to the app through a WebSocket connection. In our research, our sandboxed app created a local WebSocket server that took over the port 6263, before the 1Password app did, and was successfully connected to the password extension and downloaded the password whenever the user logged into her web account. We reported our findings to the 1Password security team, which acknowledged the gravity of this problem.

What results ??

---

1Password Version: 5.0.1
Extension Version: 5.0.1
OS Version: Mac OS X 10.10.3
Sync Type: -

Stephen_C

@gabrielwayte I have moved your post from the 1P for Mac forum to the Lounge and merged it into a very lengthy existing thread on the same subject—where I think you will find all the information you could possibly need. :)

Stephen

AGAlumB

@gabrielwayte: Feel free to catch up, as there's been a great deal of discussion in the rest of the thread, but here are some highlights that you may find helpful. Be sure, at the very least, to read the following blog post on the subject, as our own Chief Defender Against the Dark Arts gives a comprehensive overview of what this means for 1Password users:

1Password inter-process communication: a discussion

And I'll also quote myself here from an earlier post:

TL;DR:

Any app can be impersonated by malware on OS X, not just 1Password. However, since 1Password encrypts your data, malware cannot access it merely through impersonation (as it can with app data that is not encrypted); it also needs to spy on you to steal data as you access it (by communicating with the browser extension as "1Password mini"). So there are a number of layers to this which are needed to accomplish this exploit.

*It's important to note the distinction between the Keychain which is part of OS X and the Agile Keychain format which 1Password uses.

What you can do:

Only install apps from trusted developers. If you don't install and run malicious code on your system, you're safe from these exploits.

I hope this helps. Be sure to let us know if you have any followup questions! :)

AGAlumB

Is my encrypted master password available to someone who hacks my dropbox account ? could they then apply that encrypted key to decrypt keychain entries held in dropbox?. It is not clear to me what the consequence of a dropbox hack could mean to me.
I thought my banking credentials were secure - but Sindarina's response has given me cause for concern.

@idontno: Just to reiterate RichardPayne's excellent response, your Master Password is not stored in your vault at any time, so it won't be stored in Dropbox if you sync either, for example. :)

a) someone steals my PC and therefore has the local copy of my 1P vault
b) Someone hacks dropbox and has my replicated 1P data
Would it be easier to get at credentials if b) happened versus a).

No. It would be identical. The only additional local risks relate to having a compromised OS. If someone can install a keylogger then they can obtain your master password. If someone remotely gain admin rights on your OS then they can potentially scan memory looking for the master key (1Password takes various steps to make this difficult).

I also wanted to add to this that "If someone can install a keylogger then they can obtain your master password as you use your computer" (emphasis mine). I think it's important to note that in most cases an attacker will use us as the attack vector to get to our most sensitive information. This is the case with XARA attacks as they relate to 1Password, as without our help they can't get it.

idontno

Hi Brenty. Thanks for responding. In the confusion of posts about this topic my question got posted twice. It was answered on the previous page in this thread.

AGAlumB

Ah, understood. I just wanted to make sure your question was not overlooked. Cheers! :)

V_K

Has 10.10.4 address any of the XARA vulnerabilities, particularly the websocket one? I think not but I'd like to hear from Agilebits.
Thanks.

AGAlumB

@V_K: Great question! As always, you can find more details about the latest updates on Apple's site:

About the security content of OS X Yosemite v10.10.4 and Security Update 2015-005

The short answer is "no". Apple can't "fix" websockets, as it is an open standard. Apple may, however, have to develop its own technologies to allow secure inter-app authentication and communication on their platforms in general, which would obviate the need for websockets for many developers (and possibly for AgileBits with 1Password). But this will likely require deeper changes to the OS and its core API (in addition to new ones).

Also, the issues outlined in the XARA research are not primarily "bugs" or security holes; rather, the problem is that OS X (neé NextStep), like Windows, was simply not designed with an adversarial mindset. Apple, Microsoft, and any platform owner's first priority is getting things to work, both for their own software and services, and also for the ecosystem of 3rd party developers they want to make their platform attractive to users. Security was very much an afterthought.

And even now, with security perhaps a close second (after getting things to work), most of the problems we see nowadays are not so much a result of sloppy programming or poor design choices, but that software is incredibly complex, and often code which is needed to get work done on the system can also be repurposed for unintended, nefarious uses as well.

So while 10.10.4 is a huge update security-wise, the current wisdom remains: do not run code from unknown sources on your system. While there are things that Apple (and others) can and will do to mitigate some threats going forward, we may not live to see the day where it is safe to run just anything and everything. Legitimate, benign software will always need access to resources in order to be useful, and malicious software will likely always have the ability to do the same.

V_K

@brenty Thank you very much for your response! I read the original XARA paper and I did realize that to deal with XARA effectively changes of the kind you mention would be required. so I didn't really expect anything in that regard in a point update but I wanted to check just in case anyway.
Speaking of bugs, one small part of XARA does seem like an easily fixable bug to me. it's related to the keychain vulnerability rather than the websocket one so it's not really relevant to 1password but perhaps you know if that at least has been addressed? I mean the fact that a sandboxed app can delete a keychain item created by another app. it seems to me that this should be trivial to handle by enforcing appropriate ACLs on deletion and is something that can be done in a point update. this wouldn't kill the XARA keychain exploit completely but would at least mitigate it.
BTW, you mentioned that Apple would need to develop something to allow for secure inter process communication. do I understand it correctly that such things actually already exist in OSX but they just aren't available to browser extensions?

AGAlumB

Thank you very much for your response! I read the original XARA paper and I did realize that to deal with XARA effectively changes of the kind you mention would be required. so I didn't really expect anything in that regard in a point update but I wanted to check just in case anyway.

@V_K: You're welcome! :)

Speaking of bugs, one small part of XARA does seem like an easily fixable bug to me. it's related to the keychain vulnerability rather than the websocket one so it's not really relevant to 1password but perhaps you know if that at least has been addressed?

Good thinking! This stuck out to me earlier, since this sounds eerily similar to some things in the XARA paper:

Security
Available for: OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5, OS X Yosemite v10.10 to v10.10.3
Impact: Tampered applications may not be prevented from launching
Description: Apps using custom resource rules may have been susceptible to tampering that would not have invalidated the signature. This issue was addressed with improved resource validation.
CVE-ID
CVE-2015-3714 : Joshua Pitts of Leviathan Security Group

Security
Available for: OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5, OS X Yosemite v10.10 to v10.10.3
Impact: A malicious application may be able to bypass code signing checks
Description: An issue existed where code signing did not verify libraries loaded outside the application bundle. This issue was addressed with improved bundle verification.
CVE-ID
CVE-2015-3715 : Patrick Wardle of Synack

But didn't mention it previously because it isn't entirely clear that these address XARA specifically. There just isn't enough detail. Additionally, one would expect a reference to the XARA research team. You may be right to some extent, but any time basic frameworks change it can have an undesirable effect on existing legitimate apps as well.

do I understand it correctly that such things actually already exist in OSX but they just aren't available to browser extensions?

To some extent, but it depends entirely on the app and what it's trying to do. There are secure methods, but these just don't have a lot of flexibility. The main obstacle to designated inter-app communication it that traditionally all apps can just access anything the user can. Apple has slowly been taking steps to lock this down more and more each year because taking a big leap would just break things. They wisely started this process years ago when it seemed completely unnecessary, but these days I think we can all appreciate the need for tighter security, so even when it becomes a bit onerous, both developers and users are more and more willing to accept that this is a necessity.