4 ms·

What's the worst case? My understanding is that everything is encrypted at rest and in transit, therefore even if there's a breach, user passwords would be secu

by tikkun 3y ago

What's the worst case? My understanding is that everything is encrypted at rest and in transit, therefore even if there's a breach, user passwords would be secure.

ezfe 3y ago
Your understanding is correct, I believe that a compromised software update would have to be issued to skim passwords out of users databases.
- smileybarry 3y ago
  Essentially, yes. And that means duping a developer into adding your code somehow, since builds are digitally signed with a hardware token.
  - dzikimarian 3y ago
    Or supply chain attack
    - smileybarry 3y ago
      But that requires it to be present before the build is signed, ergo, early in the supply chain. Otherwise, the signature breaks and the build isn’t trusted for the rest of it.
zelon88 3y ago
When you have root access to the environment where the data is encrypted at rest, there is the possibility that you can exploit that environment to either reveal the encryption keys, learn valuable information about the encryption scheme, or directly decrypt the data through internal applications. For example, you have direct console access to a database, and when you view the data it is encrypted. But if you can steal the credentials of an administrator you may be able to login to an admin portal as an employee and make their SaaS decrypt it for you. Once you nail that down you script it with Bash + Curl and dump the database that way. Several hours later you have a freshly decrypted database to play with. Also, when you have root access to the environment where the data is encrypted in transit you can intercept one of the handshakess in the front or back-end to decrypt the data in transit. The idea is to impersonate both sides of the connection, then you can write your own certificates and create your own handshake. For example, maybe there is a web server and a caching server. The caching server sends data to a user outside the network with one certificate, and the web server sends data to the caching server with another certificate. If you perform a man-in-the-middle on the web server -> caching server, then you might be able to rewrite the encryption handshake, depending on the security configuration of the back-end. None of this would throw an error on the users browser.
- smileybarry 3y ago
  All of this is irrelevant for 1Password, as their architecture has an "account key" component & a "password" component combined to form the full key. 1Password SaaS never knows neither one. 1P SaaS is essentially a plain file host for a fully-encrypted database per-customer (technically per-vault so that different users can share vaults, and thus own keys to the same DB without sharing their own DB). This is also why I personally picked 1Password (and have used them for ~10 years) out of all options, because their original OPVault format (which I synced via Dropbox as a plain file host) and current SaaS format had these safeguards. Here's the whitepaper explaining this: https://1passwordstatic.com/files/security/1password-white-paper.pdf#Account%20password%20and%20Secret%20Key https://1passwordstatic.com/files/security/1password-white-p...
  - zelon88 3y ago
    I find the contents of that whitepaper to be interesting and full of valuable information for anyone looking to make a decision on such services. I do think that it would be technically possible to, eventually, abuse this system. The problem is, these "guarantees" create a misunderstood sense of security. They want you to believe this is "more" secure. But "more secure" than what? Competing cloud platforms, maybe. What if someone had access to 1Password's "vaults". They would only need to phish the user for two pieces of data; the 1Password password and the account key. Then, without ever having hacked your network, they gain all your passwords. So anyone with a back door into 1Password gets a trove of accounts that they can phish.
    - smileybarry 3y ago
      But that’s just a regular phishing attack, and borders on social engineering. It’s even a bit harder than classic phishing because you never input your account key other than at setup of the 1P app. Your key or password aren’t even sent to 1Password, ever. Logging in is done by computing and sending a cryptographic proof, and both sides validate each other through those cryptographic challenges. Again, a back door into 1P SaaS in this case is equivalent to a back door into any cloud storage service, e.g.: Google Drive, Dropbox, etc. > They would only need to phish the user for two pieces of data; the 1Password password and the account key I think there’s a misunderstanding here. You have an email, an alphanumeric account key and a password. There are 3 user details, effectively. Then, you can add 2FA, either via TOTP or FIDO2/Passkey. So a total of 3 factors: something you have (account key), something you know (password) and something else you have (a 2FA device).

