Concerns about web application security
Hello,
I love 1Password and I use it every day. Until now, I've been syncing over Dropbox, but I would prefer to leave Dropbox out of the equation. (I've never really trusted Dropbox as a company anyway, I'd prefer not to have to allow them to install a kernel module, and the recent discovery that they are granting themselves accessibility permissions on macOS without properly asking first has pushed me to look seriously for alternatives.) I'd be happy with iCloud except that I have a Windows machine in the mix.
Initially, it looked like syncing through 1Password.com was exactly what I wanted. However, after some investigation, it seems that some security I relied on when syncing with Dropbox would be lost if I started syncing via 1Password.com instead. In fact, the whitepaper notes this under the "Crypto over HTTPS" subheading of the "Beware of the Leopard" section: "when using 1Password for Teams in a web browser, the security is (largely) limited to what is provided by TLS". I am very hesitant to switch to syncing with 1Password.com for that reason.
For my part, I would prefer to have one password to sign into 1Password.com to sync my vaults or invite new users, and a completely separate password to unlock the items in the vault. (I understand that this would mean that I could not view or edit the contents of my vaults from 1Password.com. Because of the state of web/browser security, this is my strong preference anyway.) Syncing with Dropbox behaves this way - I need to sign into my syncing service (Dropbox) with the password for that service, and then I unlock my 1Password vault with my entirely separate master password.
This would also be useful for people who don't want to sync all their vaults to all their devices... for example, I have a personal vault and a work vault. I sync my work vault to my work laptop, personal laptop, and personal phone, but I sync my personal vault only between my personal laptop and phone, in order to keep personal data off my work machine.
Is there anything I'm missing that would alleviate my concerns about TLS security, or are there any plans to permit this kind of workflow in the future?
Thanks very much for all of ya'll's hard work on 1Password.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: 1Password.com
Comments
-
Hi @mrled! Welcome to our forum, and thanks for posting about this. :) The 1Password subscription services are a great alternative to Dropbox and iCloud, actually. I'm sorry there was a bit of confusion about the security aspect though. I'd be happy to clear that up.
However, after some investigation, it seems that some security I relied on when syncing with Dropbox would be lost if I started syncing via 1Password.com instead. In fact, the whitepaper notes this under the "Crypto over HTTPS" subheading of the "Beware of the Leopard" section: "when using 1Password for Teams in a web browser, the security is (largely) limited to what is provided by TLS". I am very hesitant to switch to syncing with 1Password.com for that reason.
I'm glad you gave the White Paper a read. @jpgoldberg always appreciates people reading his work and taking time to learn about security. :) This particular section is about accessing your data from 1Password.com, though in general you'd continue using 1Password as you always have if you moved to an account. Your data would be stored in the 1Password servers and synced to the apps you already use.
If you decide to sign in to your account from a browser using the web app, you can do that too. We've been careful to set strict security requirements for browsers, and ones with outdated security support aren't even able to access the web interface. But in addition to that, there are a few things that protect your account. I like to call them the Three Umbrellas of Account Security™.
Before the umbrellas are your Master Password and Account Key. In the standalone version of 1Password, everything is protected by your Master Password and all the security wizardry in the app. But in an account, the Account Key is used to strengthen things even further. If you have a weak password, it's very unlikely someone will be able to access your data because the Account Key is a 128-bit string of characters that's generated locally when you set up your account. It never leaves your device, and we ask that you print it out to have a copy in case you need it later — you're probably not going to remember the whole thing. ;)
Now, it's great to have a Master Password and Account Key protect your data, but they also need to communicate with the server to access your data, so we use three layers to protect things at rest and in transit.:
The first layer is based on your Master Password and Account key, which are used to derive a secret that is used to securely encrypt all of your data, both at rest and in transit between your devices and our servers.
The second layer is based on the Secure Remote Password protocol. It allows your devices and our servers to make sure they are who they say they are. This provides additional of protection against attack.
The third and final layer is the standard TLS/SSL protocol. It's another layer of encryption that also allows your web browser to indicate that you were communicating directly with a 1Password web server.
The White Paper goes into greater detail about each of these, and the second two are most relevant here. In the section of the paper you mentioned, there are also some recommendations of how to avoid a browser attack like the one we hypothesized. The main one is to heed warnings from your browser when you have TLS connections. Also make sure your operating system always has the latest security updates installed. These are very important for the OS itself, but also for browsers like Safari.
I hope that helps clear things up. :)
0 -
That is an interesting idea @mrled, about having a separate password for authenticating to our server then is used for actual data encryption.
There is a sense in which that happens underlyingly, but I don't think we can find a way to make use of that underlying separation to actually get things to work as you wish.
Two keys for two different reasons
From your Master Password and Account Key 1Password derives two separate keys. One is the x in the SRP protocol, and the other is your "Master Unlock Key (MUK). The SRP-x is needed for you to authenticate to the server. Any time our server makes a decision based who you are it is your proof that you are you from the SRP-x that underlies that.
The Master Unlock Key is the key a separate key derived from your Master Password and Account key (through having a different salt mixed into the key derivation). And it is used to encrypt the key that encrypts the private part of your personal keyset.
(I suspect you know much of this from having looked at the white paper, but I'm spelling that out for people who are following along at home.)
So, at first glance it looks like we could do the kind of thing that you suggest. We already have separate keys, and we could have one derived with an authentication password and another with an encryption password.
The separation isn't clear
The obvious difficulty is that that would add to the complexity the user is faced with (separate passwords for different purposes that do different things). The less obvious problem is it would be enormously more confusing than merely that first confusion.
This second problem is because some administrative functions do require the keys that are made available through creating the MUK. For example, you would be able to invite someone to a Team or Family with just authenticating, but you wouldn't be able confirm that invitation. It is when you confirm the invitation that you decrypt the key to the Shared vault and re-encrypt it with the public key of the person who has joined.
On the whole, we prefer to do as much through encryption (versus authentication) as possible. The example that I gave prevents someone who gains control of our server from adding themselves to a Team. The cryptography requires that the confirmation of the join (sending the new member keys that will enable them to see secrets that aren't of their own creation) be from someone who already knows those keys (and we don't know those keys).
The the range of operations that could be done with just the authentication secret is going to be strange to anyone who hasn't studied the fine details of what keys are encrypted how and the general principles of public key cryptography.
(You might detect from my answer that we've thought about this before)
Over all solution
The over all approach is to reduce dependency on the web-client by bringing more of the administrative capabilities to the native clients. This is something that we are always working on. At the same time we remain extremely strict in our TLS security.
0 -
Hello, I just wanted to come back and say a couple of things.
1) Thanks for the answer (and my apologies for not saying so earlier), I really appreciate understanding the details of what's going on.
2) When shifting admin capabilities to native clients, the master password would never be transmitted to 1Password's servers, but instead used to generate the SRP-x (which of course must be transmitted to 1Password's servers)... is that correct? If so, having admin functions inside the native clients would reintroduce the level of protection that's important to me, which I get now via Dropbox syncing.
3) Do you have any updates on the work of shifting the admin capabilities to native clients that you can share with us?
Thanks again, I love 1Password and am looking forward to all the stuff ya'll are doing.
0 -
Hi @mrled
Jeffrey is away on a well earned vacation right now so I'll do my best to step in here and answer questions he'd typically answer :)
SRP-x is not transmitted to our servers. I would recommend reading the Secure Remote Password section of the white paper. It's in Appendix B and in the current version at the time of writing this starts on page 57. It explains in fairly general terms how SRP works. In this case SRP-x is not transmitted to our servers, it's a secret that is derived from your Master Password, Secret Key and some other non-secret information. From this a verifier, v, is generated. v is sent to the server. (This is simplified, read the White Paper for more details).
When authentication happens there's a unique relationship between x and v such that neither needs to be sent to the other but each client and server can verify mathematically that the client has x and the server has v. They can also agree on a k, which can be used to further encrypt further communications. Neither of these are used to encrypt the data either. That's handled separately by other keys derived from your Master Password and Secret Key.
But you are correct that your Master Password is never sent to our servers. This is of course the same with our web client. Your web client does not send the Master Password now, nor has it ever sent the Master Password to the server. It's used locally in the browser just like it is in our native clients. It's just done in the browser instead of in the native client. They each behave very similarly in this regard, the environment in which they operate is just different.
We haven't done a lot to move admin capabilities to the native clients at this time. We've been hard at work on some other features though. Hopefully we'll get there but I don't think we have a particular time frame for when we'll have that complete or when we might begin that work.
Hope that helps a little bit at least. But if you have any other questions please let us know!
0 -
Hey @AGKyle,
Ahh, ok, thanks for the SRP clarification. I should indeed study that section if the whitepaper in more detail :)
But you are correct that your Master Password is never sent to our servers. This is of course the same with our web client. Your web client does not send the Master Password now, nor has it ever sent the Master Password to the server. It's used locally in the browser just like it is in our native clients. It's just done in the browser instead of in the native client. They each behave very similarly in this regard, the environment in which they operate is just different.
This part makes sense, but I want to clarify my concern. I understand that the master password is not sent to the server, but only used locally, even with the web client. My concerns about the security in this context are more about the environment this code is executing in. The concerns on my mind are:
- The browser is a very complex execution environment that has pieces shared by, theoretically, every other site on the Internet. I greatly appreciate the sandboxing work that browser vendors undertake so that web applications can be executed safely, but I would prefer not to trust my passwords to them. (Not all items in my 1Password database are even web passwords, after all.)
- With a browser, client code is received every time I visit the page. (My understanding is that, technically, it might be cached, but that the response from the server determines whether the cache is used.) In the event of a TLS vulnerability, this would allow an attacker to compromise the code I am receiving. By contrast, local application code is only downloaded if there is an update, and furthermore can be signed and the signature checked by the existing copy of the application, meaning an attacker would have to have not just a TLS vulnerability, but also some way of bypassing or corrupting this signature check, increasing the costs of the attack. Therefore, malicious actors with a TLS vulnerability have a greatly expanded opportunity to attack users executing application code when it's delivered to the browser than they do when it's delivered to a native application.
- Similarly, code coming in over TLS and executed immediately can be targetted more precisely, whether to individual users (probably not my threat model) or to users from a certain area or matching other characteristics (which is a more realistic threat model for me). By contrast, a backdoored non-browser application package is more likely to be received by a wider user base, meaning that detection is more likely.
I don't want to hold the native clients to an impossible standard, either, and I don't deny that there are threats that could compromise their security. For myself, however, I feel that the risks in trusting a master password to a web application are not worth the tradeoff. This is actually what brought me to 1Password in the first place over other password management services.
We haven't done a lot to move admin capabilities to the native clients at this time. We've been hard at work on some other features though. Hopefully we'll get there but I don't think we have a particular time frame for when we'll have that complete or when we might begin that work.
Thanks for replying with this information as well. I understand (and am excited for) new features too. I do hope that over time management features will be incorporated into the native apps, so that I don't ever need to type my master password into a web browser - even if it's only being used locally by the browser.
Thank you and the rest of the team again for your fantastic work and detailed posts here. I can't say how much I appreciate them.
0 -
Hi @mrled
Yup I get those concerns as well. They're concerns we're certainly aware of.
I think we'll probably find some interim fix for that via shipping the web client as some sort of native client where the code is included and can be verified via checksums and code signature.
It doesn't remove the web from the web client, but it does make the client a lot more verifiable. This idea has been bounced around but I have no idea if it'll come to fruition. Would that be enough to cover your concerns?
0 -
Hi @AGKyle,
Yes, a version of the web client wrapped in a native package that is separate from my web browser and can verify a signature for all incoming data would assuage most of my concerns, and I think would be good enough for me to switch to for my main password vault. I think that, while there might still be a few more risks with this scenario compared to a traditionally updated native application, those risks are much less significant than the risks of the current web application, and they would be acceptable to me.
If that idea does end up gaining momentum and being released, I'll be happy. Thank you :)
0 -
Hi @mrled
Great to hear. I'll pass this feedback along. Again, no promises and as far as I'm aware we haven't done any work at all on this yet so it's just an idea at this point.
Thanks for the feedback and the discussion. If there's anything else we can do to help just reach out!
0
