8 ms·

You're wrong about LinkedIn, it's not the users, it's you

24 points by cpt1138 14y ago

gdp 14y ago
Makes a fairly interesting point that seems obvious once you've read it, but which we actually don't have embedded as an assumption - that the level of user trust placed in us as developers is not matched by the level of care and responsibility which we actually feel when that trust is placed in us. Definitely some food for thought, and I think we need to take the entire issue much more seriously rather than just slapping anything together and forgetting about it.
- huggyface 14y ago
  What is the interesting point? That users should place a foolhardy, ridiculous level of trust in developers and processes that they don't know and have no insight into?
  - deelowe 14y ago
    I don't know what it takes to build a lot of things, but I trust that the engineers will do a good job. I see no difference with software. I've always found it odd that SWEs can harbor this type of opinion. That is, "it's the user's fault for trusting me/us." when every other engineering discipline would consider such a stance insane. All other disciplines would place responsibility directly on the engineering team. Whether a plane falls out of sky, a car explodes when rear ended, a bridge collapses, a chemical causes cancer, or an oven electrocutes the user, in all cases we'd point the finger at the engineers (or company that performed said engineering) and demand an explanation. I see no difference here. Full disclosure: This is coming from someone who was originally studying to be a ChemE before switching to comp-sci.
    - bwanab 14y ago
      It might be interesting to point out that in all the examples you give there exist strong regulatory requirements. Are you (we, collectively) saying that regulations and government oversight should be on the table for web sites that provide services requiring a certain level of security?
      - deelowe 14y ago
        The regulatory compliance varies from state to state. For example, ChemE doesn't require a PE in most (all?) states. Typically, regulatory compliance is only required when the work involves some sort of interstate commerce. With all the leaks and concerns over privacy lately, I think we'll see some sort expansion of the laws covering PII sooner than later. So wether or not I agree with it, I think this will happen.
    - huggyface 14y ago
      That is, "it's the user's fault for trusting me/us." No, it's the user's fault for trusting any given site more than necessary. People outraged that LinkedIn leaked the same credentials that they use for PayPal, for instance. That is ABSOLUTELY a user issue. LinkedIn, and many before, screwed up. People aren't upset as much about the root screwup though (I mean just reset your password and move on), but that, yet again, it reveals that people rashly and irresponsibly reuse credentials en masse. Your analogies -- if we accept that software should be built like a bridge (which is ridiculous) -- is misplaced. LinkedIn, like a bridge, should be built well to the limits of its purpose. If a bridge has a defect, however, it shouldn't cause my house to fall down as a consequence.
smoyer 14y ago
I agree with the article's premise, but the user does need to be educated about the risks at the same time. We can enforce some degree of password strength, but we can't keep the user from reusing the same password. If we could guarantee that their password would never be exposed, that would be fine but I'm never going to make that guarantee. I can be diligent and yet one mistake can still expose the user's (hopefully salted and hashed) password. If there is a financial impetus for someone to find my mistake, they will spend the time looking. As a side note, I'd love to hear how the hackers came to be in possession of 6.5MM LinkedIn passwords ... what mistake was made that allowed them to collect unsalted hashes in the first place?
- cpt1138 14y ago
  I keep hearing about these mysterious hackers. My gut feeling is that with these really big ones that we hear about, its more likely to be some kind of insider threat that they will do everything they can to hide. Blaming "them" with no details at all, seems really sketchy to me.
- dpark 14y ago
  > we can't keep the user from reusing the same password Neither can the user. Users cannot remember a unique password for every site they visit. That's just not realistic. The simple fact is that unique-password-per-site does not scale. Password managers don't work well, either, because they can't be integrated into the common mobile browsers, and they frankly just require too much user intervention. (Sure, I'll install this plugin on every machine I use, plus the gimpy custom browser for my phone and tablet, and I'll use the app to cut/paste into other apps that need auth...) We really need to big players to get together and build a system that works, and for them to all implement it properly and push 3rd parties to use it. BrowserID seems promising, but I haven't heard of any other big players signing on to implement and support it.
  - smoyer 14y ago
    Jeff Atwood has made the same claim and it's his rationale for using OpenID on the StackExchange sites. I don't disagree, but most users won't figure out how to use OpenID. FB login is widely known but it's not at all side-effect free.
