6 ms·

"This has happened to basically every large web app company." That is a seriously sad reflection on the poor quality of the software cranked out today. Someon

"This has happened to basically every large web app company." That is a seriously sad reflection on the poor quality of the software cranked out today. Someone should be losing their job.

icedchai 7y ago
Sure, people should lose their job because someone's diagnosing a network problem, happens to run tcpdump on a server behind a TLS-terminating load balancer, and sees username/passwords. /s This literally happens all the time.
- redleggedfrog 7y ago
  Depends, how did they get to the server (secure jumpbox)? Did anyone know it'd be a security related event when they were diagnosing the problem? Did the tech take precautions? In such a case, I don't think robinhood.com would need to notify users. They tcpdump would be handled securely, scrubbed properly, troubleshooting done, and that'd be the end of it. If that isn't what happened, someone should be losing their job. The minute you think diagnosing network problems is a reason to ignore security to a degree that your users need to be notified you're incompetent.
  - icedchai 7y ago
    If they used the info to hack accounts or other malicious activity, then yes, they should lose their job. If they just left a log or capture file around somewhere, nope. Everyone makes mistakes.
    - redleggedfrog 7y ago
      "If they just left a log or capture file around somewhere, nope. Everyone makes mistakes." I guess that's where you and I differ. There are certain mistakes that are tolerable. But ones that result in mass emailing to your clients that they need to change their passwords are not. I'd never heard of robinhood.com before, but now I have, and my impression is I'd never trust them because they have staff that makes mistakes with my secure information. Think of how robinhood.com's employees feel about this. Management, and the people who are now watching the fallout rob the company of revenue. Telling me that the person who made that mistake is gone might make me think differently. The minute you start taking users name and passwords you're in the big boy world and need to treat it as such. Mistakes can be fatal, not just for your job, but your company.
      - icedchai 7y ago
        I appreciate their transparency. It should make you trust them more because they're letting you know about the problem. Some organizations would simply ignore this and move on. You'd never know it even happened.
        redleggedfrog 7y ago
        I'll admit, that's a good point that made me go, "Hmmm."
      - Buge 7y ago
        Are you aware that Github, Twitter, and Facebook also logged passwords? https://www.zdnet.com/article/github-says-bug-exposed-account-passwords/ https://www.zdnet.com/article/github-says-bug-exposed-accoun... https://arstechnica.com/information-technology/2018/05/twitter-advises-users-to-reset-passwords-after-bug-posts-passwords-to-internal-log/ https://arstechnica.com/information-technology/2018/05/twitt... https://www.theverge.com/2019/3/21/18275837/facebook-plain-text-password-storage-hundreds-millions-users https://www.theverge.com/2019/3/21/18275837/facebook-plain-t...
        redleggedfrog 7y ago
        You're proving my point. It's not taken seriously enough, even by huge companies with lots of resources.
      - devinjflick 7y ago
        Blameless post-mortems are a thing for a reason. Honesty about mistakes should make you trust an individual/company more not less. Just my 2 c
  - deleted 7y ago
    [deleted]
- namibj 7y ago
  Since we now put the user-id first, before the form goes to check how to even try to auth said user, we can just fetch a strong random salt from the server in it's response "just use a simple password, this is not a fancy account". Some nice, salted PBKDF shouldn't be a problem then. Also, there are zero-knowledge authentication systems, but they are somewhat iterative due to their probabilistic nature. They are secure in the face of an imposter authentication service, as the password (or a hash, obviously) has to be stored in the real authentication service. But it is never transmitted after this initial store, so no amount of logging or posing as an evil imposter risks disclosure.
fivre 7y ago
After having the risks explained to them and having received our professional recommendation that they add application-specific logging that had no means of accidentally logging PII, one of our customers (a major bank) still insisted that we implement full HTTP body logging in a proxy. Nobody is going to lose their job over this because the practical consequences are that you have to send out an "our bad" email and offer a credit protection voucher that most customers won't actually use. There are no costs.
- ben_w 7y ago
  You’re both correct: someone “should” lose their job, but nobody will. Not that that someone is necessarily the person who actually turned on this logging, it could be their supervisor who let it go live, or QA or… wherever the buck stops.

