6 ms·

The sad part is that the companies will use this security by obscurity argument against open sourcing.

TickleSteve 10y ago
contrary to popular opinion.... Obscurity is good practice as one layer of a layered defence system. See "Defence in Depth" https://en.wikipedia.org/wiki/Defense_in_depth_(computing) https://en.wikipedia.org/wiki/Defense_in_depth_(computing) "Defense in depth is originally a military strategy that seeks to delay rather than prevent the advance of an attacker by yielding space to buy time". We have to acknowledge that no system is perfect, there will always be holes, therefore a good approach is to layer up the imperfect systems which delays the attacker. Obscurity is one of those layers, a system will always be more secure if you have to find it first.
- nitrogen 10y ago
  True, but history has demonstrated countless times that closed source code doesn't provide near enough obscurity to deter hackers, and automated fuzzing tools make it even easier.
  - TickleSteve 10y ago
    Of course, obscurity on its own is not a defence. its one part of a whole system, and in that, if it does delay or deter (even slightly) then it has worked.
  - rimantas 10y ago
    And as shown by OpenSSH being open source does not help much in the security department either.
  - TeMPOraL 10y ago
    It also demonstrates that obscurity can significantly reduce the number of attack attempts that are made against you. See e.g. why people move SSH to non-standard ports - raising the entry bar for the attackers has some value.
- lukasLansky 10y ago
  Theoretically yes, but the problem with obscurity is that it creates moral hazard by lowering visibility of all other measures that are or are not taken to protect the system. It's not unreasonable to decide that such extra layer of protection is not worth of making your decision makers subject to being able to cut corners as there is no feedback loop for them.
  - TickleSteve 10y ago
    Its only a moral hazard if you don't trust the people who are certifying the system and therefore aren't subject to the obscurity. The trust question is the problem with obscurity. Do you trust the people making it obscure? In this particular case, where safety-critical standards are relatively well known (within the industry) and not themselves obscured, they deserve to be trusted.
    - michaelt 10y ago
      As long as "independent certification" companies are selected in a competitive market and paid by the system makers, they can't remove moral hazard - only shift it around. After all, if you're a system maker, why would you hire hardasses who have rejected your products in the past? And if you're a certification house, why would you $$$ on many hours from experienced engineers when you could use fewer hours and junior employees giving you happier customers and higher profit margins at the same time? You can hire "independent" people to tell you what you want in a lot of industries. You want an "independent salary survey" to tell you that $50,000 is the market rate for an experienced programmer, but that your CEO needs a $5 million raise? Or an "independent credit rating agency" to tell you your subprime mortgage backed security is triple-A rated? The free market will happily provide such "independent" reports at the right price.
      - TickleSteve 10y ago
        Very true... that is a real effect... But the government(s) also employs similar agencies to perform the enforcement of the certifications. Its not a perfect system, but its a lot better than the developer-on-the-street realises.
- lordnacho 10y ago
  I think you're right that it can be used as a layer, but the reason we admonish against security-by-obscurity is that when you hide something, you often put less work into securing it properly. It's like when you leave a key for someone under a door mat. You don't often consider that the door might be easily kicked in by an intruder.
  - TickleSteve 10y ago
    "you often put less work into securing it properly." Thats the problem right there.... not obscurity.
    - Qwertious 10y ago
      Well, it would be if we were robots who could effectively separate the two problems. But we're not, so we need to avoid obscurity if we want security.
      - TickleSteve 10y ago
        Design is a separate process and skill than implementation. This applies to security and safety. There is no reason not to implement obscurity also. One thing I can guarantee is that your implementation of one security-type will not be unbreakable.... and neither will mine. Better to add obscurity than not.
        type0 10y ago
        Agree. But one should design software without the obscurity layer, then it's okay to explain how obscurity can be set up during deployment.
        TickleSteve 10y ago
        absolutely... given everything else is equal... adding obscurity is a positive.
