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