4 ms·

What we have now is kind of untenable, but I'd argue it's not about the incentives for developers, it's what customers will pay for. I had one customer, as [si

What we have now is kind of untenable, but I'd argue it's not about the incentives for developers, it's what customers will pay for. I had one customer, as [sic] government agency, lecture me about how sensitive their documents were and had to be protected. They even displayed them as images, not as text, to prevent 'copy and paste.' (I'll wait until you're done laughing). I then mentioned that in their current software, all the URLs were directly accessible, since the image requests were not checked by their terrible, terrible, hand-made, bespoke, authentication and authorization system. They said basically that was okay, because the URLs were complicated. They weren't, it was a path and a sequential image id. They wanted to pay for features but not to fix an obvious security hole. And that's probably the norm for most customers - why do they want to spend 300k fixing bad, old code that they think works? Most developers do care and try to make correct software. Some developers are ass-hats that are barely competent, going from project to project before they are 'found out.' Some contractors will put anyone with a pulse on the contract to avoid losing billable hours. And when's the last time you heard someone putting off new features if their competitors were already rolling similar features out? That being said, I can see this resulting in the market for at least some products completely drying up, or getting very expensive. It would basically cement some players into the market, like IBM/RedHat for Linux, ARM and their toolchains for embedded devices, or Microsoft/AWS for cloud. It would be a way to create a moat against competition. It will probably spawn and insurance market, making it impossible for small developers to also purchase the policy to release their software. Maybe you could add additional clauses to open source licenses, such as 'not licensed for use in any sensitive or critical system as defined by USC x.y.z'. And it still doesn't fix the problem of the pointy-haired boss ignoring risks or releasing too early to meet a schedule or competitive pressure.

hardware2win 3y ago
>They even displayed them as images, not as text, to prevent 'copy and paste.' (I'll wait until you're done laughing). Have you considered hidden watermarks just like printers? :)
loup-vaillant 3y ago
One thing I have observed when giving security advice (and having the street cred to do so): people don’t believe it. You tell them no, really 2+2 is not 5, here’s the Peano arithmetic to prove it (2+2 = 1+3 = 0+4 = 4), and they don’t believe you. Real example, I was working on TPM provisioning once. There was something fishy about the process: though they ostensibly wanted a secure channel between the provider and the TPM, the connection procedure didn’t properly authenticate the TPM. It could be replaced by a fake or emulated TPM, the provider would be none the wiser. Not too big a deal (it all happens inside the factory), but still worth pointing out. Anyway, my team lead did not believe me. Fast forward a number of weeks (the TPM is a freaking mess, I was slow), most of the provisioning was done, secure channel and all, the whole procedure worked without a hitch… on an emulated TPM. Told you so: we need to validate the public key shown in the certificate the TPM provides, else it could come from any manufacturer. Anyway, I had working code to prove my case, and my team lead still did not believe me. Me, the guy who wrote a cryptographic library, and was put to work on the TPM precisely because of that expertise. I had to escalate to the security guy on a meeting, and he believe me. Probably because he actually knew his shit. So at last, I was allowed to fix the bug. The lesson I draw from that is that demonstrating a security exploit is freaking important. It’s not enough to point out the bridge isn’t finished, people need to see a car falling down to its doom.

hardware2win 3y ago

>They even displayed them as images, not as text, to prevent 'copy and paste.' (I'll wait until you're done laughing). Have you considered hidden watermarks just like printers? :)

loup-vaillant 3y ago

One thing I have observed when giving security advice (and having the street cred to do so): people don’t believe it. You tell them no, really 2+2 is not 5, here’s the Peano arithmetic to prove it (2+2 = 1+3 = 0+4 = 4), and they don’t believe you. Real example, I was working on TPM provisioning once. There was something fishy about the process: though they ostensibly wanted a secure channel between the provider and the TPM, the connection procedure didn’t properly authenticate the TPM. It could be replaced by a fake or emulated TPM, the provider would be none the wiser. Not too big a deal (it all happens inside the factory), but still worth pointing out. Anyway, my team lead did not believe me. Fast forward a number of weeks (the TPM is a freaking mess, I was slow), most of the provisioning was done, secure channel and all, the whole procedure worked without a hitch… on an emulated TPM. Told you so: we need to validate the public key shown in the certificate the TPM provides, else it could come from any manufacturer. Anyway, I had working code to prove my case, and my team lead still did not believe me. Me, the guy who wrote a cryptographic library, and was put to work on the TPM precisely because of that expertise. I had to escalate to the security guy on a meeting, and he believe me. Probably because he actually knew his shit. So at last, I was allowed to fix the bug. The lesson I draw from that is that demonstrating a security exploit is freaking important. It’s not enough to point out the bridge isn’t finished, people need to see a car falling down to its doom.