I sort of disagree. Not necessarily that it was the wrong choice to invest your security resources elsewhere—I think your threat model is approximately correct—but I disagree that it’s wrong to invest in that part of your stack.
My argument here is that following best practices is a good principle, and that you can and should make exceptions sometimes, but Zack is right to point it out as a vulnerability. Security best practices exist to help you reduce attack surface without having to be aware of every attack vector. You might look at this instance and rightly think “okay but SHA-256 is very hard to crack with keys this long, and there is more low hanging fruit”. But sometimes you’re going to make a wrong assumption when evaluating things like this, and best practices help protect you from limitations of your ability to model this. Maybe your SHA-256 implementation has a known vulnerability that you didn’t check, maybe your secret generation wasn’t actually random, etc. I don’t think any of these apply in this case, but I think sometimes you’re likely to be mistaken about your assumptions. The question becomes a more general one about when it makes sense to follow best practices and when it makes sense to make exceptions. In this case I would think an hour of work would be worth it to follow the best practice. If it were more like five hours, I might agree with with you.
I wouldn’t discount the signaling value either. Allies and attackers can notice whether you’re following best practices and use that info to decide whether they should invest resources in trusting your infrastructure or attacking it.
I agree that this is a correct application of security mindset; exposures like these can compound with, for example, someone’s automatic search of the 100 most common ways to screw up secure random number generation such as by using the current time as a seed. Deep security is about reducing the amount of thinking you have to do and your exposure to wrong models and stuff you didn’t think of.
Furthermore, It is also not inconceivable to me that an adversary might be able to use the hash itself without cracking it. For example, the sha256 hash of some information is commonly used to prove that someone has that information without revealing it, so an adversary, using the hash, could credibly lie that he already possesses a launch code and in a possible counterfactual world where no one found about the client side leaking the hash except this adversary, use this lie to acquire an actual code with some social engineering.
Like:
“Attention Lesswrong! With trickery I have acquired a launch code capable of destroying your site. As proof here is the sha256 hash of it: <hash>.
This is not a trick, I will leave plenty of time for you to check with your EA buddies that the hash is valid before you need to meet my demands.
I demand a launch code capable of destroying the EA forum sent to me until <time> or I will nuke this site and to this I precommitted. I won’t reveal what I plan to do with the launch code you will send to me, but by basic game theory your interest is in sending it to me as your site’s destruction is not certain that way.
I can’t prove it to you, but irl I precommitted to nuking the site if my demands are not met and also that I won’t send any more messages to prevent useless debating.
I sort of disagree. Not necessarily that it was the wrong choice to invest your security resources elsewhere—I think your threat model is approximately correct—but I disagree that it’s wrong to invest in that part of your stack.
I do not know what the difference here is. Presumably one implies the other?
Tale: Today it may be best, to invest elsewhere. But not forever. Security against a dedicated adversary is not always and forever impossible, but a result of continuous investment that is a) eventually achieved, b) requires continuing work going forward (bugs are discovered in resources once thought secure and need patching, malware and threats change, etc.)
In other words, just because it’s not your top priority, doesn’t mean it shouldn’t be improved a little bit, now and then. i.e. the difference between 0% and 5% of invested effort, compounds over time.
I sort of disagree. Not necessarily that it was the wrong choice to invest your security resources elsewhere—I think your threat model is approximately correct—but I disagree that it’s wrong to invest in that part of your stack.
My argument here is that following best practices is a good principle, and that you can and should make exceptions sometimes, but Zack is right to point it out as a vulnerability. Security best practices exist to help you reduce attack surface without having to be aware of every attack vector. You might look at this instance and rightly think “okay but SHA-256 is very hard to crack with keys this long, and there is more low hanging fruit”. But sometimes you’re going to make a wrong assumption when evaluating things like this, and best practices help protect you from limitations of your ability to model this. Maybe your SHA-256 implementation has a known vulnerability that you didn’t check, maybe your secret generation wasn’t actually random, etc. I don’t think any of these apply in this case, but I think sometimes you’re likely to be mistaken about your assumptions. The question becomes a more general one about when it makes sense to follow best practices and when it makes sense to make exceptions. In this case I would think an hour of work would be worth it to follow the best practice. If it were more like five hours, I might agree with with you.
I wouldn’t discount the signaling value either. Allies and attackers can notice whether you’re following best practices and use that info to decide whether they should invest resources in trusting your infrastructure or attacking it.
I agree that this is a correct application of security mindset; exposures like these can compound with, for example, someone’s automatic search of the 100 most common ways to screw up secure random number generation such as by using the current time as a seed. Deep security is about reducing the amount of thinking you have to do and your exposure to wrong models and stuff you didn’t think of.
Furthermore, It is also not inconceivable to me that an adversary might be able to use the hash itself without cracking it. For example, the sha256 hash of some information is commonly used to prove that someone has that information without revealing it, so an adversary, using the hash, could credibly lie that he already possesses a launch code and in a possible counterfactual world where no one found about the client side leaking the hash except this adversary, use this lie to acquire an actual code with some social engineering.
Like:
“Attention Lesswrong! With trickery I have acquired a launch code capable of destroying your site. As proof here is the sha256 hash of it: <hash>.
This is not a trick, I will leave plenty of time for you to check with your EA buddies that the hash is valid before you need to meet my demands.
I demand a launch code capable of destroying the EA forum sent to me until <time> or I will nuke this site and to this I precommitted. I won’t reveal what I plan to do with the launch code you will send to me, but by basic game theory your interest is in sending it to me as your site’s destruction is not certain that way.
I can’t prove it to you, but irl I precommitted to nuking the site if my demands are not met and also that I won’t send any more messages to prevent useless debating.
I hope you will make the correct choice!”
I do not know what the difference here is. Presumably one implies the other?
Epistemic note: I’m not Taleuntum.
I think the difference is:
Tale: Today it may be best, to invest elsewhere. But not forever. Security against a dedicated adversary is not always and forever impossible, but a result of continuous investment that is a) eventually achieved, b) requires continuing work going forward (bugs are discovered in resources once thought secure and need patching, malware and threats change, etc.)
In other words, just because it’s not your top priority, doesn’t mean it shouldn’t be improved a little bit, now and then. i.e. the difference between 0% and 5% of invested effort, compounds over time.