16s 14y ago
The point about insiders is often overlooked but just as plausible as an outright hack. A rogue sys-admin or coder who is trusted and has access to file-systems and DBs can leak or sell data and might even get away with it without ever being caught.
- alainbryden 14y ago
  I imagine there's all sorts of motivation for this too. A dishonest security admin or consultant for LinkedIn might have had no traction in convincing managers that they should pay him to upgrade the security system. I can see rogue programmers contriving leaks like this just to give themselves more work.
- deleted 14y ago
  [deleted]
Paul_S 14y ago
Solution: delegate authentication to experts - use OpenID.
mhellmic 14y ago
I would like to disagree on that: "It's not really about MD5, SHA1 or BCrypt, (...) It wouldn't matter if the passwords were all in plaintext if they never got out." It is also about the hashes, because a good security infrastructure should anticipate the possibility of a leak and still protect the users. For that, you need to use the right encryption so that users don't have to change their passwords in the next days, but have 5+ years for that. And yes, I see that you are promoting dedicated authentication services (which would do it right), it just looks strange to me there.
- cpt1138 14y ago
  You're absolutely right, what I meant is that its not just about using the right algorithms and making sure they are implemented and used correctly. It's also a whole host of other things including avoiding SQL injection, CSRF, XSS, data leakage in logs, proper access and provisioning, following and reacting to the constant stream of security alerts (case in point: the MySQL Ubuntu issue that cropped up yesterday).
hello_asdf 14y ago
The trick that I've found works is to use a password that I can remember on sites like Facebook. It's the only site I'm likely to log into on my phone. GMail should be a random password though, but it can be stored on your phone so you don't need to remember it. Everything else that doesn't require mobile access use a random password managed through a program like LastPass. If you're thinking about logging in to sites like your email from a public computer or something, well you shouldn't do that anyway.

24 points by cpt1138 14y ago

gdp 14y ago

Makes a fairly interesting point that seems obvious once you've read it, but which we actually don't have embedded as an assumption - that the level of user trust placed in us as developers is not matched by the level of care and responsibility which we actually feel when that trust is placed in us. Definitely some food for thought, and I think we need to take the entire issue much more seriously rather than just slapping anything together and forgetting about it.

huggyface 14y ago
What is the interesting point? That users should place a foolhardy, ridiculous level of trust in developers and processes that they don't know and have no insight into?
- deelowe 14y ago
  I don't know what it takes to build a lot of things, but I trust that the engineers will do a good job. I see no difference with software. I've always found it odd that SWEs can harbor this type of opinion. That is, "it's the user's fault for trusting me/us." when every other engineering discipline would consider such a stance insane. All other disciplines would place responsibility directly on the engineering team. Whether a plane falls out of sky, a car explodes when rear ended, a bridge collapses, a chemical causes cancer, or an oven electrocutes the user, in all cases we'd point the finger at the engineers (or company that performed said engineering) and demand an explanation. I see no difference here. Full disclosure: This is coming from someone who was originally studying to be a ChemE before switching to comp-sci.
  - bwanab 14y ago
    It might be interesting to point out that in all the examples you give there exist strong regulatory requirements. Are you (we, collectively) saying that regulations and government oversight should be on the table for web sites that provide services requiring a certain level of security?
    - deelowe 14y ago
      The regulatory compliance varies from state to state. For example, ChemE doesn't require a PE in most (all?) states. Typically, regulatory compliance is only required when the work involves some sort of interstate commerce. With all the leaks and concerns over privacy lately, I think we'll see some sort expansion of the laws covering PII sooner than later. So wether or not I agree with it, I think this will happen.
  - huggyface 14y ago
    That is, "it's the user's fault for trusting me/us." No, it's the user's fault for trusting any given site more than necessary. People outraged that LinkedIn leaked the same credentials that they use for PayPal, for instance. That is ABSOLUTELY a user issue. LinkedIn, and many before, screwed up. People aren't upset as much about the root screwup though (I mean just reset your password and move on), but that, yet again, it reveals that people rashly and irresponsibly reuse credentials en masse. Your analogies -- if we accept that software should be built like a bridge (which is ridiculous) -- is misplaced. LinkedIn, like a bridge, should be built well to the limits of its purpose. If a bridge has a defect, however, it shouldn't cause my house to fall down as a consequence.