by tikkun 3y ago

What's the worst case? My understanding is that everything is encrypted at rest and in transit, therefore even if there's a breach, user passwords would be secure.

ezfe 3y ago

Your understanding is correct, I believe that a compromised software update would have to be issued to skim passwords out of users databases.

smileybarry 3y ago
Essentially, yes. And that means duping a developer into adding your code somehow, since builds are digitally signed with a hardware token.
- dzikimarian 3y ago
  Or supply chain attack
  - smileybarry 3y ago
    But that requires it to be present before the build is signed, ergo, early in the supply chain. Otherwise, the signature breaks and the build isn’t trusted for the rest of it.

zelon88 3y ago

When you have root access to the environment where the data is encrypted at rest, there is the possibility that you can exploit that environment to either reveal the encryption keys, learn valuable information about the encryption scheme, or directly decrypt the data through internal applications. For example, you have direct console access to a database, and when you view the data it is encrypted. But if you can steal the credentials of an administrator you may be able to login to an admin portal as an employee and make their SaaS decrypt it for you. Once you nail that down you script it with Bash + Curl and dump the database that way. Several hours later you have a freshly decrypted database to play with. Also, when you have root access to the environment where the data is encrypted in transit you can intercept one of the handshakess in the front or back-end to decrypt the data in transit. The idea is to impersonate both sides of the connection, then you can write your own certificates and create your own handshake. For example, maybe there is a web server and a caching server. The caching server sends data to a user outside the network with one certificate, and the web server sends data to the caching server with another certificate. If you perform a man-in-the-middle on the web server -> caching server, then you might be able to rewrite the encryption handshake, depending on the security configuration of the back-end. None of this would throw an error on the users browser.

smileybarry 3y ago
All of this is irrelevant for 1Password, as their architecture has an "account key" component & a "password" component combined to form the full key. 1Password SaaS never knows neither one. 1P SaaS is essentially a plain file host for a fully-encrypted database per-customer (technically per-vault so that different users can share vaults, and thus own keys to the same DB without sharing their own DB). This is also why I personally picked 1Password (and have used them for ~10 years) out of all options, because their original OPVault format (which I synced via Dropbox as a plain file host) and current SaaS format had these safeguards. Here's the whitepaper explaining this: https://1passwordstatic.com/files/security/1password-white-paper.pdf#Account%20password%20and%20Secret%20Key https://1passwordstatic.com/files/security/1password-white-p...
- zelon88 3y ago
  I find the contents of that whitepaper to be interesting and full of valuable information for anyone looking to make a decision on such services. I do think that it would be technically possible to, eventually, abuse this system. The problem is, these "guarantees" create a misunderstood sense of security. They want you to believe this is "more" secure. But "more secure" than what? Competing cloud platforms, maybe. What if someone had access to 1Password's "vaults". They would only need to phish the user for two pieces of data; the 1Password password and the account key. Then, without ever having hacked your network, they gain all your passwords. So anyone with a back door into 1Password gets a trove of accounts that they can phish.
  - smileybarry 3y ago
    But that’s just a regular phishing attack, and borders on social engineering. It’s even a bit harder than classic phishing because you never input your account key other than at setup of the 1P app. Your key or password aren’t even sent to 1Password, ever. Logging in is done by computing and sending a cryptographic proof, and both sides validate each other through those cryptographic challenges. Again, a back door into 1P SaaS in this case is equivalent to a back door into any cloud storage service, e.g.: Google Drive, Dropbox, etc. > They would only need to phish the user for two pieces of data; the 1Password password and the account key I think there’s a misunderstanding here. You have an email, an alphanumeric account key and a password. There are 3 user details, effectively. Then, you can add 2FA, either via TOTP or FIDO2/Passkey. So a total of 3 factors: something you have (account key), something you know (password) and something else you have (a 2FA device).