Is the mobile app storing the credentials so the user can send them to an outside service? If the user checkmarked the box for "save my password", then
>requiring a password/PIN to unlock the stored credentials
defeats the purpose of a feature built to not require a user to remember a password. "Save my password" features are very common. I use that feature of Firefox all the time. I fully understand if someone gets access to my filesystem, then they get my passwords. (And they also get all the other important stuff on my filesystem like my photos and documents.)
> defeats the purpose of a feature built to not require a user to remember a password
And yet millions of people use password-protected password managers.
Including FireFox, which DOES encrypt your passwords, and which DOES allow you to optionally set a master password. And if you do set that password, it DOES use that password as an encryption key. And in that case, if someone gets physical access to your device, they'll need to install a keylogger or brute force your master password. Which requires a lot more effort than simply copying a file, providing more opportunities for the attacker to fail, for you to detect the attack, or for investigators to track the source of the attack.
And no, that won't save you if there's a critical security bug in your OS's kernel. Which there probably is. But that doesn't mean you give up on a sensible and easy to implement security policy.
The calculus is very clear here -- encrypting the passwords costs the developer and the user almost nothing (maybe 10 minutes to 2 hours of time for a competent developer; maybe a penny or two of electricity across the lifetime of the device). And there is a definite benefit to the overall security of the system -- the attacker needs to clear one more hurdle to get device passwords, and security-sensitive consumers can make that hurdle a rather large one (rooting the device and installing a keylogger).
No, it's not a silver bullet.
Yes, it is strictly more secure that the alternative.
> 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.
If the mobile app discussed is only used for logging into the router, then making it have an option to save the one password you use in it and encrypt it behind another different password would be pretty pointless.
>requiring a password/PIN to unlock the stored credentials
defeats the purpose of a feature built to not require a user to remember a password. "Save my password" features are very common. I use that feature of Firefox all the time. I fully understand if someone gets access to my filesystem, then they get my passwords. (And they also get all the other important stuff on my filesystem like my photos and documents.)