4 ms·

So your only argument is that if someone quits, the secrets will spill out ? I am a big fan of security by obscurity actually. I mean, by announcing to the who

So your only argument is that if someone quits, the secrets will spill out ? I am a big fan of security by obscurity actually. I mean, by announcing to the whole world how you store your secrets, you are telling all the hackers in the world what protocols, what algorithms should they target against. Then one day you suddenly have a 0-day vuln and boom, everything is gone. Compare the risks of that to an employee leaving and leaking the secrets.

hluska 9y ago
First, in practice, don't ever minimize the risks of an employee spilling secrets. Employees are a massive source of leaks. Some good research suggests that 60% of data breaches are caused by employees. Maybe they're just being helpful, maybe they're outright malicious, or maybe they have no idea what they're doing, but insiders are always a massive source of breaches. Don't minimize that; accept it. And second, I said "risk management". Risk management not only looks at probability of breach but at the probability of a judicial or (worse) a legislative response to the breach. If you rely upon security by obscurity, you have to assume that someday, you'll be deposed by an attorney who will want to find out how you protect those secrets. That gets tough because protecting secrets is notoriously difficult, even for government organizations with massive budgets for employee screening and training. It's not impossible, but it's so difficult that you should assume that the probability of a secret remaining secret is close to zero. And, this is where obscurity by obscurity get complicated. It's very hard to tell if a secret has leaked. So, when do you revoke a secret? There is always an organizational cost to changing a secret, yet there is potentially a massive organizational cost to holding onto a secret for too long. That looks too much like a coin toss to me and I don't like playing odds like that. Instead, I like playing the odds by using trusted algorithms and protocols to protect secrets and backing those trusted algorithms and protocols up with some hardcore monitoring, solid policy and well drilled process.
- agnivade 9y ago
  Thanks. Good points. I won't be rolling out my own crypto of course. I like to use existing known parts. But add some slight improvements of my own. Customizations to my use-case. It's a layered defense approach against attackers. The point is to make them work hard.

hluska 9y ago

First, in practice, don't ever minimize the risks of an employee spilling secrets. Employees are a massive source of leaks. Some good research suggests that 60% of data breaches are caused by employees. Maybe they're just being helpful, maybe they're outright malicious, or maybe they have no idea what they're doing, but insiders are always a massive source of breaches. Don't minimize that; accept it. And second, I said "risk management". Risk management not only looks at probability of breach but at the probability of a judicial or (worse) a legislative response to the breach. If you rely upon security by obscurity, you have to assume that someday, you'll be deposed by an attorney who will want to find out how you protect those secrets. That gets tough because protecting secrets is notoriously difficult, even for government organizations with massive budgets for employee screening and training. It's not impossible, but it's so difficult that you should assume that the probability of a secret remaining secret is close to zero. And, this is where obscurity by obscurity get complicated. It's very hard to tell if a secret has leaked. So, when do you revoke a secret? There is always an organizational cost to changing a secret, yet there is potentially a massive organizational cost to holding onto a secret for too long. That looks too much like a coin toss to me and I don't like playing odds like that. Instead, I like playing the odds by using trusted algorithms and protocols to protect secrets and backing those trusted algorithms and protocols up with some hardcore monitoring, solid policy and well drilled process.

agnivade 9y ago
Thanks. Good points. I won't be rolling out my own crypto of course. I like to use existing known parts. But add some slight improvements of my own. Customizations to my use-case. It's a layered defense approach against attackers. The point is to make them work hard.