- belorn 10y ago
  Security by obscurity is in practice almost always a bad idea. 1# security by obscurity gives a false sense of security. Under no circumstance should obscurity be used as a deciding factor behind a management decision. 2# security by obscurity cost money and time, and should only be used when all real form of security measures has been implemented. Even the military are currently not always implementing multi-token authentication, ipsec and selinux. Instead of trusting that the medical deceive is safe behind two layers, a static password and a secret port, add a certificate and implement challenge and response. 3# the priority to implement security by obscurity should be far lower than all the real security technologies. When reading security reports by pen testers, its important to understand the difference between a verified code injection vulnerability and a system information disclosure. Fixing a remotely code injection bug is much more important than hiding the fact that a system is running a up-to-date stable version of Debian, yet many security guides and reports for pen-testing tools rarely priorities. 4# security by obscurity often has real cost in support, brittleness of the system, and debugging. There is still in 2016 firewalls that will permanent block any ip address that has sent a icmp package to them. The amount of work employees are spending to unblock customers that accidentally end up in the block list could be spent on making sure that the system is just that more perfect against the serious attackers who can afford to spend $50 to access a botnet for a few hours.
  - TickleSteve 10y ago
    I agree with your numbered points, but not the conclusion that its always a bad idea. Its common sense that I can't pick a lock if I cant find the lock. This says nothing about the quality of the lock or what is behind the lock.
    - belorn 10y ago
      Almost never. I know where the bank is, I know where the door to the bank is, but that should not make it easy to break into the bank. However, a gold storage might want to keep the location hidden, as they should have already implemented all the security procedures of a bank plus extra. Spending time on security by obscurity should be a job for the small minority of people who already done everything else, and then only if there is a cost-benefit analyze that show cost of the obscurity to be less than the calculated gains.
- nabla9 10y ago
  Obscurity is one possible layer, but it's not very good. Obscurity has a cost for anyone working with the system. Obscurity don't scale. Things that are commonly used should not use obscurity. Somebody who mass produces computing equipment or software that many use can't use obscurity because it's economically efficient for attackers to look past obscurity. It's also unproductive to advice others to use some obscuring methods, because as soon as something becomes even slightly common, it can be detected and security of obscurity vanishes. Obscurity must be obscure. Great minds think alike and it's very easy to build obscurity that is similar to what everyone else thinks is nice trick. Genuine obscurity can provides additional security layer (in probabilistic expected value sense) against automatic or routine attacks. If obscurity requires even small time to figure it out, it's likely that attacker moves to next target. But it's hard to know how well the obscurity is working.
  - kefka 10y ago
    Passwords are obscurity, are they not? And in the end, so are 2048 bit RSA keys. It's just a prime-number needle in the haystack. Look enough places/try enough passwords, and you will find it.
    - augustl 10y ago
      This is interesting and quite philosophical. Is there a difference between procedures and data? Isn't it all just transistors and capcitors anyway? And is anyting really anything? Isn't it all just really quantum fields? Practically speaking, obscurity is a "platform" that lets you bypass everything, whereas knowing a password is more limited since it grants access to a single user. But practically speaking, obscurity and root passwords are similar.. I wonder if there are formal definitions here that makes the separation clear.
      - kefka 10y ago
        If anything, I would use a lock analogy. Locks are rated in how many seconds/minutes they can withstand from a dedicated attacker. Perhaps that would be a way to determine a similar safety rating for passwords/crypto based systems. In passwords: how many passwords can you try per second before the server refuses? Then Password space/# per second = total seconds for guaranteed entry. Crypto: how many keys do you have to calculate before you succeed in finding the correct key? Keys/second * how many machines / keyspace. But in the end, I don't believe we really have a formalized difference between types of obscurities, aside the "go to /root and get root" obvious badness. It would be a rather nice way to provide security in "seconds to millenia depending on techniques used".
- deleted 10y ago
  [deleted]
- runeks 10y ago
  Security by obscurity is not security, I think that's the main objection behind the phrase. Inherently, a system does not become more secure by postponing its subversion. If you have broken security, fix it. If you don't, obscurity is unnecessary. It's qualitative versus quantitative. Security is a quality, which means it can become absolute: the complete absence of security holes. Obscurity, on the other hand, is quantitative, because you can always add more obscurity. There is no "absolute" obscurity. "Buying time" doesn't make sense in this context. It's pacemaker software. Who's buying time by making proprietary pacemaker software and for what reason? Buying time is only useful if you can see when an attacker begins trying to subvert your system. If he can sit at home working on it for a year, "buying time" to improve security makes no sense, as you can't spend the time to improve security,p when you don't know you're about to be attacked.
  - TickleSteve 10y ago
    the discussion on security comes about because the problem discussed is about messaging security (or lack of) on the pacemaker itself.... not about any bugs (or lack of) in the pacemaker software. No layer of security is ever perfectly implemented, mathematically perfect tho the algorithms may be.... this is the key point that defence-in-depth acknowledges... and hence is the key point that obscurity addresses. Buying time certainly does gain you a lot in this context. If someone was attempting to bypass security to get into a pacemaker in side me.... I would damn-sure prefer the apparent "lock" to be hidden rather than in plain sight! (given everything else is equal).
    - hx87 10y ago
      > I would damn-sure prefer the apparent "lock" to be hidden rather than in plain sight I would prefer the lock be visible to me over either situation. Otherwise, how would I know how easy is it to bypass?

