> they'll need to install a keylogger or brute force your master password
Not true, they can simply dump the RAM on your browser while your passwords are decrypted, which is probably the case when you run their malware anyways. It's a completely pointless half measure to encrypt those passwords. Worst case they have to patch it or hook it with something like Frida to do it next launch cycle. Keyloggers just ain't targetted and automated enough for me at least, but it's fairly trivial to just grab what you need from memory and run.
In fact according to this bug, the master password is stored in cleartext in RAM when your firefox is logged in so a simple string search on a memory dump could potentially do the job for someone without even the smallest RE capability:
If you have the RE capability to do one, it's not really any more than is required to do the other. It's not another hurdle. Just doing it at runtime instead of purely on disk.
> If you have the RE capability to do one, it's not really any more than is required to do the other. It's not another hurdle. Just doing it at runtime instead of purely on disk.
Phones/laptops are stolen. When they're stolen, they're turned off -- often by yanking a battery -- to prevent lockout/wipe/locating features. That wipes RAM. And after they're stolen, they're rarely returned for use.
Also, file system access doesn't imply access to a RAM dump. Especially on Android/iOS. And on a server, there are whole classes of vulnerabilities that provide RO access to certain files but can't be trivially exploited to provide access to a RAM dump.
So on many relevant platforms, I don't think it's true that access to portion of file system == access to RAM dump for particular process.
I agree that nearly all password storage mechanisms have serious problems, and that storing passwords is not ideal. However, if you're going to do it, then encrypting at rest is one small, extremely cheap security mechanism that does prevent out certain attacks.
I think maybe you're arguing that we shouldn't store passwords in app-specific password managers at all, which I don't necessarily disagree with. But I do disagree that encrypting at rest is "not another hurdle". For many attack profiles, it is.
No, it doesn't. If I have filesystem access in the sense you're talking I can just replace the application's executable with a malicious or modified one for example, which will allow me to steal your password still.
Correct me if I'm wrong here and there is some exploit class which might allow reading of but not writing to private application data and executables? I certainly haven't seen one and this would be the only scenario in which what you're saying has an impact.
As for the theft scenario - you could just as easily prevent the theft risk by setting a password on your device which would protect it at the platform level - where it should be. It'd also prevent other private data leaks which I'd say are higher risk than your router password which is useful only on your internal network, like your SMS messages, email accounts, authenticator tokens, etc. None of which I might add ask for passwords, dumping Google Authenticator tokens is as simple as running a SELECT on the sqlite database, they're not encrypted at all.
Not true, they can simply dump the RAM on your browser while your passwords are decrypted, which is probably the case when you run their malware anyways. It's a completely pointless half measure to encrypt those passwords. Worst case they have to patch it or hook it with something like Frida to do it next launch cycle. Keyloggers just ain't targetted and automated enough for me at least, but it's fairly trivial to just grab what you need from memory and run.
In fact according to this bug, the master password is stored in cleartext in RAM when your firefox is logged in so a simple string search on a memory dump could potentially do the job for someone without even the smallest RE capability:
https://bugzilla.mozilla.org/show_bug.cgi?id=539608
If you have the RE capability to do one, it's not really any more than is required to do the other. It's not another hurdle. Just doing it at runtime instead of purely on disk.