How do you secure data on clients

Options
pjnagel
pjnagel
Community Member

One of our 1Password for Teams Macbook laptops has been stolen, and I'm investigating the security risk to our company.

Your "1Password
Security Design" whitepaper at https://1password.com/files/1Password for Teams White Paper.pdf says under "How We Secure Data on Clients": "This section of this document is not yet ready".

We suspended the account on the server side (for now).

However, since you claim to locally cache data for offline operation, we should assume that the team member's data can be exposed on the client side if the user's master password can be brute-force cracked, right?

How long does the client cache the data? If the client runs while there is network connectivity to the 1password server, does the client delete locally cached copies of the data in anticipation of syncing with the server, regardless of whether the master password is provided or not?


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

Comments

  • AGAlumB
    AGAlumB
    1Password Alumni
    Options

    @pjnagel: 1Password data is encrypted using the Master Password and Secret Key with 1Password.com accounts, so to decrypt the data at rest they would have to know and/or guess both. Suspending the account will not delete the cached data but revokes the encryption keys (which are encrypted using the Master Password and Secret Key); deleting the account does delete the cached encrypted data as well though — in both cases, provided the server can communicate with the client to give the order. As long as the user chose a long, strong, unique Master Password (and did not give it to the attacker), brute forcing it will be infeasible, even if they know the randomly-generated, 128-bit Secret Key. I hope this helps. Be sure to let me know if you have any other questions! :)

  • pjnagel
    pjnagel
    Community Member
    Options

    @brenty

    1Password data is encrypted using the Master Password and Secret Key with 1Password.com accounts

    But since the client has the secret key pre-filled in when you launch it, doesn't that mean that the secret key is stored on the client, and one should consider it known to the thief, and thus not secret?

  • pjnagel
    pjnagel
    Community Member
    Options

    To be more precise: only the web client has the secret key pre-filled.

    However, the Windows client does not require me to type the secret key, only the master password. So surely it must remember the secret key somewhere? If the thief knows the algorithms, the thief only needs the master password to decrypt whatever the client has cached offline?

  • AGAlumB
    AGAlumB
    1Password Alumni
    Options

    @pjnagel: Thanks! You didn't mention that. Correct. If they've stored the Secret Key locally so that they only have to enter their Master Password to unlock (or sign in in the browser) then yes, we should assume that has been compromised and regenerate it at https://my.1password.com/profile (under Manage).

  • The web clients do not cache data locally. Only the native apps do.

    Also, if you delete the device on 1Password.com then the native app will automatically delete local data when gets a chance to connect to the server.

  • pjnagel
    pjnagel
    Community Member
    Options

    @roustem

    Good to know, but out of an abundance of caution, I will assume a dedicated attacker would start up laptop without network, and thus prevent the client from deleting the local data.

    It all still boils down to "the master password is the last line of defense". The secret key provides additional protection, but only in certain scenarios.

  • AGAlumB
    AGAlumB
    1Password Alumni
    Options

    @pjnagel: Right. The Secret Key exists to protect against a very specific scenario: 1Password.com data being stolen, so that brute force attempts against individual users' Master Passwords cannot be made. It isn't meant to legitimize not using a long, strong, unique Master Password, or protect you against scenarios where someone has direct access your your device.

This discussion has been closed.