4 ms·

So I keep seeing it mentioned that AgileBits is not a target because the end user keeps the secret key locally. What mitigations do they have in place to avoid

by Grimm1 7y ago

So I keep seeing it mentioned that AgileBits is not a target because the end user keeps the secret key locally. What mitigations do they have in place to avoid the scenario where they're breached, all encrypted passwords are exfiltrated and then wiped from their servers and then during a sync it wipes from the local 1pw. Now as an attacker you just ransom them back to individual users who can decrypt the passwords with the local key. I'm hoping multiple offsite backups? I was considering switching from last pass so genuinely curious.

bwoodruff 7y ago
Hi Grimm1. Ben from 1Password here. I think this is a great question. I'd like to put you in touch with our security team who would be best positioned to answer this. Would you mind writing into support+security@1password.com ? Thanks!
AGKyle 7y ago
Disclosure: I work for 1Password on the security team. First, lets discuss what the Secret Key actually does. I'm going to simplify this greatly simply because I don't want to end up in the weeds here. But I think it's important to know what it does and why. When we designed 1Password's online service we knew that our servers would be a big target if it were storing a lot of user data. And we knew, that historically, users used terribly weak passwords. Knowing this we set out to find ways to protect against these issues. Lets compare to our standalone vaults since it's a comparison with only us and keeps things simple. Assuming an attacker gains access to your local vault they'd have to guess your Master Password. With 1Password membership accounts you have both a Master Password and the Secret Key. If someone were to gain access to our servers they'd have to guess both your Secret Key and Master Password together (they're combined together, again simplifying, see our white paper for the full technicals here). You can't just guess the Master Password and then the Secret Key or vice versa, you have to have both of them correct. Say a user uses a terribly weak Master Password, this would be relatively trivial to guess if someone had your encrypted data. Say our servers are compromised and you used a weak Master Password. The Secret Key (a 128-bit randomly generated key) is going to protect that data because even if the attacker could guess the weak Master Password, the addition of the Secret Key requires that they guess both together, making the weak Master Password not nearly as weak. For those using very strong Master Passwords, the Secret Key strengthens it even further. With the same idea in mind, breaching our servers to acquire the encrypted data means an attacker acquires nothing but encrypted data and requires guessing the Secret Key and Master Password for every account. This is a significant undertaking and effectively improbable using today's technology. Hopefully you now see the point of the Secret Key, it's to protect your data locally on our servers. You absolutely shouldn't use a weak Master Password, but the Secret Key protects those that potentially do. Now, to your other questions. We do have snapshots of the database made daily. We could restore to one of those. We are also working on (and have partially implemented) a local backup solution. The Mac client creates these backups already for users who are on our memberships (for individual and family accounts only). They are not (yet) documented nor is there a tool that can read them, but they are being made. The plan is to openly document how they're created so that anyone with the technical understanding could create their own tool for reading them. The reader part of it will come in the future, and likely part of our CLI application, though nothing is for certain at this point and subject to change. This will allow you to have your own backups and they'll be local to you in the event that something goes wrong on our servers. Hope that gives you some idea of how it all works. If I can answer any other questions, feel free to write in to support+security@1password.com and mention me (Kyle) and this thread (ideally a link to your question so I have context and won't feel like I have to repeat in case I forget what I may have said) Kyle 1Password
- Grimm1 7y ago
  Hey, I am really sorry I didn't see this earlier I have a bad habit of browsing not signed in so I rarely see replies to my comments. I think this was a great answer to my question and I really appreciate you taking the time to write up your explanation for me.

by Grimm1 7y ago

bwoodruff 7y ago

Hi Grimm1. Ben from 1Password here. I think this is a great question. I'd like to put you in touch with our security team who would be best positioned to answer this. Would you mind writing into support+security@1password.com ? Thanks!

AGKyle 7y ago

Disclosure: I work for 1Password on the security team. First, lets discuss what the Secret Key actually does. I'm going to simplify this greatly simply because I don't want to end up in the weeds here. But I think it's important to know what it does and why. When we designed 1Password's online service we knew that our servers would be a big target if it were storing a lot of user data. And we knew, that historically, users used terribly weak passwords. Knowing this we set out to find ways to protect against these issues. Lets compare to our standalone vaults since it's a comparison with only us and keeps things simple. Assuming an attacker gains access to your local vault they'd have to guess your Master Password. With 1Password membership accounts you have both a Master Password and the Secret Key. If someone were to gain access to our servers they'd have to guess both your Secret Key and Master Password together (they're combined together, again simplifying, see our white paper for the full technicals here). You can't just guess the Master Password and then the Secret Key or vice versa, you have to have both of them correct. Say a user uses a terribly weak Master Password, this would be relatively trivial to guess if someone had your encrypted data. Say our servers are compromised and you used a weak Master Password. The Secret Key (a 128-bit randomly generated key) is going to protect that data because even if the attacker could guess the weak Master Password, the addition of the Secret Key requires that they guess both together, making the weak Master Password not nearly as weak. For those using very strong Master Passwords, the Secret Key strengthens it even further. With the same idea in mind, breaching our servers to acquire the encrypted data means an attacker acquires nothing but encrypted data and requires guessing the Secret Key and Master Password for every account. This is a significant undertaking and effectively improbable using today's technology. Hopefully you now see the point of the Secret Key, it's to protect your data locally on our servers. You absolutely shouldn't use a weak Master Password, but the Secret Key protects those that potentially do. Now, to your other questions. We do have snapshots of the database made daily. We could restore to one of those. We are also working on (and have partially implemented) a local backup solution. The Mac client creates these backups already for users who are on our memberships (for individual and family accounts only). They are not (yet) documented nor is there a tool that can read them, but they are being made. The plan is to openly document how they're created so that anyone with the technical understanding could create their own tool for reading them. The reader part of it will come in the future, and likely part of our CLI application, though nothing is for certain at this point and subject to change. This will allow you to have your own backups and they'll be local to you in the event that something goes wrong on our servers. Hope that gives you some idea of how it all works. If I can answer any other questions, feel free to write in to support+security@1password.com and mention me (Kyle) and this thread (ideally a link to your question so I have context and won't feel like I have to repeat in case I forget what I may have said) Kyle 1Password

Grimm1 7y ago
Hey, I am really sorry I didn't see this earlier I have a bad habit of browsing not signed in so I rarely see replies to my comments. I think this was a great answer to my question and I really appreciate you taking the time to write up your explanation for me.