About the new security audit.

Newsuer22 · January 2019

Hey,

I've read through the new security audit and one thing worries me, so I thought I'll just ask.

The application uses an implementation of Secure Remote Password (SRP) to prevent the server from having
access to the user’s master password. This greatly reduces the chances that an attacker would be able to access
user data, even with access to 1Password’s data. It must be noted however, this depends on the integrity of the
client-side code hosted on the 1Password server; any event that allowed an attacker to modify this code could
result in the user’s master password of other data being exposed.

--https://com-agilebits-users.s3.amazonaws.com/security/AppsecConsulting-Summary-20180822.pdf

Maybe I'm just reading it wrong, English is not my native language, but does that mean that an attacker can modify the code on the server so that they have the master password of the user logging in at that time?
When they are already on the server they also would have the databases.
Or does the secret key prevent them from unlocking the vaults/databases in that specific case? Or could they modify the code to obtain the secret key too?
If so the encryption would be useless when they can obtain both with modifying the server code.

Also there are pages missing, will they be added in the future or excluded for privacy reasons?
Only sites 3 to 7 are present of 18.

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

AGAlumB · January 2019

Maybe I'm just reading it wrong, English is not my native language, but does that mean that an attacker can modify the code on the server so that they have the master password of the user logging in at that time?

@Newsuer22: Not quite. But I agree that the wording is a bit confusing. :)

What it's saying is that if someone malicious were to take over our server, they would be able to give anyone who visits it whatever web page they want. It's like when websites get hijacked to display ads or vandalism, just worse since it would be 1Password, so we're determined to prevent that from happening.

When they are already on the server they also would have the databases.

That's correct. But (counterintuitively) this isn't a problem because we never have the keys to anyone's data. So they would only have encrypted data, and no means to decrypt it.

Or does the secret key prevent them from unlocking the vaults/databases in that specific case?

You're good! ;) Indeed, that is precisely the reason the Secret Key exists. Even if an attacker downloads your encrypted data from our server, without your Secret Key, they cannot even perform a brute force attack against your Master Password: they would need to simultaneously guess your Master Password and (128-bit, randomly-generated) Secret Key. So that's good news. :sunglasses:

https://www.youtube.com/watch?v=Krbl911ZPBA

Or could they modify the code to obtain the secret key too?

Indeed, that's the problem. If they control the server, yes, they'd be able to send you whatever they want -- including a fake 1Password webpage that asks for your Secret Key. That's bad. :(

But keep in mind that's the same for any website: if someone is able to take control of google.com or whatever, they could similarly send visitors an arbitrary web page to do evil. So, like others, we constantly monitor our services for any potential problems, and work with security professionals both internally and externally to find and address any issues.

If so the encryption would be useless when they can obtain both with modifying the server code.

Correct.

Also there are pages missing, will they be added in the future or excluded for privacy reasons? Only sites 3 to 7 are present of 18.

Good question. I'll get you an answer to that!

gedankenexperimenter · January 2019

The thing that concerns me most is a reverse proxy phishing attack (e.g. Modlishka), perhaps initiated via an email with link to, say, https://my.1passwerd.com/signin or some variation that's difficult for humans to catch. This would present the user with a page that looks just like this:

…and the attacker would get all of the victim's information at once, and be able to decrypt the whole password database.

I would really like to see the 1Password web site use a two-step login and decryption process instead of this single page. That way, a user could meaningfully employ a U2F device (e.g. Yubikey) after the master password was entered, but before the prompt for the secret key is presented. Unlike OTP, U2F should be immune to this kind of phishing attack, because it would generate a key that would not be valid, stopping the user from also providing the secret key to the attacker. Even if the attacker constructs a page that does prompt for the secret key at the same time as the password, U2F authentication would fail, and they wouldn't be able to access the database to decrypt it.

More generally, I'd like to be able to log in and manage my 1Password account without having to also decrypt my password database in my web browser, which I don't trust nearly as much as the 1Password standalone apps. Every time there's something I have to do on the website, I get very nervous about that secret key being required; I basically never want to access my database via the website, but 1Password doesn't give me a choice.

ref: https://discussions.agilebits.com/discussion/comment/484702#Comment_484702

gedankenexperimenter · January 2019

@brenty:

What it's saying is that if someone malicious were to take over our server, they would be able to give anyone who visits it whatever web page they want. It's like when websites get hijacked to display ads or vandalism, just worse since it would be 1Password, so we're determined to prevent that from happening.

