Security Questions
I am considering switching to 1Password and have some concerns on the security. I understand that you use the master password to encrypt a secret key that is generated on the device. You have stated on the forum that this is not sent to your servers at any time. However I see that on the login page, you ask for the secret key and the master password. Can you explain how this is handled exactly?
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Hi @random483 - You're right! With a 1Password membership we take securing your data to the next level. Your Secret Key is used to encrypt your data in conjunction with your Master Password. Both keys are needed in order to decrypt your data. By design, we don't store Secret Keys or Master Passwords since it would compromise the security of our users. We don't want anyone to have access to the keys to your account, including us, therefore we can't reset this if lost or forgotten.
Our security is very open to make sure everyone knows what we're doing behind the scenes, we wrote a White Paper and published it on our website.
There are three umbrellas of security with a 1Password membership. Before all of them is your Master Password and Secret Key. In the standalone version of 1Password, everything is protected by your Master Password and all the security wizardry in the app. But with a 1Password membership, the Secret Key is used to strengthen things even further. If you have a weak password, it's very unlikely someone will be able to access your data because the Secret Key is a 128-bit string of characters that's generated locally when you set up your account. It never leaves your device, and we ask that you print it out to have a copy in case you need it later — you're probably not going to remember the whole thing. :wink:
It’s great to have a Master Password and Secret Key protect your data, but they also need to communicate with the server to access your data, so we use three layers to protect things at rest and in transit. The first layer is based on your Master Password and Secret Key, which are used to derive a secret that is used to securely encrypt all of your data, both at rest and in transit between your devices and our servers. The second layer is based on the Secure Remote Password protocol. It allows your devices and our servers to make sure they are who they say they are. This provides an additional layer of protection against attack. The third and final layer is the standard TLS/SSL protocol. This layer provides a final layer of encryption and also allows your web browser to indicate that you were communicating directly with a 1Password web server. If you'd like to learn more about the security of 1Password, head to https://1password.com/security
0 -
That's great and all, but you didn't answer my question. On the login page you ask for the secret key and the master password. Are they transmitted to your servers via the web page?
0 -
Hi @random483 - You're right, sorry about that... Both your Secret Key and Master Password are NOT transmitted to our severs. The modern approach to covering most of the security properties of au- thentication we seek is to find a way for the client and the server to prove to each other that they each posses the appropriate secret without ei- ther of them revealing any secrets in the process. This is done by using a password-authenticated key exchange (PAKE). The best answer to your question can be found on page 8 of the White Paper we published if you want to read a bit further. I hope this helped a bit more :+1:
0 -
Page 8 doesn't cover PAKE, but page 26 and 27 (barely) explain your use of JSBN to do the calculations on the browser. I think you need to use less humour and trivialisation of the process in your replies. To me, it makes me doubt the implementation.
0 -
Hi @random483
Frank asked me to jump in here as I'm a member of our security team here at AgileBits.
I had quoted the PAKE example to Frank but previously in our conversation pointed him to page 8, so the page number differences were likely a result of me referencing two separate things on different pages. That's my fault for not being clear in my discussion with Frank.
I'm not entirely sure I understand what you're looking for here so I don't want go down a rabbit hole of detail when it could be wrong. Instead, I'll try to give a larger 1000 foot view, and if you have more specific questions please ask them.
The simplest answer is that no, we do not send your Master Password or Secret Key to the server. Full stop. The webpage is not a traditional webpage, it doesn't log you in by sending that login information to the server where the server validates the data sent. It's a web app that runs locally in the browser. The browser downloads this web app when you visit the page. When you sign in, it does a variety of transformations on your Master Password and Secret Key and uses SRP (Secure Remote Password) to authenticate. See page 13 of the White paper, entitled A Modern Approach to Authentication for details on how the authentication works.
The White Paper also has a section called A deeper look at keys, which shows how the authentication key is derived for use with authenticating via SRP. There's some discussion in the section just below that for initial sign up that might be relevant.
Finally, there's an appendices section and section B talks specifically about SRP.
SRP is used to authenticate and provide another level of encryption between the server and the client, but your data is still encrypted using other keys, all of those keys are outlined specifically in the section titled A deeper look at keys.
You'll notice that all of these keys are derived from the Secret Key and Master Password.
The white paper covers all of the details (for the most part) in how authentication, key creation, key derivation, and all the other bells and whistles of how this works. I'd highly encourage you to read the entirety of the white paper. Mostly because you seem skeptical of what we say. But perhaps a better understanding of the whole system will help you see how everything is handled and related to the Secret Key and Master Password.
None of this inherently proves that we aren't sending your Secret Key or Master Password to the server, but this can be independently verified if you were to want to dig into it.
Let me know if you have any other questions though. We're happy to help you get the answers you need.
Edit: Oh, and the Secret Key is stored in the browsers local storage. Choosing the option that it's a public computer will prevent the browser from storing the Secret Key. It's not stored in a cookie or anything like that. Our web client can operate with cookies disabled as well.
0 -
I've read the paper, and am satisfied. This is the best answer in the forum I've seen, and you should answer in this detail. Security is not difficult, and doesn't need a jokey tone. If someone doesn't understand, they'll ask, but using the term "magic" in a security document - or in the forums - does a disservice to the software you write. Just IMHO.
0 -
One word of warning to readers - and to your credit you mention it in the security document, albeit in passing - that if you use the web page to enter your security key, it will be stored in local storage in the clear, accessible should your browser be susceptible to attack.
0 -
Hi @random483
Security was explained to me as saying what you do and doing what you say. I think it's fairly apt.
I'm glad you've gotten the answers you need though. We're working on trying to make it so people can become less reliant on the web client, and also find ways to make sure the web client can be validated better to keep our users more secure. Hopefully our users will have some nice improvements to these in the future.
If you have any other questions though please don't hesitate to reach out.
0 -
(Figured it out)
0 -
:+1: :)
Ben
0
