Hacker News Reader

Comment by tikkun | Hacker News Reader

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.

View on HN

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.

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-p...

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.

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).

While the encryption might be solid, if you have a security issue in a sensitive area such as the build environment, you cannot have any confidence in the app.

I'm not saying that this is what happened here, just pointing out that there are other risks here which cannot be mitigated by strong encryption.

That extends to any and all applications. Nothing is stopping a local only Keepass installation from being exposed via a supply chain attack to start sending passwords to an attackers server. In fact, I trust 1Password's corporate infrastructure more than my own ability to lock down my personal devices.

I don't disagree. Just pointing out that "zero knowledge" isn't the cure for every security issue.

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

Essentially, yes. And that means duping a developer into adding your code somehow, since builds are digitally signed with a hardware token.

Or supply chain attack

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.

Reply on news.ycombinator.com