On a smaller scale – but potentially even worse for an individual user – if someone malicious tricks a user into entering both their master password and secret key into a fake version of the 1Password website, that user's whole database would be compromised. If done carefully, the user might not even notice that it happened, and this wouldn't involve any sort of takeover of the real 1Password web server(s), which would be much more likely to be quickly detected and fixed by AgileBits.

jpgoldberg · January 2019

That's a useful thought experiment, @gedankenexperimenter. (Sorry, I had to say that.)

Yes, it is possible for an attacker to gain everything they need via a phishing site. But breaking this up into multiple pages doesn't change the threat. And in our case would only be for show, as there is nothing that the genuine web client can do until it has has all three pieces.

There are things that don't eliminate the threat, but that at least reduce the scope of some attacks:

Users are notified when a new client is set up, so there is some individual to users that their secrets may have been reused.
Sign-ins via the native clients (including 1Password X) are immune to capture by phishing. This is one of the reasons why we are working to move more functionality into the native clients, so that web-client logins are reduced.
We also use HSTS and insist on TLS version 1.2 (or greater), which makes it harder for an attacker to tamper with the web page in transit.
Enabling 2FA doesn't prevent someone from getting phished, but it does make it harder for an attacker to make use of the information that they collect through phishing.

We are not fully satisfied with these mitigations, but we do what we can and we continue to look for ways to both protect users from being phished and to reduce the damage that an attacker can do if they successfully phish someone.

jpgoldberg · January 2019

Hi @newuser22,

Let me follow-up on what @brenty said.

Omitted pages

Also there are pages missing, will they be added in the future or excluded for privacy reasons?

Only sites 3 to 7 are present of 18.

This is to save me time. First of all, it is customary to just publish the summaries and lot list the "vulnerabilities" found. We chose to follow that custom mostly to save me time. The half a dozen "best practices" issues that are listed in those pages are really not applicable to user security.

For example, one is titled "Sensitive data in cross domain cookies". That looks like a really dumb practice when you read it, but the actual explanation for it takes longer to go into. The cookie in question is not at all needed or used within the service itself, but it is when you come back to start.1password.{com,eu,ca} to direct you to the appropriate one of com, eu or ca domains if your browser tells us which one you've used before. This necessarily has to be cross domain cookie, and it does need to contain account ID information.

The other issues are similar. They are deliberate design choices that make sense for what we have, but would take a long time to explain. We could have gone back to to Appsec Consulting with explanations to have each of these issues "closed" (as we did with some), but we simply didn't bother. This is because our primary reason for having the test done was to find things we we may have overlooked. Public attestation was a distant second. The goal of having external experts to poke at things is to find the (inevitable?) things we may have missed.

Had we anticipated publishing the whole thing, we would have talked to them to get those issues "resolved" in the sense that they would sign off on our design choices. Instead, we just did this for the issues that were mentioned in the summary.

Tampering with clients

Does that mean that an attacker can modify the code on the server so that they have the master password of the user logging in at that time?

This is about delivery of the web client. It is not about modifying the what 1Password does server side. It is about tampering with the web client on the server from which the web client is delivered. There is nothing wrong your ability to read English, its that the term "server" is very context dependent.

First a little background. When you sign in to 1Password in the browser it appears like a normal web page login where you are talking to a server. But our process is different: We never want to receive your Master Password and Secret Key. No secrets are transmitted to us during sign in. So all our clients use a protocol called SRP for authentication (the server and client prove to each other that they know certain secrets, but without revealing any secrets). The way this is done in your browser is that when you go to the sign in page, a fairly substantial program is downloaded to your browser and then run within your browser on your local machine. That program is "the web client".

If you can be tricked into running a malicious version of 1Password on your own machine, that malicious client can grab anything you give it, and it can do whatever it wants with what it grabs. For the native clients (including 1Password X), there are whole mechanisms of code signing and such that ensure that the client you are running on your machine hasn't been tampered with. The same guarantees aren't available for how the web client is delivered. So our fancy SRP stuff doesn't protect you if someone can tamper with any client, but the opportunities to get away with tampering with the web client is are greater than with tampering with the native clients given how it is delivered.

I should point out that this is an issue with anything with a web interface. This is not in any way specific to 1Password. We also describe this in more detail in the "Beware of the Leopard" section of our security white paper.

TOTP v U2F

