Security of the 1password.com account creation process

So, I'm a (senior) software developer myself. I'm not a security expert per se but I know the basic stuff pretty well, I guess.

At my job, I was involved in writing an end-to-end encrypted web chat. From that project I've learned that you cannot have an absolute air-tight end-to-end encryption with browsers because there is no way (that I know of) of cryptographically signing JavaScript code. So if an attacker could compromise the web server that's serving the JavaScript files for the web chat, he/she could change the JavaScript code so that it always sends a copy of all decrypted data to a hacker's server.

I'm suspecting that this is also true for the JavaScript code served via 1password.com. If an attacker could compromise the 1password.com web server(s), he/she could change the JavaScript code to silently grab all the secret keys and master passwords and post them to some hacker's server.

Usually this may not be a problem because a security cautious person could solely rely on the 1Password desktop apps (which are probably properly signed and thus trustworthy). However, the initial account creation process is (always?) done in a browser - and not in the desktop app. So I'm a little bit skeptical on how secure this process actually is.

It would be nice if you guys could shed some light onto this problem.


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

«1

Comments

  • brentybrenty

    Team Member

    @manski: Definitely an interesting topic. Though I don't see any questions, you raise some good points. Ultimately an attacker who is able to modify the JavaScript client that is sent from the web server to the user’s device will be able to capture whatever is entered by the user into their malicious (web) app. This seems surprising on the surface, but it's really no different than running anything else malicious on your machine. But obviously the stakes are much higher when we're talking about what is likely some of our most sensitive data (or at least the keys to it) than they would be for chat or most other web apps. There are a few things we have in place to mitigate these sorts of threats though:

    • Using the most recent version of TLS
    • Not supporting weak cypher suites since those could be used for downgrade attacks
    • Using HSTS to prevent downgrade to (insecure) HTTP
    • Offer large monetary incentives to researchers] to help identify weaknesses in our server infrastructure that might expose us to the type of threat you're concerned about
    • Continue to explore new ways to protect 1Password.com (and users) against attackers

    There are also things you (and other users) can do to to protect yourself when using the 1Password.com service:

    • As you mentioned, using the apps is a more secure option, since we're able to digitally sign the code
    • Whether you're using the web app or downloading a native client, verify the certificate of the server you're connected to
    • Keep your browser up to date and heed security notices (expired or invalid certificate warning, for example)
    • Keep your OS up to date
    • Don't allow "security" software to perform a person-in-the-middle attack on your connection

    So while you're right that there isn't a single "silver bullet" when it comes to securing yourself when using the web client, there are a lot of safeguards in place (and more to come in the future) that mean there isn't a single point of failure in this case, even with the limitations of Javascript. :sunglasses:

  • But wouldn't this also apply to sites like LifeLock and banking sites accessed via a browser? I access those sites and 1Password via apps on my I phone and via a browser. I hope they're safe

  • Hi

    Do I need any of them Java plugins to access 1password.com accounts on a web browser?

    Thanks

  • brentybrenty

    Team Member

    @manski: I just realized that I failed to address the thing you mentioned in the title of your post: account creation:

    Security of the 1password.com account creation process

    While much of what I've already said applies, it's important to note that for the most part users will be using the web app to signup. However, we've already implemented signup in 1Password for iOS and want to do the same across all platforms, as well as allowing other functions that are web-only currently to be done in the native clients.

  • brentybrenty

    Team Member

    Do I need any of them Java plugins to access 1password.com accounts on a web browser?

    @telUK: Great question! No. Confusingly, they both have "java" in their names, but Java is very separate and not required. Unless you have a specific need to install Java (most people don't, except for very specific business/development uses...or Minecraft), please don't, as it's infamous for security vulnerabilities. And even if you do require Java for some other application, you can disable it in the browser.

  • brentybrenty

    Team Member
    edited March 2017

    But wouldn't this also apply to sites like LifeLock and banking sites accessed via a browser? I access those sites and 1Password via apps on my I phone and via a browser. I hope they're safe

    @TDK1044: Indeed, any website that is compromised could be used to try to collect the information you enter there, or encourage you to run malicious code. While in most cases there are less stringent security measures in place, keeping your software up to date and verifying that you're connected securely to who you think you are can help you stay safe online. And if you're using 1Password to create a unique password for each site, a compromise of one account won't be the end of your others at least.

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    Well spotted, @manski!

    When you use the web app to talk to 1Password.com, the security can only be as strong as the integrity of the TLS connection over which our JavaScript web client is delivered. (The security of the 1Password web client does not depend on the secrecy of TLS.)

    And, as you correctly point out, sign-up (and some administrative functions) are not available in the signed binaries.

    @brenty has suggested a number precautions that you can take and that we take to reduce the risk of an attacker succeeding in delivering a malicious 1Password web client. Ultimately we are working toward (but progress is slow) a signed native app for each platform that would do everything that the web client does.

    All of this, by the way, is documented in our display department (behind a sign saying "Beware of The Leopard") in our security white paper.

    Beware of Leopard page

    Cheers,

    -j

  • But wouldn't this also apply to sites like LifeLock and banking sites accessed via a browser?

    @TDK1044 That's not entirely true - at least for a banking site. If the web server of a bank was compromised, the hackers could only get your banking PIN. But to do any real harm to your banking account, they'd also needed a TAN. Surely, the hackers could also request a TAN from the user, but banks usually take steps to make sure that TANs are tied to a single recipient banking account (i.e. can't be used to send money to the hacker's banking account). So there's a high chance that your banking account stays safe even if hackers compromised the bank's web server.

  • @jpgoldberg Thanks for pointing me to the security white paper. I'd already found it but just scanned it and didn't read everything.

    It doesn't exactly address the problem I was subscribing but it's close enough.

    Still, I think that if hackers could compromise the 1password.com web server, the impact would be huge. But I guess there is (currently) nothing you guys can do about that. :)

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    Yes, either a compromise of the server delivering the JavaScript or a compromise the integrity of the deliver mechanism would be a Bad Thing™. The full solution will be signed applications that eliminate the need for the web client to be delivered the way that it is.

  • Is the sign-up on iOS only visible when you don't have any vaults at all or only when you're not signed into an 1Password account?

  • FrankFrank

    Team Member

    Hi @Manaburner - The "sign-up" is only visible when you start over on iOS. It's not visible if you're all set up and signed into your account. I hope this answered your question, if not, can you clarify. I just want to make sure we're on the same page :wink:

  • edited March 2017

    Hi @Frank the (hypothetical) situation is this: I'm an existing customer that has one vault synced with Dropbox onto the iPhone. No accounts whatsoever. Will I see the sign-up button for 1Password accounts?

    Same situation but this time, I'm signed into an account. Will I see the sign-up button, when I sign out of the account? Or would the app just offer me to sign in to an existing account?
    I hope I wrote my question understandable :)

  • FrankFrank

    Team Member

    Hi @Manaburner - Thank you for the clarification. If you're syncing with a local vault on iOS, under settings, there is a section "1Password Accounts". It just asks you to sign into your account if you have one. There is also a link that takes you to our website to learn more about 1Password memberships. If you have an account, you won't see the link if you sign out, it's only when you start fresh from the welcome screen. I hope this helps a bit more.

  • Hi @Frank thank you, yes, that helps.
    Just an idea: if you want to convince existing users to switch to a 1Password account, wouldn't it make sense to also show the "sign up" button for them?

  • FrankFrank

    Team Member

    Hi @Manaburner - You're welcome. Yes, you're correct we do think our 1Password memberships offer the better experience but I think the current link that directs customer's to our website is sufficient enough but I do appreciate the feedback. I'll make sure to mention this to my team :+1: Enjoy the rest of your day!

  • Couldn't you argue that the same risk exists with the desktop client that you download from AgileBits' website? If a hacker can compromise the website, they can also compromise the downloadable client and perhaps even the auto-update from within the client. One example of this happening is with the bit torrent client Transmission. I guess this is one argument to download from the Mac App Store.

  • @pervel I wouldn't say that the Mac App Store is immune to hackers. No system is. But IMHO AgileBits are doing a lot to prevent hackers from getting in.

  • brentybrenty

    Team Member

    @Manaburner, @pervel: Excellent points, but with one important caveat: While it could be possible for someone to compromise the AgileBits server, we don't keep our digital signatures there. So while they could offer a 1Password download that was malicious, it wouldn't be signed by us (or Apple — even the AgileBits Store version of 1Password is signed by the AgileBits developer certificate, which is signed by Apple, to comply with Gatekeeper):

    Interestingly, the inconvenient, unceremonious breakage of 1Password for Mac version 6.5.3 offers hope here. The reason everyone had to update the app manually was because the built-in updater checks not only that the server certificate matches the AgileBits it expects (as opposed to an impostor), it also checks the signature of the download. Because we had to change it, it didn't match the old one, and the updater rejected it. The same would happen if someone malicious were posing as the AgileBits update server and/or giving users a file that we didn't sign ourselves. I hope that helps put things into perspective. :)

  • Hi @brenty yes that helps :-)

  • brentybrenty

    Team Member

    :) :+1:

  • For current account holders, would you say it is overly paranoid if you would start from scratch, once it's possible to sign-up to 1Password via the Mac application?

  • brentybrenty

    Team Member

    @Manaburner: Wow. I had to read that a few times to be sure what you meant. That's a tough question. Ultimately it's one that each of us can only answer for ourselves, but I'll try to give you a sense of what I'd take into consideration when choosing for myself.

    1. Do I have reason to believe that my device was compromised?
    2. Was 1Password.com compromised?*
    3. Is it sufficient to simply regenerate my Security Key (F.K.A. Account Key) and/or change my Master Password?

    *To date, there's no evidence that there has been unauthorized access, in spite of the incentives we're offering to security researchers, and the audits that have been performed.

    So at this point, for me, I'd say that's not something I feel is necessary (though again, it's your data and you should do whatever you feel is necessary to protect it). And in all but the worst-case scenario (let's say, critical design flaw), simply changing my credentials will almost certainly be sufficient for my needs. I think you're right to ask this question, but at least for my purposes, there are enough security measures in place that I feel comfortable using the web interface on trusted machines. No one of these would be sufficient, but together they compose an enormous barrier to attack.

  • Hi @brenty
    looks like my question was encrypted too ;)
    Thank you for the clarification.

  • brentybrenty

    Team Member

    Haha I don't think your question was to blame. I think I was just in a different frame of mind at first and had to switch gears since it hadn't been something I'd considered already. Anyway, I'm glad that helped. And my brain probably needed the exercise anyway, so thank you! :lol:

  • I would prefer not to trust the my.1password.com web server. I have already given it a passphrase via the signup process, which I now consider compromised. I am pretty alarmed that Vaults can be opened via the web app, implying continued access to my passwords from the my.1password.com web server, assuming it is compromised. I would like to change my master password, but the instructions suggest that I am only able to do so via the website. Is this accurate? Can you provide an API endpoint that I can hit directly without using the website with my (obviously not plaintext passphrase) to rotate this credential?

    I would also like to only trust software whose source code I can read and verify myself via a deterministic build process, so am wary of trusting any of the clients as they stand now (though of course better than the web client). Has AgileBits thought about what it would take to support people with my security requirements?

    Finally, I have read the security documentation, but details are light on the security of my.1password.com web server. This is surprising to me given that with ordinary usage your security model depends on the server being uncompromised, unless I misunderstand. Are you running a hardened environment? Are you using cloud-based servers or your own hardware? What strategy are you using to secure the hardware, boot stack? What virtualization or containerization exists, if any? What hypervisor are you using? Are you running a stock image or a custom build of an operating system? Assuming it is Linux are you using grsecurity? SELinux? What web server software are you running? Does SSL termination take place on the same machine as the app server? What is your deploy process like? What WAFs/edge infrastructure do you have in place and what vendors do you use, if any? If an attacker was able to deliver Javascript from my.1password.com to a client, what mechanisms do you have in place to detect that? Have you considered signing Javascript blobs to give confidence to clients who would like to verify your Javascript?

    You surely must realize that you are a gigantic target, and I want confidence that you are able to defend against nation-state attackers. The cryptography aspect is not trivial but there are fewer variables and as such it is relatively easy compared to the much more difficult problem of securing your infrastructure and web servers against compromise. Intelligence agencies typically obtain information by breaking into computers rather than through cryptanalysis, and your users are almost surely one of the top targets, as these agencies across the planet try to hoard passwords to use in future cracking attempts.

    Thanks!

    PS Your white paper has a typo on page 16: "ralated"

  • @brenty ^. Also to clarify, the cryptography is super complex if you remove the assumption of security of standard NIST-endorsed cryptographic primitives, and unfortunately the speed requirements make an algorithms reduction to NP-hard problems an impractical area of research. But AgileBits obviously shouldn't be in the cryptography business, given that society is more or less reliant on the assumption that these symmetric and asymmetric crypto primitives are "secure enough".

  • brentybrenty

    Team Member
    edited February 2018

    I would prefer not to trust the my.1password.com web server. I have already given it a passphrase via the signup process, which I now consider compromised.

    @dtauerbach: Thanks for getting in touch! I'm not sure I follow your reasoning here though. Can you elaborate?

    I am pretty alarmed that Vaults can be opened via the web app, implying continued access to my passwords from the my.1password.com web server, assuming it is compromised.

    Nope. All crypto is done locally in the client (web or native app). The server simply doesn't have the "keys" to decrypt the data; only you do. They aren't even sent as part of the sign in process.

    I would like to change my master password, but the instructions suggest that I am only able to do so via the website. Is this accurate?

    That's correct.

    Can you provide an API endpoint that I can hit directly without using the website with my (obviously not plaintext passphrase) to rotate this credential?

    We don't have an API, but it's a capability we'd like the new CLI app to handle.

    I would also like to only trust software whose source code I can read and verify myself via a deterministic build process, so am wary of trusting any of the clients as they stand now (though of course better than the web client).

    I hear you, and it's a great ideal. But unfortunately that's untenable in a marginally less-than-ideal world, just in general and certainly for most users. The reality is that plenty of open source packages suffer vulnerabilities similar to (and more severe than) proprietary software. There is a lot of love in the community, but love doesn't fix bugs. OpenSSL is the poster child for this: it seems to be getting the attention it needs now, but none of us discovered the Heartbleed vulnerability until years later. That's not for lack of passion in the community, but OSS is merely a bullet point if no one is actually doing the work to review the code with a skeptical eye.

    Has AgileBits thought about what it would take to support people with my security requirements?

    I don't believe that's possible. You're talking about not trusting code signing or, really, any developers, and reviewing everything yourself. You and I can't possibly do that for all of the software we depend on, even when the source code is freely available. And it's also a much higher bar for anyone to use 1Password, if we take that to its logical conclusion of releasing a new version's source code (before packaging it for public consumption), waiting for it to be vetted by parties whose only potential positive motivation to do so is altruism (if we pay them to do this, we're back to where we are today). That said, we would like to open source the CLI app once it's complete. But we don't have plans to do that with all of our software, as the vast majority of users are not going to have the time, inclination, or expertise to do a code review and build from source anyway. Part of what the vast majority of our customers pay us for is so they don't have to deal with that stuff.

    Finally, I have read the security documentation, but details are light on the security of my.1password.com web server. This is surprising to me given that with ordinary usage your security model depends on the server being uncompromised, unless I misunderstand.

    Ordinary use, for most users, means using the apps which are codesigned and, in many cases, distributed through an app store. Can you tell me more about the specific attack(s) you have in mind?

    Are you running a hardened environment?

    I'm not sure what you're asking. Can you be more specific?

    Are you using cloud-based servers or your own hardware?

    The 1Password.com security white paper talks about our use of AWS for the server infrastructure. Are you referring to something else?

    What strategy are you using to secure the hardware, boot stack? What virtualization or containerization exists, if any? What hypervisor are you using? Are you running a stock image or a custom build of an operating system? Assuming it is Linux are you using grsecurity? SELinux? What web server software are you running? Does SSL termination take place on the same machine as the app server? What is your deploy process like? What WAFs/edge infrastructure do you have in place and what vendors do you use, if any? If an attacker was able to deliver Javascript from my.1password.com to a client, what mechanisms do you have in place to detect that? Have you considered signing Javascript blobs to give confidence to clients who would like to verify your Javascript?

    I'm not sure we're going to tell you (and everyone else) every little detail about our setup, but you can easily inspect the Javascript yourself as it all runs locally in your browser.

    You surely must realize that you are a gigantic target, and I want confidence that you are able to defend against nation-state attackers.

    We sure are a more interesting target now that we're running a hosted service. That's why we make sure we never, ever have the "keys" to anyone's data. We go to a lot of trouble to prevent anyone from breaking in to our systems, but even if they do they will only have your encrypted data, which is not useful to them without getting your Master Password and Secret Key from you. And "nation states" are not currently in a position to brute force that in any reasonable amount of time. Apart from our own efforts, we also participate in external audits and cooperate with independent security researchers to find any flaws so we can fix them. It's possible that someone could get in, but we've taken measures to avoid having anything they can leverage to access users' data, and we work to further strengthen our security on an ongoing basis.

    The cryptography aspect is not trivial but there are fewer variables and as such it is relatively easy compared to the much more difficult problem of securing your infrastructure and web servers against compromise. Intelligence agencies typically obtain information by breaking into computers rather than through cryptanalysis, and your users are almost surely one of the top targets, as these agencies across the planet try to hoard passwords to use in future cracking attempts. Thanks!
    Also to clarify, the cryptography is super complex if you remove the assumption of security of standard NIST-endorsed cryptographic primitives, and unfortunately the speed requirements make an algorithms reduction to NP-hard problems an impractical area of research. But AgileBits obviously shouldn't be in the cryptography business, given that society is more or less reliant on the assumption that these symmetric and asymmetric crypto primitives are "secure enough".

    Indeed. Fortunately none of the user data on 1Password.com is protected by only a Master Password, which may or may not be great. And arguably weaker Master Passwords some folks might use, the 128-bit, randomly-generated Secret Key is not going to be easy to guess (to put it mildly).

    PS Your white paper has a typo on page 16: "ralated"

    Thanks! We'll get that fixed! ;)

    ref: b5s-428

  • Thanks for the quick and detailed response! I understand the zero knowledge model. The basic reason not to trust the my.1password.com web server is that if my plaintext passwords appear in the DOM, then a compromised server could send malicious Javascript which would just send back plaintext passwords to the server, even without the knowledge of the 1Password team (if an upstream CDN, say, is compromised), unless I misunderstand? This is one of the primary criticisms of the first version of crypto.cat, and the Matasano post: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/. Of course I could run it via burp and intercept every web request and try to read the Javascript, but this would be an exhausting exercise. I'd love another way of verifying the JS similar to how I can ostensibly verify an app via the signing process? Do you have fake 1password web clients in the wild that phone home with unexpected JS, for example? This is the attack I envision might be happening; I understand that by breaking into your servers no data will be immediately accessible. However, by breaking into your servers, attackers have an easy launching point for slurping up tons of user credentials in a targeted or (riskier) mass attack way, which I think is far more valuable to many people than 100K USD.

    I think I trend towards the usability side of the debate, and disagree with many points in the Matasano post and the ire with which crypto.cat was met by the community. It's better to use a password manager than pw reuse. I also understand that the web crypto working group in the W3C is making strides but I don't think we're there yet. As a password manager is one of the juiciest possible targets, I'd hope it would be one of the last use cases to transition to trusting the browser. There are many shades of gray between me reading and verifying every line of code or writing my own client and trusting only myself vs treating password management like an ordinary web app. 1Password has made choices along that spectrum -- of course, you have to run a business and security is always imperfect -- and I'm just interested in a little more detail about the future direction here. I think deterministic builds aren't going to "win", sadly, but I still think this is an interesting direction. I largely agree with you about open source, but thinking about other ways to establish trust in running software is worthwhile. Are you involved with the web crypto W3C working group?

  • @dtauerbach: I'm not going to have as much insight here as @brenty and others I'm sure, but since it's the weekend, I figured I'd hop in with my 2 cents all the same. As @jpgoldberg is fond of saying, security is a process and we're always looking to improve. As is pointed out in the Security White Paper section Jeff pointed to in earlier replies, we are aware that the web app is more vulnerable than native clients and we're definitely working towards a better solution for those who lean towards the security side over convenience (while also hopefully not substantially sacrificing convenience, but that's always a delicate balance). :+1:

    That said, I'll leave a more detailed reply for those better equipped to discuss this in depth as I don't want to risk any misinformation on such an important subject.

«1

Leave a Comment

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