6 ms·

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 amoun

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.

throwaway729 10y ago
> 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.
- problems 10y ago
  > 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.
  - throwaway729 10y ago
    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"...)
    - problems 10y ago
      > 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.
- AgentME 10y ago
  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.)
  - throwaway729 10y ago
    > 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.
    - AgentME 10y ago
      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.
tjohns 10y ago
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.

throwaway729 10y ago

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

problems 10y ago
> 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.
- throwaway729 10y ago
  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"...)
  - problems 10y ago
    > 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.
AgentME 10y ago
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.)
- throwaway729 10y ago
  > 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.
  - AgentME 10y ago
    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.

tjohns 10y ago

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.