You are correct that TOTP one time codes can be relayed, while U2F ones cannot. U2F really is a brilliant protocol. But as I said, it wouldn't prevent an phisher from learning your Master Password and Secret Key, but it would make it harder for them to make use of that information. Let me explain why I find that distinction important.

What is important to keep in mind is that if an attacker gets 1Password data from your own machine then the only thing protecting that data is your Master Password. (The attacker will get your Secret Key with your local data and will not need to authenticate at all, and so no authentication factors play a role.) So even if sign in is protected with a zillion authentication factors, a user's weak point is the strength of their Master Password in the event of data capture from the users own systems. Because we consider the Master Password the weak point, we are hesitant to introduce anything that would encourage weaker Master Passwords.

With every other service for which people use U2F, it allows them to get away with weaker or reused password. But 1Password is different. We can't expect everyone to understand those differences, they will use U2F the way that they use it everywhere. But in the case of something like 1Password (and other password managers) this can lead to people weakening what is already the weakest part of their security.

I spoke with someone at Yubico not so long ago who said that they really want to use 1Password but they use a competitor because that competitor offers Yubikey support. I asked "so do you use a weaker master password for that product as a result of using your Yubikey." Their answer was, "Yes, that's the whole point." Although I wasn't at all surprised, I found that terrifying: They were weakening the weakest point of their password manager's security for a small gain in authentication security.

gedankenexperimenter · January 2019

@jpgoldberg: Thanks for the detailed explanation of the authentication process, and the underlying reasoning. I'm afraid that I only just got around to reading the 1Password Security Design white paper, and would have saved you the trouble if I had been quicker.

I'm very surprised to hear that people are choosing weaker passwords when using U2F. But I submit that using better 2FA does not require users to weaken their primary authentication mechanism. As one of those users, I care about the security of my data, not so much about everyone else's, and it's very frustrating to hear that you don't want to let me protect my password data from a known (hypothetical) form of attack because you think some people will do something foolish if you do.

You say "small gain in authentication security"; I say "fixes a glaring security hole". 1Password downplays authentication security so much, but fails to acknowledge that this is not just an authentication issue, because it allows an attack that gives up all the secrets at once. An attack that you could allow us to protect ourselves against, by letting us choose a more effective means of 2FA.

I bet that people already choose weaker Master Passwords with 1Password than they do with other password managers because of the Secret Key, and the big deal that is made about it. And I bet that effect is already bigger than it is for people using U2F. Of course, since you don't have access to those Master Passwords, you have no way of knowing how strong they really are, do you?

And why bother offering TOTP 2FA? Doesn't that also encourage people to use weaker passwords (while providing ~zero protection against the phishing attacks that I'm concerned about)?

AGAlumB · January 2019

I'm very surprised to hear that people are choosing weaker passwords when using U2F. But I submit that using better 2FA does not require users to weaken their primary authentication mechanism. As one of those users, I care about the security of my data, not so much about everyone else's, and it's very frustrating to hear that you don't want to let me protect my password data from a known (hypothetical) form of attack because you think some people will do something foolish if you do.

@gedankenexperimenter: I think by virtue of participating in this discussion we all agree that using a weaker Master Password is a bad thing...but getting away from having to remember a complex password really is one of the key selling points of hardware tokens. As a result, many, many people take that as an opportunity for greater freedom: "If I just hang onto this token, I'm secure." And in many cases that is a step up in security. But as Goldberg mentioned, with things other than a password manager, it's less of a problem for people to rely on multifactor authentication. We really need to take that reality, -- and millions of other users -- into account when considering these things.

You say "small gain in authentication security"; I say "fixes a glaring security hole". 1Password downplays authentication security so much, but fails to acknowledge that this is not just an authentication issue, because it allows an attack that gives up all the secrets at once. An attack that you could allow us to protect ourselves against, by letting us choose a more effective means of 2FA.

1Password's security is based on encryption, not authentication, so it's really apples and oranges. Certainly I understand your impulse, but it's coming from the fact that you really do need extra authentication with a lot of other services since there is literally nothing else protecting you.

You're right that your connection to download the web app is a weak link, but there is not a way to guarantee that you ultimately receive and run authentic code on your machine, since there is no facility for code signing. But I think that in your love for U2F you're overlooking that it is not the only (partial) solution to this problem. Building admin capabilities into the native apps (which can be validated) is something that can not only help with 99% of cases, it does so without placing greater burden on the user -- which is exactly what multifactor and/or requiring separate credentials just for administration do. We've done some of that already. You can already sign up for an account right within many of our native apps -- no browser required -- and also do some vault management. And we'll continue to do more in this area.