contrary to popular opinion.... Obscurity is good practice as one layer of a layered defence system. See "Defence in Depth" https://en.wikipedia.org/wiki/Defense_in_depth_(computing) https://en.wikipedia.org/wiki/Defense_in_depth_(computing) "Defense in depth is originally a military strategy that seeks to delay rather than prevent the advance of an attacker by yielding space to buy time". We have to acknowledge that no system is perfect, there will always be holes, therefore a good approach is to layer up the imperfect systems which delays the attacker. Obscurity is one of those layers, a system will always be more secure if you have to find it first.

nitrogen 10y ago
True, but history has demonstrated countless times that closed source code doesn't provide near enough obscurity to deter hackers, and automated fuzzing tools make it even easier.
- TickleSteve 10y ago
  Of course, obscurity on its own is not a defence. its one part of a whole system, and in that, if it does delay or deter (even slightly) then it has worked.
- rimantas 10y ago
  And as shown by OpenSSH being open source does not help much in the security department either.
- TeMPOraL 10y ago
  It also demonstrates that obscurity can significantly reduce the number of attack attempts that are made against you. See e.g. why people move SSH to non-standard ports - raising the entry bar for the attackers has some value.
lukasLansky 10y ago
Theoretically yes, but the problem with obscurity is that it creates moral hazard by lowering visibility of all other measures that are or are not taken to protect the system. It's not unreasonable to decide that such extra layer of protection is not worth of making your decision makers subject to being able to cut corners as there is no feedback loop for them.
- TickleSteve 10y ago
  Its only a moral hazard if you don't trust the people who are certifying the system and therefore aren't subject to the obscurity. The trust question is the problem with obscurity. Do you trust the people making it obscure? In this particular case, where safety-critical standards are relatively well known (within the industry) and not themselves obscured, they deserve to be trusted.
  - michaelt 10y ago
    As long as "independent certification" companies are selected in a competitive market and paid by the system makers, they can't remove moral hazard - only shift it around. After all, if you're a system maker, why would you hire hardasses who have rejected your products in the past? And if you're a certification house, why would you $$$ on many hours from experienced engineers when you could use fewer hours and junior employees giving you happier customers and higher profit margins at the same time? You can hire "independent" people to tell you what you want in a lot of industries. You want an "independent salary survey" to tell you that $50,000 is the market rate for an experienced programmer, but that your CEO needs a $5 million raise? Or an "independent credit rating agency" to tell you your subprime mortgage backed security is triple-A rated? The free market will happily provide such "independent" reports at the right price.
    - TickleSteve 10y ago
      Very true... that is a real effect... But the government(s) also employs similar agencies to perform the enforcement of the certifications. Its not a perfect system, but its a lot better than the developer-on-the-street realises.
lordnacho 10y ago
I think you're right that it can be used as a layer, but the reason we admonish against security-by-obscurity is that when you hide something, you often put less work into securing it properly. It's like when you leave a key for someone under a door mat. You don't often consider that the door might be easily kicked in by an intruder.
- TickleSteve 10y ago
  "you often put less work into securing it properly." Thats the problem right there.... not obscurity.
  - Qwertious 10y ago
    Well, it would be if we were robots who could effectively separate the two problems. But we're not, so we need to avoid obscurity if we want security.
    - TickleSteve 10y ago
      Design is a separate process and skill than implementation. This applies to security and safety. There is no reason not to implement obscurity also. One thing I can guarantee is that your implementation of one security-type will not be unbreakable.... and neither will mine. Better to add obscurity than not.
      - type0 10y ago
        Agree. But one should design software without the obscurity layer, then it's okay to explain how obscurity can be set up during deployment.
        TickleSteve 10y ago
        absolutely... given everything else is equal... adding obscurity is a positive.
