(no title)
solenoid0937 | 29 days ago
The PIN interface is also an HSM on the backend. The HSM performs the rate limiting. So they'd need a backdoor'd HSM.
solenoid0937 | 29 days ago
The PIN interface is also an HSM on the backend. The HSM performs the rate limiting. So they'd need a backdoor'd HSM.
barbazoo|29 days ago
solenoid0937|29 days ago
However, most users can't be bothered to choose such a PIN. In this case they choose a 4 or 6 digit pin.
To mitigate the risk of brute force, the PIN is rate limited by an HSM. The HSM, if it works correctly, should delete the encryption key if too many attempts are used.
Now sure, Meta could insert itself between the client and HSM and MITM to extract the PIN.
But this isn't a Meta specific gap, it's the problem with any E2EE system that doesn't require users to memorize a master password.
I helped design E2EE systems for a big tech company and the unsatisfying answer is that there is no such thing as "user friendly" E2EE. The company can always modify the client, or insert themselves in the key discovery process, etc. There are solutions to this (decentralized app stores and open source protocols, public key servers) but none usable by the average person.
basch|29 days ago
Every time you sign in to the web interface or resign into the app you enter it. I don’t remember an option for an alphanumeric pin or to offload it to a third party.
solenoid0937|29 days ago
The Messenger PIN is rate limited by an HSM, you merely enter it through the web interface.
Of course, the HSM could be backdoored or the client could exfil the secret but the latter would be easy to discover.
Harder to do any better here without making the user memorize a master password, which tends to fail miserably in real life.