Correct me if I'm wrong, but isn't #4 just encouraging security through obscurity? If I hacked someone's phone, I can read those credentials, whether that amounts to reading them off the device, sniffing the connection, injecting code into an app, etc. Not encrypting the credentials on the device is not a security offense as it's not a valid security mechanism. Go ask Mozilla, Google and Microsoft about how well their encrypted credential stores work against freely available NirSoft tools or actual malware like iStealer.
> If I hacked someone's phone, I can read those credentials, whether that amounts to reading them off the device, sniffing the connection, injecting code into an app, etc.
Assuming attacker has root while the customer is logging in. But what if the attacker only has access to the file system (e.g. in the case of a stolen phone, or a broken jail/sandbox)? In that case, requiring a password/PIN to unlock the stored credentials does provide some protection to the user.
Storing passwords in the clear is always a terrible idea. If you must store credentials, at the very least they should be encrypted when at rest, and the system should require a sufficiently strong password/pattern/PIN to unlock the key chain. That way the attacker has to intercept and/or brute force, rather than merely gain access to, the device.
Ultimately, the answer is very simple: if you can't store credentials securely, then don't store them at all!
So you may be correct that DLink should not have stored those credentials at all. But just because there's no secure way to implement a convenience feature doesn't mean it's reasonable to go ahead and store passwords in the clear.
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.
> Assuming attacker has root while the customer is logging in. But what if the attacker only has access to the file system (e.g. in the case of a stolen phone, or a broken jail/sandbox)? In that case, requiring a password/PIN to unlock the stored credentials does provide some protection to the user.
Has such a case ever occurred? I can't think of one. Of course, if you have filesystem access you can replace the application on disk, patch it to steal the password easily.
> Ultimately, the answer is very simple: if you can't store credentials securely, then don't store them at all!
Many users want it anyways, and it's secure enough that unless you have remote attacks or the security level of Windows desktops with people downloading executables and running them constantly, it's unlikely to be an issue.
It's a trade-off, of course, but I don't think that means it's an unreasonable one to make.
Of course, you should probably go ahead and tell this to browser vendors. Script kiddies are running around selling accounts because of how they store passwords - encrypted, but in a total half measure way. Personally, I don't think it's reasonable to hold D-Link liable for a trade-off that even the biggest companies in tech make all the time. And one which is much more costly in those cases too!
There's just no secure way to do this on today's computers, we must rely on the security of the platform here. If storing passwords in this way is a problem, it's a platform security issue or a user issue, not an application issue.
TPMs have the potential to solve this, but at some scary costs which may adversely impact security in other ways, like preventing reverse engineering.
Yes, encrypting credentials is far from a silver bullet. Yes, much more work is needed on the platform side.
No, that doesn't make it OK to store credentials or other sensitive data in the clear.
> Has such a case ever occurred? I can't think of one.
Stolen encrypted drive/stolen drive with encrypted passwords on it? It's happened to me, personally (a usb key with my .password_store on it).
> Personally, I don't think it's reasonable to hold D-Link liable for a trade-off that even the biggest companies in tech make all the time.
First, I'm not aware of any tech giants who store passwords in the clear.
Second, just because the heavy weights do it doesn't make it reasonable.
> Of course, if you have filesystem access you can replace the application on disk, patch it to steal the password easily.
There are a lot of plausible scenarios in which an attacker gets RO/RW access to a portion of a file system but doesn't have the root or the capability to MITM/replace a binary.
> There's just no secure way to do this on today's computers
I think FTC's issue is this: "look, there's this really really simple thing that you could have done. Obviously it's not perfect, but doing this would have cost you basically nothing and would have at least made attacks a little bit harder. And even though it's basically free to implement and a very common practice, you didn't even bother."
Now, perhaps DLink had this discussion internally and decided that they agree with you. In that case, I'm sure those internal discussions will come out during the lawsuit, and a lay jury will have the difficult task of assessing some variant of the argument we're having here.
(Also, regardless of this one issue, shipping with default credentials w/o requiring a password change, and publishing a private key on a public website, are pretty egregious breaches of known best practice at time of sale. All while describing the device as "secure"...)
> First, I'm not aware of any tech giants who store passwords in the clear.
Mozilla, Microsoft and Google all effectively do this in their browsers. Don't believe me? Run the nirsoft webbrowserpassview. With just the files in your profile directory someone can dump your passwords. Sure, they're not "in the clear" but in practice it's just as bad if not worse. The number of accounts stolen with things like istealer is ridiculous. You can literally grab someone's entire lifetime of accounts in a fraction of a second.
I'd argue this isn't something a good developer would even attempt as it provides little more than a false sense of security to users. Good developers should be safe to absolutely refuse half measures like this as I do.
Modern Android/iOS devices have hardware-backed certificate storage, which (if used by an app) would prevent an attacker from getting access to private keys.