belorn 10y ago
Security by obscurity is in practice almost always a bad idea. 1# security by obscurity gives a false sense of security. Under no circumstance should obscurity be used as a deciding factor behind a management decision. 2# security by obscurity cost money and time, and should only be used when all real form of security measures has been implemented. Even the military are currently not always implementing multi-token authentication, ipsec and selinux. Instead of trusting that the medical deceive is safe behind two layers, a static password and a secret port, add a certificate and implement challenge and response. 3# the priority to implement security by obscurity should be far lower than all the real security technologies. When reading security reports by pen testers, its important to understand the difference between a verified code injection vulnerability and a system information disclosure. Fixing a remotely code injection bug is much more important than hiding the fact that a system is running a up-to-date stable version of Debian, yet many security guides and reports for pen-testing tools rarely priorities. 4# security by obscurity often has real cost in support, brittleness of the system, and debugging. There is still in 2016 firewalls that will permanent block any ip address that has sent a icmp package to them. The amount of work employees are spending to unblock customers that accidentally end up in the block list could be spent on making sure that the system is just that more perfect against the serious attackers who can afford to spend $50 to access a botnet for a few hours.
- TickleSteve 10y ago
  I agree with your numbered points, but not the conclusion that its always a bad idea. Its common sense that I can't pick a lock if I cant find the lock. This says nothing about the quality of the lock or what is behind the lock.
  - belorn 10y ago
    Almost never. I know where the bank is, I know where the door to the bank is, but that should not make it easy to break into the bank. However, a gold storage might want to keep the location hidden, as they should have already implemented all the security procedures of a bank plus extra. Spending time on security by obscurity should be a job for the small minority of people who already done everything else, and then only if there is a cost-benefit analyze that show cost of the obscurity to be less than the calculated gains.
nabla9 10y ago
Obscurity is one possible layer, but it's not very good. Obscurity has a cost for anyone working with the system. Obscurity don't scale. Things that are commonly used should not use obscurity. Somebody who mass produces computing equipment or software that many use can't use obscurity because it's economically efficient for attackers to look past obscurity. It's also unproductive to advice others to use some obscuring methods, because as soon as something becomes even slightly common, it can be detected and security of obscurity vanishes. Obscurity must be obscure. Great minds think alike and it's very easy to build obscurity that is similar to what everyone else thinks is nice trick. Genuine obscurity can provides additional security layer (in probabilistic expected value sense) against automatic or routine attacks. If obscurity requires even small time to figure it out, it's likely that attacker moves to next target. But it's hard to know how well the obscurity is working.
- kefka 10y ago
  Passwords are obscurity, are they not? And in the end, so are 2048 bit RSA keys. It's just a prime-number needle in the haystack. Look enough places/try enough passwords, and you will find it.
  - augustl 10y ago
    This is interesting and quite philosophical. Is there a difference between procedures and data? Isn't it all just transistors and capcitors anyway? And is anyting really anything? Isn't it all just really quantum fields? Practically speaking, obscurity is a "platform" that lets you bypass everything, whereas knowing a password is more limited since it grants access to a single user. But practically speaking, obscurity and root passwords are similar.. I wonder if there are formal definitions here that makes the separation clear.
    - kefka 10y ago
      If anything, I would use a lock analogy. Locks are rated in how many seconds/minutes they can withstand from a dedicated attacker. Perhaps that would be a way to determine a similar safety rating for passwords/crypto based systems. In passwords: how many passwords can you try per second before the server refuses? Then Password space/# per second = total seconds for guaranteed entry. Crypto: how many keys do you have to calculate before you succeed in finding the correct key? Keys/second * how many machines / keyspace. But in the end, I don't believe we really have a formalized difference between types of obscurities, aside the "go to /root and get root" obvious badness. It would be a rather nice way to provide security in "seconds to millenia depending on techniques used".
deleted 10y ago
[deleted]
runeks 10y ago
Security by obscurity is not security, I think that's the main objection behind the phrase. Inherently, a system does not become more secure by postponing its subversion. If you have broken security, fix it. If you don't, obscurity is unnecessary. It's qualitative versus quantitative. Security is a quality, which means it can become absolute: the complete absence of security holes. Obscurity, on the other hand, is quantitative, because you can always add more obscurity. There is no "absolute" obscurity. "Buying time" doesn't make sense in this context. It's pacemaker software. Who's buying time by making proprietary pacemaker software and for what reason? Buying time is only useful if you can see when an attacker begins trying to subvert your system. If he can sit at home working on it for a year, "buying time" to improve security makes no sense, as you can't spend the time to improve security,p when you don't know you're about to be attacked.
- TickleSteve 10y ago
  the discussion on security comes about because the problem discussed is about messaging security (or lack of) on the pacemaker itself.... not about any bugs (or lack of) in the pacemaker software. No layer of security is ever perfectly implemented, mathematically perfect tho the algorithms may be.... this is the key point that defence-in-depth acknowledges... and hence is the key point that obscurity addresses. Buying time certainly does gain you a lot in this context. If someone was attempting to bypass security to get into a pacemaker in side me.... I would damn-sure prefer the apparent "lock" to be hidden rather than in plain sight! (given everything else is equal).
  - hx87 10y ago
    > I would damn-sure prefer the apparent "lock" to be hidden rather than in plain sight I would prefer the lock be visible to me over either situation. Otherwise, how would I know how easy is it to bypass?