"This has happened to basically every large web app company." That is a seriously sad reflection on the poor quality of the software cranked out today. Someone should be losing their job.

icedchai 7y ago

Sure, people should lose their job because someone's diagnosing a network problem, happens to run tcpdump on a server behind a TLS-terminating load balancer, and sees username/passwords. /s This literally happens all the time.

redleggedfrog 7y ago
Depends, how did they get to the server (secure jumpbox)? Did anyone know it'd be a security related event when they were diagnosing the problem? Did the tech take precautions? In such a case, I don't think robinhood.com would need to notify users. They tcpdump would be handled securely, scrubbed properly, troubleshooting done, and that'd be the end of it. If that isn't what happened, someone should be losing their job. The minute you think diagnosing network problems is a reason to ignore security to a degree that your users need to be notified you're incompetent.
- icedchai 7y ago
  If they used the info to hack accounts or other malicious activity, then yes, they should lose their job. If they just left a log or capture file around somewhere, nope. Everyone makes mistakes.
  - redleggedfrog 7y ago
    "If they just left a log or capture file around somewhere, nope. Everyone makes mistakes." I guess that's where you and I differ. There are certain mistakes that are tolerable. But ones that result in mass emailing to your clients that they need to change their passwords are not. I'd never heard of robinhood.com before, but now I have, and my impression is I'd never trust them because they have staff that makes mistakes with my secure information. Think of how robinhood.com's employees feel about this. Management, and the people who are now watching the fallout rob the company of revenue. Telling me that the person who made that mistake is gone might make me think differently. The minute you start taking users name and passwords you're in the big boy world and need to treat it as such. Mistakes can be fatal, not just for your job, but your company.
    - icedchai 7y ago
      I appreciate their transparency. It should make you trust them more because they're letting you know about the problem. Some organizations would simply ignore this and move on. You'd never know it even happened.
      - redleggedfrog 7y ago
        I'll admit, that's a good point that made me go, "Hmmm."
    - Buge 7y ago
      Are you aware that Github, Twitter, and Facebook also logged passwords? https://www.zdnet.com/article/github-says-bug-exposed-account-passwords/ https://www.zdnet.com/article/github-says-bug-exposed-accoun... https://arstechnica.com/information-technology/2018/05/twitter-advises-users-to-reset-passwords-after-bug-posts-passwords-to-internal-log/ https://arstechnica.com/information-technology/2018/05/twitt... https://www.theverge.com/2019/3/21/18275837/facebook-plain-text-password-storage-hundreds-millions-users https://www.theverge.com/2019/3/21/18275837/facebook-plain-t...
      - redleggedfrog 7y ago
        You're proving my point. It's not taken seriously enough, even by huge companies with lots of resources.
    - devinjflick 7y ago
      Blameless post-mortems are a thing for a reason. Honesty about mistakes should make you trust an individual/company more not less. Just my 2 c
- deleted 7y ago
  [deleted]
namibj 7y ago
Since we now put the user-id first, before the form goes to check how to even try to auth said user, we can just fetch a strong random salt from the server in it's response "just use a simple password, this is not a fancy account". Some nice, salted PBKDF shouldn't be a problem then. Also, there are zero-knowledge authentication systems, but they are somewhat iterative due to their probabilistic nature. They are secure in the face of an imposter authentication service, as the password (or a hash, obviously) has to be stored in the real authentication service. But it is never transmitted after this initial store, so no amount of logging or posing as an evil imposter risks disclosure.

fivre 7y ago

After having the risks explained to them and having received our professional recommendation that they add application-specific logging that had no means of accidentally logging PII, one of our customers (a major bank) still insisted that we implement full HTTP body logging in a proxy. Nobody is going to lose their job over this because the practical consequences are that you have to send out an "our bad" email and offer a credit protection voucher that most customers won't actually use. There are no costs.

ben_w 7y ago
You’re both correct: someone “should” lose their job, but nobody will. Not that that someone is necessarily the person who actually turned on this logging, it could be their supervisor who let it go live, or QA or… wherever the buck stops.