4 ms·

Can the title get changed? - E2E in this case is nebulous, this isn't a chat or email client, it isn't client <-> client with Google acting as an intermediary.

Can the title get changed? - E2E in this case is nebulous, this isn't a chat or email client, it isn't client <-> client with Google acting as an intermediary. It is between your Google account/Google's Server and Google's software. - It isn't clear if during transportation it is encrypted (e.g. HTTPS?); since seemingly this post isn't about that (or if it is the evidence or technical information is lacking). The term "E2EE" typically is referring to encryption from client <-> client through a blind intermediary, but again that doesn't describe the relationship here. The actual complaint SEEMS to be: > Google Authenticator backup isn't encrypted at rest on Google's Servers My big complaint is that this is a misuse of the term "E2E" (E2EE). It simply doesn't apply in this situation. That doesn't mean it isn't discussion worthy (e.g. not using HTTPS is a major red flag, and not encrypting at rest on Google's Servers is discussable). In general the linked post doesn't do a good job describing what they found and how they found it.

deleted 4y ago
[deleted]
jchw 4y ago
End-to-end is being used to mean encrypted on the client and decrypted on other clients. "Encrypted at rest" is overloaded, it's often used to refer to secrets stored encrypted by an HSM or something where the key is still accessible by whoever is storing the data; pretty common for compliance where the threat model being addressed is someone stealing a hard drive from a data center, but not very useful for when you want a secret to remain secret even to the server operator. This is pretty common use for the term E2EE as far as I can tell. That all of the "clients" for which the encryption would be end-to-end for are all run by the same user is not really a big deal; I've seen it used similarly for things like "end-to-end encrypted notes" and that sort of thing. Example: https://standardnotes.com/ https://standardnotes.com/
amarshall 4y ago
E2EE is a valid term. Just because both ends are controlled by the same person doesn’t make it not “client ↔ client”. Just because Google wrote the software and stores the backups does not mean that those backups should be readable to someone (e.g. Google servers) with access only to the backup. E2EE means that no one other then the end-users can see the data—in this case, that is just the one user. Neither transit encryption nor encryption at rest provide that. Encryption at rest is not really part of the discussion. There’s no way to verify client side that it is happening, and it does not prevent Google servers from seeing the plaintext backup. > In general the linked post doesn't do a good job describing what they found and how they found it Seemed pretty clear: they did MITM to bypass any transit encryption and saw the plaintext secrets being sent, and thus Google servers can see all the secrets.
choppaface 4y ago
there's really no reason google couldn't have implemented (as the article suggests) a prompt for a one-time password while the user initiates the credential transfer. and it's clear the transfer isn't completely protected. this is a sloppy product change.
shawnz 4y ago
> The actual complaint SEEMS to be: Google Authenticator backup isn't encrypted at rest on Google's Servers Encryption at rest would NOT solve the problem being described here. Even if the data was encrypted both in transit and at rest, that does not mean that Google is incapable of getting access to the data. The data needs to be encrypted from the moment it leaves the device until the moment it arrives back on the user's device again (e.g. client to client E2EE), which is a stronger criteria than encryption in transit and at rest.
- larsrc 4y ago
  The "not encrypted at rest" part seems to be pure speculation: "As shown in the screenshots, this means that Google can see the secrets, likely even while they’re stored on their servers." Is there some actual evidence for this claim that I'm not noticing?
  - shawnz 4y ago
    That sentence doesn't imply anything about whether they're encrypted at rest or not. Even if they were encrypted at rest (but not E2E encrypted), Google can just decrypt the secrets to see them. The problem here doesn't involve encryption at rest in any way and there's nothing being claimed about whether the secrets are encrypted at rest or not.

deleted 4y ago

[deleted]

jchw 4y ago

End-to-end is being used to mean encrypted on the client and decrypted on other clients. "Encrypted at rest" is overloaded, it's often used to refer to secrets stored encrypted by an HSM or something where the key is still accessible by whoever is storing the data; pretty common for compliance where the threat model being addressed is someone stealing a hard drive from a data center, but not very useful for when you want a secret to remain secret even to the server operator. This is pretty common use for the term E2EE as far as I can tell. That all of the "clients" for which the encryption would be end-to-end for are all run by the same user is not really a big deal; I've seen it used similarly for things like "end-to-end encrypted notes" and that sort of thing. Example: https://standardnotes.com/ https://standardnotes.com/

amarshall 4y ago

E2EE is a valid term. Just because both ends are controlled by the same person doesn’t make it not “client ↔ client”. Just because Google wrote the software and stores the backups does not mean that those backups should be readable to someone (e.g. Google servers) with access only to the backup. E2EE means that no one other then the end-users can see the data—in this case, that is just the one user. Neither transit encryption nor encryption at rest provide that. Encryption at rest is not really part of the discussion. There’s no way to verify client side that it is happening, and it does not prevent Google servers from seeing the plaintext backup. > In general the linked post doesn't do a good job describing what they found and how they found it Seemed pretty clear: they did MITM to bypass any transit encryption and saw the plaintext secrets being sent, and thus Google servers can see all the secrets.

choppaface 4y ago

there's really no reason google couldn't have implemented (as the article suggests) a prompt for a one-time password while the user initiates the credential transfer. and it's clear the transfer isn't completely protected. this is a sloppy product change.

shawnz 4y ago

> The actual complaint SEEMS to be: Google Authenticator backup isn't encrypted at rest on Google's Servers Encryption at rest would NOT solve the problem being described here. Even if the data was encrypted both in transit and at rest, that does not mean that Google is incapable of getting access to the data. The data needs to be encrypted from the moment it leaves the device until the moment it arrives back on the user's device again (e.g. client to client E2EE), which is a stronger criteria than encryption in transit and at rest.

larsrc 4y ago
The "not encrypted at rest" part seems to be pure speculation: "As shown in the screenshots, this means that Google can see the secrets, likely even while they’re stored on their servers." Is there some actual evidence for this claim that I'm not noticing?
- shawnz 4y ago
  That sentence doesn't imply anything about whether they're encrypted at rest or not. Even if they were encrypted at rest (but not E2E encrypted), Google can just decrypt the secrets to see them. The problem here doesn't involve encryption at rest in any way and there's nothing being claimed about whether the secrets are encrypted at rest or not.