I bet that people already choose weaker Master Passwords with 1Password than they do with other password managers because of the Secret Key, and the big deal that is made about it. And I bet that effect is already bigger than it is for people using U2F. Of course, since you don't have access to those Master Passwords, you have no way of knowing how strong they really are, do you?

To clarify, the Secret Key doesn't server the function you seem to think it does. As I mentioned earlier, it's purpose is to protect users from attacks against us -- so that someone who steals data from the server cannot perform brute force attacks against people's Master Passwords. Authentication would not help with that.

And why bother offering TOTP 2FA?

We offer two-factor authentication because it is a regulatory requirement for many enterprises.

Doesn't that also encourage people to use weaker passwords (while providing ~zero protection against the phishing attacks that I'm concerned about)?

Master Passwords cannot be leas than 10 characters, so there are limits to how far people can go. And the "phishing protection" you're lauding doesn't do everything you seem to think. If an attacker can see what you're doing anyway, either on your machine or over your communications, it doesn't matter if they have the means to actually hijack your account or not; they can just sit back and have you access it for them.

You're right that the delivery of the web client is a weak link, but again, that's true of anything delivered that way, not limited to 1Password. You're wrong that U2F is a security panacea, especially in the context of 1Password, which does not depend solely on authentication the way that most services do. Certainly it's something we may add support for, but not to present it as a solution to something it does not solve; and not lightly, as there is a lot at stake any time we introduce a feature which could be misconstrued, misused, and ultimately harm people more than it helps them. It's important we take all of that into account and strike the best balance we can.

gedankenexperimenter · January 2019

@brenty: You don't seem to understand the vulnerability that I'm concerned about. The type of phishing attack in question acts as a proxy for the 1Password website. The victim is tricked into following a link in an email that looks like it came from 1Password, and the page they see looks and behaves exactly like the real 1Password website, because the attacked is relaying credentials (including the TOTP) to the real 1Password site by accessing the web client on the attacker's server.

And the "phishing protection" you're lauding doesn't do everything you seem to think. If an attacker can see what you're doing anyway, either on your machine or over your communications, it doesn't matter if they have the means to actually hijack your account or not; they can just sit back and have you access it for them.

I don't think you understand how U2F works. This attacker has no direct access to the victim's machine or to the 1Password server, but because the web client requires all the same secrets for authentication that it does for decryption, the attacker gets both at the same time, without compromising either endpoint. U2F would prevent this attack from working, because the key generated would work only for their fake version of the 1Password domain, not the real one. TOTP does nothing, while putting a bigger burden on the user.

I completely understand and agree with the principle that password manager security should be primarily encryption-based, but that doesn't mean that authentication-based security is pointless, especially when all the secrets required for the one are also required for the other.

Building admin capabilities into the native apps …(which can be validated) is something that can not only help with 99% of cases, it does so without placing greater burden on the user -- which is exactly what multifactor and/or requiring separate credentials just for administration do. We've done some of that already. You can already sign up for an account right within many of our native apps -- no browser required -- and also do some vault management. And we'll continue to do more in this area.