smoyer 14y ago

I agree with the article's premise, but the user does need to be educated about the risks at the same time. We can enforce some degree of password strength, but we can't keep the user from reusing the same password. If we could guarantee that their password would never be exposed, that would be fine but I'm never going to make that guarantee. I can be diligent and yet one mistake can still expose the user's (hopefully salted and hashed) password. If there is a financial impetus for someone to find my mistake, they will spend the time looking. As a side note, I'd love to hear how the hackers came to be in possession of 6.5MM LinkedIn passwords ... what mistake was made that allowed them to collect unsalted hashes in the first place?

cpt1138 14y ago
I keep hearing about these mysterious hackers. My gut feeling is that with these really big ones that we hear about, its more likely to be some kind of insider threat that they will do everything they can to hide. Blaming "them" with no details at all, seems really sketchy to me.
dpark 14y ago
> we can't keep the user from reusing the same password Neither can the user. Users cannot remember a unique password for every site they visit. That's just not realistic. The simple fact is that unique-password-per-site does not scale. Password managers don't work well, either, because they can't be integrated into the common mobile browsers, and they frankly just require too much user intervention. (Sure, I'll install this plugin on every machine I use, plus the gimpy custom browser for my phone and tablet, and I'll use the app to cut/paste into other apps that need auth...) We really need to big players to get together and build a system that works, and for them to all implement it properly and push 3rd parties to use it. BrowserID seems promising, but I haven't heard of any other big players signing on to implement and support it.
- smoyer 14y ago
  Jeff Atwood has made the same claim and it's his rationale for using OpenID on the StackExchange sites. I don't disagree, but most users won't figure out how to use OpenID. FB login is widely known but it's not at all side-effect free.

16s 14y ago

The point about insiders is often overlooked but just as plausible as an outright hack. A rogue sys-admin or coder who is trusted and has access to file-systems and DBs can leak or sell data and might even get away with it without ever being caught.

alainbryden 14y ago
I imagine there's all sorts of motivation for this too. A dishonest security admin or consultant for LinkedIn might have had no traction in convincing managers that they should pay him to upgrade the security system. I can see rogue programmers contriving leaks like this just to give themselves more work.
deleted 14y ago
[deleted]

Paul_S 14y ago

Solution: delegate authentication to experts - use OpenID.

mhellmic 14y ago

I would like to disagree on that: "It's not really about MD5, SHA1 or BCrypt, (...) It wouldn't matter if the passwords were all in plaintext if they never got out." It is also about the hashes, because a good security infrastructure should anticipate the possibility of a leak and still protect the users. For that, you need to use the right encryption so that users don't have to change their passwords in the next days, but have 5+ years for that. And yes, I see that you are promoting dedicated authentication services (which would do it right), it just looks strange to me there.

cpt1138 14y ago
You're absolutely right, what I meant is that its not just about using the right algorithms and making sure they are implemented and used correctly. It's also a whole host of other things including avoiding SQL injection, CSRF, XSS, data leakage in logs, proper access and provisioning, following and reacting to the constant stream of security alerts (case in point: the MySQL Ubuntu issue that cropped up yesterday).

hello_asdf 14y ago

The trick that I've found works is to use a password that I can remember on sites like Facebook. It's the only site I'm likely to log into on my phone. GMail should be a random password though, but it can be stored on your phone so you don't need to remember it. Everything else that doesn't require mobile access use a random password managed through a program like LastPass. If you're thinking about logging in to sites like your email from a public computer or something, well you shouldn't do that anyway.