About 1Password asking users to send all their secrets over the internet to 1Password

Dear 1Password,

1Password is not clear about its position on secret key confidentiality. Here are some excerpts from the support page on the secret key, https://support.1password.com/secret-key-security/ :

Your Secret Key protects your data off your devices. Someone who attempts a brute-force attack on our servers won’t be able to decrypt your data without your Secret Key, which we never have.

Also, from the same page

Keep it secret. Don’t send it to us or make it public.

We can draw at least two conclusions from your support page, 1) Keep your secret key secret, 2) Don't share it with anyone, not even 1Password.

The login page at https://my.1password.com requires users to send all their local secrets, master password and secret key, to log in to the 1Password online service. The online service is the only service that allows for account management tasks, such as changing account or subscription details. Sharing all user secrets with 1Password, over the internet, goes directly against everything you've communicated about the secret key so far. To top it off, the endpoint that accepts the secrets are protected by a DV certificate—easily achieved by anyone from services like Let's Encrypt.

Different operations has different requirements to confidentiality, integrity and availability; the 1Password web ui is no exception. Changing credit card details or inviting a new family member to the family 1Password account does not have the same requirements to integrity as accessing all user secrets stored with 1Password.

I ask you to do the following

  1. Don't require the secret key to log in to 1password.com.
  2. If you want to keep operations in the web ui that requires the secret key, make a separate authentication step for that.

Alternatively make the web ui obsolete by offering the same services in the application.

--
Jostein


