3 ms·

> 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

> 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.

problems 10y ago
> does prevent out certain attacks. 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.

problems 10y ago

> does prevent out certain attacks. 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.