Does this mean that AgileBits has concrete plans to add all of the functionality that is currently available only via the web client to at least one of the native apps? That would be great news. I would never use the web client again, and probably block it from any browsers used by members of my family. (Frankly, I would prefer it if the web client simply didn't exist.)

I want to dispute your claim that either separate account-administration credentials or multifactor authentication place a "geater burden on the user", though. In practice, as a user of 1Password, if I had a separate password for a hypothetical admin-only 1Password website, that website would be just one more among the hundreds of accounts that I already have, and I wouldn't even need to add it by hand, because it would be generated automatically when I set up my 1Password account. It would even serve as a useful example of what a login entry should look like. I would fill in my username and password using the same keyboard shortcut that I use for logging into any other website, including the 1Password web client. I would have no need to remember that password, or even know what it is at any time.

Adding 2FA does, I will admit, add an extra burden, but in practice, that burden is miniscule, because it's only required when the client is not recognized by the server. And if that second factor is a hardware token, the only additional thing I have to remember is where my hardware token is (probably on my keyring, which I already have to keep track of, anyway). If it's an authenticator app, I have to remember which app, and find a different entry for each service (whereas it's the same hardware key for all of them), and rush to type in the one-time password before it expires. I find this much more stressful than a hardware key. (And 1Password does make this much easier, at least for some websites, by automatically copying the TOTP code to the clipboard for me). The extra burden is so tiny compared to the added security that I would always choose to employ it.

Master Passwords cannot be leas than 10 characters, so there are limits to how far people can go.

I would consider any memorable password that short to be unacceptably weak, myself, but the strength of the master password is irrelevant in the case of phishing attacks. Furthermore, people who don't understand the nature of good password security will continue to use bad ones regardless of what you do. Why not let those of us who do understand use all the tools at our disposal to protect our most valuable data?

jpgoldberg · January 2019

I'm very surprised to hear that people are choosing weaker passwords when using U2F.

There is yet to be a systematic study of this, but do keep in mind that everywhere else that people use U2F it does allow them to get away with weaker or reused passwords. U2F and other 2FA systems are advocated by services specifically because they know that people use weak, reused passwords. You might understand that 1Password is different than those other services with respect to the Master Password, but that puts you in the minority.¹

I did put out a "call for research" on exactly this at SOUPS (Symposium on Usable Privacy and Security) this past summer. But we probably need to start sponsoring research for it to really happen.

But I submit that using better 2FA does not require users to weaken their primary authentication mechanism.

That is true.

As one of those users, I care about the security of my data, not so much about everyone else's, and it's very frustrating to hear that you don't want to let me protect my password data from a known (hypothetical) form of attack because you think some people will do something foolish if you do.

I'm sorry, but this is what we are all about. We are trying to bring top-notch security to people who aren't experts. This means reducing the ways in which people can shoot themselves in the foot. It is what we do, and I believe that it is one of the reasons that we've been successful. We try really hard to not add too many "advanced options", even if we ourselves would make use of those. There is always room for "one more" advanced option, but that leads to twenty more.

Furthermore, my experience is that the people who insist most adamantly on 2FA for unlocking 1Password are the ones who are most likely to misunderstand its security properties. We've had people demand 2FA because they thought it would make it safe for them to unlock 1Password on a compromised computer. So yes, we have to consider how people may use a feature against their own security interests if it is offered. While we can't prevent all such things, we do need to take those into consideration. And there are gross misunderstandings of the security properties of 2FA both in the general public and even among knowledgeable users.

The mysterious future

I'm not saying that we won't support U2F. We already support TOTP, and U2F is clearly superior to TOTP. But if we are going to take the downsides of it, I want it to do more.

One thing that we are looking at is having something like an online-only mode. Your vault keys and personal keyset would not be persisted locally. This means that an attacker who gets your local data would not be in a position to run a master password cracking attempt, and authentication to our server would be necessary for you to decrypt your data. In such a context, strengthening the authentication component (through something like U2F) would make more sense. But at the moment, authentication plays a far lesser role in 1Password's security than it appears (particularly to most people, who aren't even aware of the differences between authentication and encryption.)

There are lots of other things we would need to do first to offer such a mode, in particular we'd need to have stronger guarantees of uptime during database maintenance and upgrades as well as better sense of how well we could withstand (D)DoS attacks. But with such a mode, there are more substantive gains in beefing up the authentication component, and there is a reduced dependency on the strength of master passwords.

We have users who think that we have full access to all of their data and are completely oblivious to the e2ee aspect of things. We discover this when they report to us that they've forgotten their Master Passwords and want us to let them back in. We can't blame people for believing that because that is how just about every other service they use works. Sure we tell them during signup, but that has little effect. I should note that it is somewhat gratifying that people trust us under such assumptions, but it is also terrifying that they would trust anyone under such assumptions. ↩︎

gedankenexperimenter · January 2019

I submit that people who think multi-factor authentication is a good reason to weaken their password(s) will also not understand the critical difference between TOTP and U2F that I have been harping on here. If they're going to use weaker passwords because they've set up 2FA, they're almost certainly doing it already.
I have no interest in an online-only mode myself, but it would appear to require the users to remember both their Master Passwords and their Secret Keys, which is clearly not how it would work, given your belief that even the miniscule "burden" of using a U2F key is considered too onerous. How this would both justify an increased reliance on authentication and a decrease in master password strength is a mystery to me. [Feel free to ignore this entirely, as I have no interest in a password manager that only functions if I'm connected to the internet — I use it to store secrets that do not require the internet, and require that I keep access to those while offline.]

I want to bring this discussion back to my main concern: Because 1Password uses both secrets (Master Password & Secret Key) for authentication as well as decryption — which you see as a benefit, and I see as a flaw — a user's credentials can be captured by a phishing attack. TOTP offers (almost) no protection from that attack. U2F would prevent that attacker from gaining access to the user's data, leaving only their credentials compromised. That is what U2F is for. This is a known, concrete benefit, and your argument against it (that users would choose weaker passwords vs TOTP 2FA) has little to no evidence to support it.

I'm saying you shouldn't add more "advanced options"; I'm saying you should replace weak TOTP support with superior U2F support. As it is, TOTP is basically only good for letting the user know that the server thinks it's a new login, whereas U2F actually protects the user who fails to recognize that as a warning sign.

Newsuer22 · January 2019

Thank you @brenty and @jpgoldberg
I think I understand it for the most part.
Also I appreciate that you make external audits just for looking if everything is the way it's supposed to be.
After all (I hope) we're all human and can make mistakes or overlook things.

Thank you for taking the time and explaining everything so thoroughly.

jpgoldberg · January 2019

You've hit upon an extremely tricky question (which is the subject of much debate) with

I submit that people who think multi-factor authentication is a good reason to weaken their password(s) will also not understand the critical difference between TOTP and U2F that I have been harping on here. If they're going to use weaker passwords because they've set up 2FA, they're almost certainly doing it already.

If we already have 2FA with TOTP then why not with U2F, which is clearly superior in its security properties? That is, while 2FA might have the problems I raised, if we are going to have it, we shouldn't we be doing it right?

This is the crux of the current internal debate on this. I will tell you my position, which is not necessarily the position that will prevail.

Some background

We've been concerned about this issue since before we introduced TOTP 2FA. Quite honestly we felt that it offers little real security value, but there were simply too many potential customers who wouldn't even talk to us if we didn't offer some form of 2FA. It simply wasn't tenable to continue to refuse. So we offered the minimum, squirreled it away, used it only where it made some sense (setting up a new device), and hope that it didn't do too much damage.

My concern (not universally shared by my colleagues) is that U2F is a whole lot easier and more convenient to use that TOTP. It is also perceived of as stronger. And so the uptake of 2FA will be greater with U2F and the perceived strength of it will more strongly lead to the effective we're worried about.

There is another couple of things that are more to do with timing. We used to more strongly encourage that people pick strong, memorable master passwords than we now do. But in streamlining the enrollment process we had to drop that. I want to focus energy on what I see as the weak point of most people's security (their choice of master password). So I am more sensitive than I was 18 months ago to anything that further downplays the importance of a strong, unique master password.

Another way of putting it is that I think in retrospect we erred in not doing things to strengthen MP choice when we introduced TOTP. It was an easy mistake to make at the time, but instead of it being taken as a precedent, I think it is a mistake that we shouldn't repeat.

As you see my position, while one that I strongly believe in, is not exactly compelling to those who aren't already inclined to see things my way. So you may very well get what you want (and I will just whine a bit internally.)

I have no interest in an online-only mode myself, but it would appear to require the users to remember both their Master Passwords and their Secret Keys, which is clearly not how it would work,

That is not how it would work. Your Secret Key would persist on your device just as it does now. What would not persist is what we call your "personal keyset". This is (I'm taking a lot of shortcuts in this description) is a public/private key pair with the private part encrypted with your MUK (more shortcuts; it's more complicated). Your vault keys (which are the keys that actually encrypt your data) are encrypted to your public key. Without your private key, you cannot decrypt your vault keys which mean that you can't decrypt your data.

So you would need to connect to the server and authenticate (your client was already have your Secret Key) and the server would deliver your encrypted personal keyset. Some time after your session ends, your personal key set would be removed from your device, after which you wouldn't be able to decrypt anything that you hadn't already decrypted during that session. (The details of that would need to be worked out.)

This is semantically coherent with beefing up authentication. Currently, the bulk of your security comes from the encryption side of things, but if your personal keyset (which is not your Secret Key), isn't stored locally, than authentication plays a bigger role in your true security.

Because 1Password uses both secrets (Master Password & Secret Key) for authentication as well as decryption — which you see as a benefit, and I see as a flaw — a user's credentials can be captured by a phishing attack.

I think you may be overlooking just how important a benefit it is. The benefit from this is that if our servers are breached then the attacker cannot run master password guessing attacks on your data. The point of this is so that we are not hosting any data worth stealing. Data that were merely encrypted with Master Password would be worth stealing. This is not only protecting you from a breach but also from an insider attack or an attack through coercion.

Driver carries no cash and is naked

Furthermore our authentication system is extremely strong compared to traditional authentication. What you seem to be asking for is that we weaken it to give it the problems that traditional authentication has so that it could be strengthened if a different way.

Here is a table from a version of the paper that I presented at PasswordsCon (and SOUPS/WAY).

MFA comparison chart

So yes, U2F is good. But we certainly aren't going to weaken what we have (particularly in such a way as to learn user secrets) to address one specific attack.

gedankenexperimenter · January 2019

I think you may be overlooking just how important a benefit it is. The benefit from this is that if our servers are breached then the attacker cannot run master password guessing attacks on your data. The point of this is so that we are not hosting any data worth stealing. Data that were merely encrypted with Master Password would be worth stealing. This is not only protecting you from a breach but also from an insider attack or an attack through coercion.

I think you are overlooking the disadvantages. Because my encryption key (likewise simplifying) is required for authentication, it becomes vulnerable to attacks that would otherwise have no way to access it, from server breaches, insider attacks, or from man-in-the-middle phishing. If my encryption key was only used for encryption (which I thought was the case when I decided to use 1Password — and was the primary reason I chose to do so instead of using other services), there would be many fewer ways for an attacker to acquire it. Then, even if you were storing password hashes on the server, and some users (as they inevitably will) choose easily crackable passwords, those passwords would not give the attackers access to the real user data unless they separately gain access to the corresponding encryption keys.

By requiring the Secret Key for authentication, you have made improvements to authentication security, but made encryption security vulnerable to a whole class of credential-stealing attacks. This certainly doesn't seem consistent with the 1Password mantra that encryption is more important than authentication.

jpgoldberg · January 2019

My encryption key (likewise simplifying) is required for authentication, it becomes vulnerable to attacks that would otherwise have no way to access it, from server breaches, insider attacks, or from man-in-the-middle phishing.

It is not vulnerable to insider attacks or server breaches.

I suspect that you may be mislead by the name "Secret Key". It is really just another password, but one that is meant to be stored locally and not remembered. Your actual master unlock key is derived from both those these "passwords". As is your SRP-x. (Though differently salted so that one cannot be computed from the other.)

By requiring the Secret Key for authentication, you have made improvements to authentication security, but made encryption security vulnerable to a whole class of credential-stealing attacks.

If we only used the MP for authentication, then the SRP verifier, if captured, could be used for a master password cracking. So no, our use of the Secret Key here is to strengthen the encryption.

Oh, I get it! (and I just delated about 800 words of draft response about the role of the Secret Key). If we only used the SK for deriving the MUK but not the authentication verifier then a server breach (insider or otherwise) could crack the MP using the authentication verifier, but still wouldn't be able to decrypt data without the SK. Interesting.

It would make a server breach more damaging, as there are still things that can be done solely through being authenticated, but this is something that I will have to think about. I really like holding on to nothing crackable at all, but this is an idea that certainly should be considered the next time we redesign authentication (something that isn't happening for a while as it would involve major changes in all clients.) Hmm.

gedankenexperimenter · January 2019

It is not vulnerable to insider attacks or server breaches.

I disagree. I'm considering the case where the attacker/insider has replaced the web client with a version that sends the entered credentials, including the Secret Key, to the malicious party. If the server has been compromised, this is at least hypothetically possible.

Of course, now that I consider all the possibilities, if the client has been maliciously replaced, it could steal the Secret Key, even if it's not used for authentication…unless the web client in question was (normally) only used for administration functions, but was not designed for decrypting the user data.

Whether or not a separation of authentication and encryption keys would make a server breach worse depends on what the attacker is able to do with the breached server. If they can replace the web client and steal all credentials from users as they connect, that's probably worse than merely being able to crack the weaker Master Passwords (which still doesn't give them access to the encrypted user data).

Thank you for taking the time to read my long-winded arguments; I finally feel like someone there is starting to understand my concerns about the web client. [On a related note, is there any way to regenerate the Secret Key from one of the native clients? If not, that is by far the first thing I want to be able to do without relying on the web client.]

jpgoldberg · January 2019

I'm considering the case where the attacker/insider has replaced web client with a version that sends the entered credentials, including the Secret Key.

A malicious web-client would be able to do that even if the Secret Key is entered later. Eventually the user must provide the client with the secrets needed to decrypt the data. Whether this is on the first page or on some later page doesn't matter if client is malicious.

So this returns to what the OP highlighted from the report. It is easier for an attacker to get away with delivering a malicious web client than it is to deliver a malicious native client. And if that attacker is an insider or has control of the CDN/hosting provider then U2F or only interring a decryption secret later isn't going to defend against that at all.

gedankenexperimenter · January 2019

A malicious web-client would be able to do that even if the Secret Key is entered later.

Yes. And you are absolutely correct that U2F would be ineffective in that case. Which is why I would much prefer a version of the web client that doesn't use the Secret Key for authentication, and doesn't decrypt the user data.

My previous message was entirely about the benefits of separate keys for authentication and decryption, not at all about U2F. Of course, this is 1Password, not 2Password, so I don't expect to convince anyone here that it would be better…

jpgoldberg · January 2019

I would much prefer a version of the web client that doesn't use the Secret Key for authentication, and doesn't decrypt the user data.

I can see that. If the web client were only for the administrative panel, then it would never need to be give encryption keys.

AGAlumB · January 2019

[On a related note, is there any way to regenerate the Secret Key from one of the native clients? If not, that is by far the first thing I want to be able to do without relying on the web client.]

@gedankenexperimenter: I'm sorry this was missed earlier. The answer is yes! It does need to be done through the web interface though, which is not great news in this context:

https://start.1password.com/profile

However, I think that ties in nicely with something else you brought up:

I'm considering the case where the attacker/insider has replaced the web client with a version that sends the entered credentials, including the Secret Key, to the malicious party. If the server has been compromised, this is at least hypothetically possible.
Of course, now that I consider all the possibilities, if the client has been maliciously replaced, it could steal the Secret Key, even if it's not used for authentication…unless the web client in question was (normally) only used for administration functions, but was not designed for decrypting the user data.

Indeed, it all comes full circle. This is why we're not secretive about how 1Password works, or hostile to security researchers. We actively encourage people to poke and prod and verify so that our customers can know that their trust is not misplaced, and so we can continually improve. You're taking part in that process here, and there are plenty of folks independently hammering away at our systems to find any weaknesses from the outside. Internally, we've got security reviews, checks and balances, and policies in place compartmentalize as much as possible so that no one person -- by being compromised themselves, or having their accounts taken over -- can be the instrument of taking over the server or making changes to code for ill purposes alone. So while you're right that there are always risks, and that some security measures are insufficient for every potential attack, in aggregate our defenses hold up -- even as we continue to harden them further. It's an ongoing process. :)

gedankenexperimenter · January 2019

@brenty: Thank you for taking the trouble to answer my question regarding generation of a new Secret Key, and for confirming my guess that it can only be done on the web client. However, I specifically asked if any of the native apps could perform that function, as the web client is clearly the one most vulnerable to many forms of attack. If my Secret Key is compromised – likely because of one of the web client's vulnerabilities that it doesn't share with the native clients – I really don't want to use the least trustworthy client to generate a new one.

So, the answer to my question is really "No, the Secret Key cannot be regenerated by any of the native clients – only the web client can do it." I will continue to hope that the answer changes at some point in the future.

Ben · January 2019

So, the answer to my question is really "No, the Secret Key cannot be regenerated by any of the native clients – only the web client can do it."

That is correct -- at the moment changing the Secret Key requires the use of the web client.

Ben

AGAlumB · January 2019

@gedankenexperimenter: Ah, my mistake. I did get mixed up about the wording. Sorry about that. Indeed, while the Secret Key can be changed, that is only possible within the web interface currently. :blush:

1pwuser31547 · September 2019

@gedankenexperimenter : “I would much prefer a version of the web client that doesn't use the Secret Key for authentication, and doesn't decrypt the user data.

@jpgoldberg : I can see that. If the web client were only for the administrative panel, then it would never need to be give encryption keys.”

Great discussion!
Phishing/MITM attacks are definitely the most prevalent risks clients face.
Anything that encourages the use of native over web clients is best.
Hopefully one day the native client would be able to fulfill ALL the roles that at present solely are performed in the web client, such as adding/modifying 2FA, enable travel mode, etc.

I do know of one password manger (that I used before 1PW) who’s web interface functions solely an administrative role and doesn’t allow one to access cloud stored vaults through the web client.

gedankenexperimenter: you probably know this now but U2F is currently supported by 1 PW

Thanks for the discussion.
I love these forums. I learn so much from them.

AGAlumB · September 2019

Likewise, thanks for participating, and for the encouragement! Over time we're supporting more features that were once available only through he web interface in the native apps as well, and we'll continue to make more progress. Cheers! :)