1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Comments

  • The login page at https://my.1password.com requires users to send all their local secrets, master password and secret key, to log in to the 1Password online service.

    Are you really sending them or does SRP protect you from that?

    https://blog.1password.com/developers-how-we-use-srp-and-you-can-too/

  • As a user, the interface makes be believe I'm transmitting my secrets, but looking closer at the actual traffic, you might be right. They do transmit part of my secret key, but not enough to make me concerned, and the request does mention method: "SRPg-4096".

    Thanks for pointing me do that article, I'll have a closer look.

  • brentybrenty

    Team Member

    @jgogstad: Thanks for reaching out. I'm sorry for the confusion. Indeed, while we intentionally avoid shoving all of the complexity in the user's face, all crypto is done locally on the user's machine when using 1Password in any way shape or form, and the "keys" to decrypt it are never sent to us. There's a good overview of our security model here:

    About the 1Password security model

    But if you want to dig into the specifics, you should definitely check out the white paper:

    1Password Security Design

    It goes into a lot of detail on how all of this works. But the short version is that, as you folks were just discussing above, 1Password.com accounts use SRP -- Secure Remote Password protocol (the blog post XIII linked above goes into more detail about that specifically) -- to avoid transmitting any account credentials at all. Even the 1Password.com web app runs entirely in your browser on your local device so that, just like using the native apps, data is encrypted* there locally before being transmitted; and then data received from the server is similarly decrypted locally as well. So no secrets are ever sent to, stored on, or processed by our server. So this simply isn't true:

    The login page at https://my.1password.com requires users to send all their local secrets, master password and secret key, to log in to the 1Password online service.

    All of that's happening locally on your device, just as any other time you use 1Password. That was really important to us so that we cannot be used to compromise our customers' data, but also because it's what our customers -- and we ourselves -- expect of 1Password: having all of this happen on our own trusted devices so that we don't need to worry about secrets in the cloud or going here and there out over the internet. But since the major browsers gained support for a lot of great crypto and security standards a few years ago, we were able to make this happen.

    I ask you to do the following
    Don't require the secret key to log in to 1password.com.

    That's not really possible, as your data can not be decrypted without it.

    If you want to keep operations in the web ui that requires the secret key, make a separate authentication step for that.

    It's something we can consider. What did you have in mind?

    Alternatively make the web ui obsolete by offering the same services in the application.

    I'm not sure about the time scale, but that is something we'd like to do, and have already been adding some previously web-interface-only functions to the native apps.

    the endpoint that accepts the secrets are protected by a DV certificate—easily achieved by anyone from services like Let's Encrypt.

    I understand what you're saying, but that goes for any website, and is not limited to 1Password and/or Let's Encrypt (so Let's Not Pick On Them :lol: ): no matter what, it's up to you to make sure you're visiting the correct site when you're going to enter your credentials, and maintain the integrity of your devices so you don't have malware hijacking the connection or installing fake root CAs, etc. If your machine is compromised, you're in trouble regardless of whether or not you have a secure connection to our server (or if you're not using the website at all, and the native app instead). We have very strict TLS protocols to prevent downgrade attacks, etc., but we do not control your endpoint of the connection.

    As far as "the interface makes be believe I'm transmitting my secrets", I think maybe you're thinking of it from the perspective of the way web sites work who are storing your secrets (passwords, sensitive information, etc.) themselves do things. So maybe it's helpful to think of 1Password.com as just another app running on a different platform -- your browser, in this case -- since that's really what it is. This stuff just isn't done on the server, because then we would need your secrets to perform operations on the data. Instead, it's completely opaque to us (we can't even see your vault names, much less individual items or their details), and we wouldn't have it any other way. There's too much at stake for all of us -- as customers, 1Password users (ourselves included!), and for those of us whose livelihood depends on us not ending up yet another company who's in trouble due to a data breach.

    Anyway, I hope this helps. But be sure to let me know if you have any other questions! :)

    *I mistyped "excrypted" originally, and while that isn't a word, I think it should be -- a synonym for "decrypted", and an antonym for "encrypted". :lol:

  • @brenty: Thanks for the thorough and elaborate response. The level of service 1Password is giving on this forum is above expectations, you're doing a wonderful job with customer service.

    But if you want to dig into the specifics, you should definitely check out the white paper:

    1Password Security Design

    Thanks, I'll give that and the SRP page a read through.

    It goes into a lot of detail on how all of this works. But the short version is that, as you folks were just discussing above, 1Password.com accounts use SRP -- Secure Remote Password protocol (the blog post XIII linked above goes into more detail about that specifically) -- to avoid transmitting any account credentials at all. Even the 1Password.com web app runs entirely in your browser on your local device so that, just like using the native apps, data is encrypted* there locally before being transmitted; and then data received from the server is similarly decrypted locally as well. So no secrets are ever sent to, stored on, or processed by our server. So this simply isn't true:

    I see. I withdraw my critique of the online login service, thanks for making this clear.

    If you want to keep operations in the web ui that requires the secret key, make a separate authentication step for that.

    It's something we can consider. What did you have in mind?

    Not all the data served in the web ui is encrypted with my master password+secret key. Subscription details, family account details etc. is necessary for you to have in order to operate the service. I find that the only part I need the web ui for is those two use cases, the native application covers all my other use cases for 1Password.

    I believe the online service will be better if you have a two-tier access, one for non-masterpassword encrypted content and one with. My secret key would never leave the 1Password app then, and there would be no phishing attack vector to get my secret key. Seeing that the secret key never leaves my computer anyway, I think this is a "nice to have" and not a "must have".

    the endpoint that accepts the secrets are protected by a DV certificate—easily achieved by anyone from services like Let's Encrypt.

    I understand what you're saying, but that goes for any website, and is not limited to 1Password and/or Let's Encrypt (so Let's Not Pick On Them :lol: ): no matter what, it's up to you to make sure you're visiting the correct site when you're going to enter your credentials, and maintain the integrity of your devices so you don't have malware hijacking the connection or installing fake root CAs, etc. If your machine is compromised, you're in trouble regardless of whether or not you have a secure connection to our server (or if you're not using the website at all, and the native app instead). We have very strict TLS protocols to prevent downgrade attacks, etc., but we do not control your endpoint of the connection.

    This was not the primary critique of my post, and I understand there are financial concerns with buying certificates. EV certificates gives "the green bar", something to look for when sensitive user data is being handled or transmitted. I'm not an expert on this however, and I trust you to make the right decision.

    As far as "the interface makes be believe I'm transmitting my secrets", I think maybe you're thinking of it from the perspective of the way web sites work who are storing your secrets (passwords, sensitive information, etc.) themselves do things. So maybe it's helpful to think of 1Password.com as just another app running on a different platform -- your browser, in this case -- since that's really what it is. This stuff just isn't done on the server, because then we would need your secrets to perform operations on the data. Instead, it's completely opaque to us (we can't even see your vault names, much less individual items or their details), and we wouldn't have it any other way. There's too much at stake for all of us -- as customers, 1Password users (ourselves included!), and for those of us whose livelihood depends on us not ending up yet another company who's in trouble due to a data breach.

    I think that summarises it well. Thanks for the explanation.

  • BenBen AWS Team

    Team Member
    edited December 2018

    Indeed, we used to have an EV (extended validation) certificate, and got away from it. The process for having an EV cert is quite onerous, and doesn't add any technical security. If you take a look at what EV actually is all about it is entirely about verifying the company that says they own the domain and operate the website is indeed the company they say they are. It has nothing to do with enhanced levels of security or extra protection. It is all about identification. This may still make sense in some cases -- especialy for companies that are less well know. If you look around the internet you'll see that many well known companies are getting away from EV. DuckDuckGo, Facebook, Google, Microsoft, etc are all using non-EV certificates.

    Your ideas about a tiered system are certainly interesting and I'll pass that feedback along to the team. :)

    Ben

  • brentybrenty

    Team Member
    edited December 2018

    Not all the data served in the web ui is encrypted with my master password+secret key. Subscription details, family account details etc. is necessary for you to have in order to operate the service. I find that the only part I need the web ui for is those two use cases, the native application covers all my other use cases for 1Password.

    @jgogstad: Thanks for making this point. I'm sorry for not being clearer. When I talk about "1Password data", I mean the secrets we store in our vaults to keep them safe. You're absolutely right that there is other information (like account details, as you mentioned, which I'd call "metadata") that is not encrypted using your Master Password. However, it is still encrypted using other means -- the whole payload, in both directions -- as we want to keep your data not only secure but also private:

    The data you save in 1Password is encrypted and inaccessible to us. Anything else is only ever used to provide you with service and support.

    To protect 1Password users' privacy we collect as little information as possible.

    I believe the online service will be better if you have a two-tier access, one for non-masterpassword encrypted content and one with. My secret key would never leave the 1Password app then, and there would be no phishing attack vector to get my secret key. Seeing that the secret key never leaves my computer anyway, I think this is a "nice to have" and not a "must have".

    Having additional security for admin functions is an interesting idea. Thanks for sharing it! :)

  • nahninahni
    edited December 2018

    @brenty

    all crypto is done locally on the user's machine when using 1Password in any way shape or form, and the "keys" to decrypt it are never sent to us

    Thank god! I was just about to send a rant mail to the support, because I had to type my master password into your site while creating my account (I've been a 1Password stand-alone user for one year now).

    Maybe you should make that clear on that specific page, because if I hadn't found this discussion by accident that would have been a show-stopper for me and if I were a first-time user I would't have looked into 1Password any further.

    EDIT Follow-up question: What measures do you undertake to prevent a hacker from replacing the JavaScript files on your server with malicious ones that send the master password back over the internet?

  • brentybrenty

    Team Member

    Thank god! I was just about to send a rant mail to the support, because I had to type my master password into your site while creating my account (I've been a 1Password stand-alone user for one year now).

    @nahni: Glad you decided to drop in then! To play Santa's Advocate, you'd be entering your Master Password into 1Password on your computer either way, wouldn't you? No matter what, it's just as critical to us that people don't send us their Master Passwords; we really don't want to be in a position where the bad guys use us to get to our customers. We all know how that ends. So we've cut out the middle man: we simply don't have what attackers need to get at your data. Everyone wins. Okay, except the bad guys, but this is the life they chose. :tongue:

    Maybe you should make that clear on that specific page, because if I hadn't found this discussion by accident that would have been a show-stopper for me and if I were a first-time user I would't have looked into 1Password any further.

    Unfortunately most people don't care -- or read. Believe me, people constantly miss the part about needing to keep their account credentials... But for those who are interested, we have plenty of detail in the security white paper:

    https://1pw.ca/whitepaper

    And more general information about our security model and privacy safeguards on our support site:

    https://support.1password.com

    EDIT Follow-up question: What measures do you undertake to prevent a hacker from replacing the JavaScript files on your server with malicious ones that send the master password back over the internet?

    We monitor our server infrastructure around the clock, as does AWS. And apart from our own efforts, we participate in external audits and cooperate with independent security researchers to find any flaws so we can fix them.

    We worry about all of this so that our customers don't have to, and can enjoy a holiday -- or any day -- without having to stress about this at least. It's the gift that keeps on giving. Merry Christmas! :pirate: (←Santa hat, yo)

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file