5 ms·

> The biggest customer threw a gigantic hysterical fit and practically demanded to return the old root password which they knew. We just shrugged and complied.

> The biggest customer threw a gigantic hysterical fit and practically demanded to return the old root password which they knew. We just shrugged and complied. It's not like it will be ours network which can be breached. If they want to operate insecurely, they are welcome. Did a PM or sales engineer from your org ever sit down with the customer to figure out what they were doing with root access that your solution lacked? My naive read here is that the customer saw it as easier to keep root access because your product didn't expose what they wanted or did it in a cumbersome way.

masklinn 3y ago
They were providing root either way, the only change I assume was switching from the same root on all machines to a per-machine root password. I can understand how that would be a pain in the ass if your legacy architecture (e.g. administration and reporting tooling, etc…) is predicated upon a unified root, you probably don’t even have a way to report the information so that machines and passwords could be paired. Assuming a good way to provision keys is provided, I’d make the insecure unified root password into a paid option (with lots of warnings) the price of which would increase every year. This way the existing workflow of the customer keeps working short-term, but you CY the hell out of your A in case of breach at the customer’s, and at one point the line item will get large enough that the customer allocates time & money to fix their shit.
- true_religion 3y ago
  Charging for insecure systems incentivizes selling those same systems to customers. Soon you’ll have sales guys regaling how this unified root password system is extremely convenient and you’re one of the few companies who provides this single-signature-security-system (S4 compliance). Next thing you know someone will gain an software patent on this to ensure no one else can provide it.
  - perfmode 3y ago
    But charging for it also disincentivizes customers from asking for it.
    - PaulHoule 3y ago
      Pass some law that says the money has to go to some federal cybersecurity fund or something to pay for cleaning up the mess.
  - masklinn 3y ago
    > Soon you’ll have sales guys The solution is trivial: no commission on this. Possibly even negative commission, can't convince your client not to take this? You get less money for the sale. This way sales are incentivised to only talk about this if not doing so would lose them the sale entirely.
Yizahi 3y ago
Yeah, they did want to maintain root access because they had started to rely on it, I'm not very familiar with exact details. We have an ongoing process of exposing different debug info in the restricted CLI, but it is a never ending task so they always want something which is only visible to the root.
LeifCarrotson 3y ago
Not OP, but over here, PM and sales usually understand that what's important to me and our other engineers (building a really great machine, with a well-architected, secure, extensible backend) is completely immaterial to my end customer. They're trying to build a car or a chair or an appliance. To them, anything that gets in the way of that goal is bad, anything that supports it is good. Sure, the customer's engineering department had a grand vision of skilled shift leads empowered to look up the fault diagnostics, call over a QC engineer, and get two-party authorization to ignore the fault and continue...but once it hit the floor, and getting QC over to the machine took a whopping 4 minutes, the operators all memorized their lead's and QC's passwords and were rewarded for cutting TAKT times by 3 minutes and 50 seconds. Yes, bad product containment is a huge deal in the boardroom, but there's almost no will to enforce it on the production floor.
- ReactiveJelly 3y ago
  Just Get Shit Done and build a car that's controlled by a Russian botnet. Live laugh love that
ozim 3y ago
That stuff for me is “entrepreneur porn”. For b2b or b2c your customers don’t want to sit with you to make your product better. Yes they want your product better. Myself as a customer I don’t spend time filling in customer reviews. I just want to go on with my life. I see the same in company I work for, our customers don’t have time - they have stuff to be done - either our software helps them achieve their goals or they leave.

masklinn 3y ago

They were providing root either way, the only change I assume was switching from the same root on all machines to a per-machine root password. I can understand how that would be a pain in the ass if your legacy architecture (e.g. administration and reporting tooling, etc…) is predicated upon a unified root, you probably don’t even have a way to report the information so that machines and passwords could be paired. Assuming a good way to provision keys is provided, I’d make the insecure unified root password into a paid option (with lots of warnings) the price of which would increase every year. This way the existing workflow of the customer keeps working short-term, but you CY the hell out of your A in case of breach at the customer’s, and at one point the line item will get large enough that the customer allocates time & money to fix their shit.

true_religion 3y ago
Charging for insecure systems incentivizes selling those same systems to customers. Soon you’ll have sales guys regaling how this unified root password system is extremely convenient and you’re one of the few companies who provides this single-signature-security-system (S4 compliance). Next thing you know someone will gain an software patent on this to ensure no one else can provide it.
- perfmode 3y ago
  But charging for it also disincentivizes customers from asking for it.
  - PaulHoule 3y ago
    Pass some law that says the money has to go to some federal cybersecurity fund or something to pay for cleaning up the mess.
- masklinn 3y ago
  > Soon you’ll have sales guys The solution is trivial: no commission on this. Possibly even negative commission, can't convince your client not to take this? You get less money for the sale. This way sales are incentivised to only talk about this if not doing so would lose them the sale entirely.

Yizahi 3y ago

Yeah, they did want to maintain root access because they had started to rely on it, I'm not very familiar with exact details. We have an ongoing process of exposing different debug info in the restricted CLI, but it is a never ending task so they always want something which is only visible to the root.

LeifCarrotson 3y ago

Not OP, but over here, PM and sales usually understand that what's important to me and our other engineers (building a really great machine, with a well-architected, secure, extensible backend) is completely immaterial to my end customer. They're trying to build a car or a chair or an appliance. To them, anything that gets in the way of that goal is bad, anything that supports it is good. Sure, the customer's engineering department had a grand vision of skilled shift leads empowered to look up the fault diagnostics, call over a QC engineer, and get two-party authorization to ignore the fault and continue...but once it hit the floor, and getting QC over to the machine took a whopping 4 minutes, the operators all memorized their lead's and QC's passwords and were rewarded for cutting TAKT times by 3 minutes and 50 seconds. Yes, bad product containment is a huge deal in the boardroom, but there's almost no will to enforce it on the production floor.

ReactiveJelly 3y ago
Just Get Shit Done and build a car that's controlled by a Russian botnet. Live laugh love that

ozim 3y ago

That stuff for me is “entrepreneur porn”. For b2b or b2c your customers don’t want to sit with you to make your product better. Yes they want your product better. Myself as a customer I don’t spend time filling in customer reviews. I just want to go on with my life. I see the same in company I work for, our customers don’t have time - they have stuff to be done - either our software helps them achieve their goals or they leave.