4 ms·
We don't store the password in the DOM. When you choose to sign/encrypt, the password is passed to gpg (via the plugin) and promptly goes out of scope. (It mean
by mh_ 15y ago
We don't store the password in the DOM. When you choose to sign/encrypt, the password is passed to gpg (via the plugin) and promptly goes out of scope. (It means you have to enter your password every time you want to sign/encrypt, but this seems safer)
- pnathan 15y agoGoes...out of scope. I am suspicious that that's not really sufficient password protection. What protection do you have from an attack that provides access to your machine's address space? (or chrome's address space)? I'd like to see the source code before I use this. If that sounds paranoid, it's because if I'm using crypto, it's because I'm concerned about snoopers. --- edit - source got posted. Thanks!
- mh_ 15y ago-nod- an attack with full access to chromes address space would grab the password in memory. I'm guessing someone with that sort of threat model isn't using gmail for comms. (I guess even then, it could be useful to verify signatures (when gmail doesn't break the mail) without risking your private key)
- caf 15y agoCould you mitigate that by having a separate process to do the crypto, which the plugin talks to by IPC? The separate process is then the one that prompts for the password. This would also mean you don't have to reenter your password every time.
- msbarnett 15y agoYou're at zero right now because my finger slipped. Sorry about that.